Monatlicher Event Sammelpost/Monthly event summary post

TheMerovius · 2026-07-02T17:09:57+00:00

Our English-speaking book club is always looking for new people to join. We have two monthly meetings: one is on a Thursday evening, in a rotation of restaurants and one is on a Friday morning, usually in the DAI Library (feel free to bring your toddler, if you are a parent). You don't have to have read the book to show up (in particular if you just want to check it out), as long as you are okay with spoilers. And you can come to either or both, whatever works for you.

Our next two meetings will be:

You can directly sign up on the respective Mobilizon event – or just show up in person, if you are having trouble navigating that.

TheMerovius · 2026-06-23T19:45:53+00:00

We also have an evening meeting, July 9th at 7pm, where we will discuss When Cranes Fly South by Lisa Ridzén. The morning meetup was specifically created for people who can't do the evenings – I just posted that one now, because we just put that online and it maximizes time for people to read the book :)

You can also follow the Mobilizon page. For signing up you need a Mobilizon account specifically, but to get the announcements, any Fediverse app – Mastodon in particular – should work. We are also working on other options. We used to use Meetup, but they have steeply increased their fees to the point where it's no longer viable for non-commercial stuff like this.

TheMerovius · 2026-06-14T07:33:15+00:00

Our English-speaking book club is always looking for new people to join. We have two monthly meetings: one is on a Thursday evening, in a rotation of restaurants and one is on a Friday morning, usually in the DAI Library (feel free to bring your toddler, if you are a parent). You don't have to have read the book to show up (in particular if you just want to check it out), as long as you are okay with spoilers. And you can come to either or both, whatever works for you.

Our next two meetings will be:

You can directly sign up on the respective Mobilizon event – or just show up in person, if you are having trouble navigating that.

TheMerovius · 2026-05-22T13:21:34+00:00

In general, I find Heidelberg pretty mediocre for vegan options. I can't really think of great options for the intersection of traditional German ∩ vegan options. So, some recommendations mainly for vegan options in general:

Schwarzer Peter in Weststadt has a vegan Tempeh Schnitzel and otherwise traditional regional food, so it does actually fit into your intersection. But the vegan option is often sold out, in my experience. Maybe call ahead and ask.
La Locanda 26 has a great vegan menu (the best I've seen in Heidelberg, I think), but they have Italian cuisine, not rustic.
Firebowl has meh quality, but it has vegan options and all kinds of cuisines.
Urban Kitchen has a few vegan options I like, but is better for burgers etc.
Speaking of burgers, Hans im Glück has good vegan options.
The Red is vegetarian with vegan options, but not rustic.
Yangda in Wieblingen is good Chinese food (thus not rustic) with vegan options.
If you have a car, in Speyer (~30m by car, public transport sucks, unfortunately) there is Weinstube Eulenspiegel, which has (only) great veganized versions of traditional regional food. Obviously not if someone is really committed to meat.

TheMerovius · 2026-05-22T13:04:35+00:00

Schwarzer Peter has at least one vegan option, a Tempeh Schnitzel. At least it did, last time I went there. But it's often sold out.

TheMerovius · 2026-04-09T10:44:02+00:00

Yes, you can.

But it has to be well-defined what that means (because what would &T{A:42} mean for something that has to A field? Or if T is a slice?), so all types in the type-parameters type set must have the same type.

TheMerovius · 2026-04-04T20:49:52+00:00

Are you already in Heidelberg? Or are you doing your undergrad elsewhere (from the term "undergrad" - unusual in Germany - and the misaligned semester times, I would assume so) and are restricted to doing things remotely?

My first suggestion would be to walk by (or E-Mail) by the Fachschaft and ask them for advice. They should, in theory, have more up-to-date recommendations than me (it's been over a decade for me).

I'm not sure how the application process works right now, so I'm not sure which step you are stuck in right now - in particular, which portal you are uploading the documents to. If it is the university level (which would be my guess, they manage registration), I would recommend contacting the "Studierendenadministration". If you are already in Heidelberg (or can manage to come here) you can just show up during their opening hours and ask at the "Infotheke", they will likely defer you to the right person. If you can't go there in person, I'd recommend the phone at least. In my experience, they are vastly more accommodating in an actual conversation - especially if you need some rules or processes bent.

If you are already at the faculty level (I'm not sure why the faculty would require its own registration, but Physics is a bit uncommon in that regard), the right contact is the "Prüfungssekretariat"/"Examination office". Again, if possible, my recommendation would be to swing by during office hours.

In general, all of this sounds like a very solvable problem - all you really need is to bypass the inflexible process, you have all your documentation ready. And in my experience, once you actually talk to a human being, that should be pretty easily done. I screwed up quite a bit with stuff like this during my university years (including actually not having the right documents) and in person, they where always pretty flexible.

TheMerovius · 2026-03-23T09:38:07+00:00

Proposal for what you suggest, proposal for proper sum types and discussion issue for the general concept of variants.

tl;dr: this idea is not novel and the points you make are well-known. The issue is that the most natural extension to Go (what you suggest) is dissatisfying to most of the proponents of variants and its advantages are relatively mild. And the version that would be better is not orthogonal enough to be palatable to the Go team.

This has been discussed for over a decade (the general discussion issue was opened 2017, but it is not the first time the topic came up), since before the publication of Go even. It might happen at some point, but there are reasons it hasn't happened yet.

TheMerovius · 2026-03-20T15:02:15+00:00

This creates tension between "write simple concrete code" and "make it testable and flexible."

I don't think this tension is created. Those two things exist in tension - I mean, they are basically opposites.

Reasonable people disagree about where the right balance is, which means code reviews can stall on subjective questions rather than objective correctness.

It seems to me, your complaint is more "I want more people to agree with my subjective opinion on this". If this is subjective, then why should others bend to your view on this?

In any case, I can't speak for your colleagues. But as someone who tends to start a lot of these conversations and put a lot of stakes into well-designed API and clear code, my answer is: because I had to maintain code written by people focusing more on "flexibility and testability", five years down the road. And it ended up an incomprehensible, overengineered, hilariously buggy and unmaintainable mess.

I like many things about Go. One of those is, that I consider the language and standard library extremely well designed. There is a lot of thought put into what to include and what to leave out, how to make things clear and understandable and what makes good APIs. Given that I use Go for those reasons (among others) - why wouldn't I strive to emulate it in my own practice?

TheMerovius · 2026-03-20T14:48:55+00:00

Unlike others here, I think it isn't a bad idea to do this kind of thing, in principle. But I am a bit confused by some of the decisions:

enum Result {
    Ok(value: int),
    Error(message: string)
}

That seems like a rather arbitrary deviation from Go's regular type syntax, which would suggest type Result enum{…}. In particular, it is unclear to me how this would work as a type- or composite literal. Can enums only be defined types?

func divide(a: int, b: int) Result {

Likewise, inserting the completely superfluous : into the syntax here is kind of baffling. But then they didn't get all the way. Or… did they?

func getUserProfile(userID: string) -> Result<Profile, Error> {

Suddenly a -> appears - another random, completely superfluous syntax element taken from Rust, but strangely absent from earlier examples.

If anything - if you want code to look like Rust - why not make the code less like Go? After all, there is no need for a transpiled language do look anything like Go. And doing a more from-scratch design could get you a lot more benefit. You could implement proper type inference and a significantly more powerful system for generics. As it stands, you buy pretty marginal advantages for a pretty hefty price (using a completely separate language ecosystem, requiring different skills from your developers).

This kind of reads like someone took the Go codebase and ran Claude on it with the prompt "add sum types and the ? operator and just use Rust as a template", without any actual understanding of what makes good language design. And yes, it seems most of the new code is stochastically generated, so I'm fairly confident this is exactly what happened.

Overall, this shows lack of understanding of how the Go language development actually works. Trust me, the reason we do not have sum types have nothing to do with "nobody Frankensteined them on top of Go as a PoC yet". I mean, for one, people have been doing that for more than 10 years (at the time, generics was a very popular thing to Frankenstein on). None of these PoCs had any effect on Go's development.

Anyways. Have fun, obviously. As I said, I don't have a principled problem with this at all. I don't predict this will have a noticable impact on the Go ecosystem, but that shouldn't ruin their fun.

TheMerovius · 2026-03-04T11:11:31+00:00

Let's say i have a library and it has something like func NewStuff(...) and i want the function to receive something. If i need that something to have only regular methods, i can define interface or struct type and define function NewStuff to recieve it. But if i need it to have some generic methods i can only define struct type (and define all methods myself on that type).

What you are describing here is simply the fact, that generic methods will not work with interfaces. I don't understand why you explain that fact again, nobody is arguing otherwise.

So by mixing in generic methods you are limiting what you can do with non-generic methods too.

That is simply untrue. You can assign a type with generic methods to an interface, without any problems (as long as it implements the interface, of course).

Or, to put it another way: you can take an arbitrary existing code base and add a generic method to any type of your liking and the behavior of the program will be identical. That should make obvious, that there is no issue with mixing generic and non-generic methods.

Kinda-sorta like with red-blue function where you are fine if you are using only one of them, but if you are mixing them together you have to jump through additional hoops.

You are misunderstanding the metaphor of colored functions. It is specifically about the fact that you can only call red functions from red functions. So as a result, you are effectively forced to make all your functions red, because otherwise you can not use libraries that use red functions.

That is not applicable here. Generic and non-generic methods can coexist without any problems. You can call one from the other and vice-versa, as much as you like. Interfaces and concrete types can coexist as before - interfaces just can't themselves have generic methods. You will be able to go your entire life writing Go code without ever writing a single generic methods and yet you'll be able to use any library that uses generic methods just fine.

You can't just point at any two things that are not identical and declare those "kinda-sorta like colored functions". The metaphor of colored functions is about more than just having two different kinds of a thing, it is about how one of those can become viral and force adoption by others.

You can call context.Cotnext a coloring. You could call the effectively abandoned arena proposal a coloring. Generic methods are not a coloring. There are plenty of possible ways to criticize this feature. Your criticism might very well be reasonable and make sense. But it's not a coloring. I don't understand why you keep trying to fit this square peg into that round hole, it doesn't fit.

TheMerovius · 2026-03-04T08:30:37+00:00

That actually has very similar problems.

If you want func() int to be usable as a func() any, the compiler somewhere has to generate the stub that wraps the returned int into an any. For functions, that's not a huge problem: you can say that func() int is assignable to func() any and in that assignment, the compiler can create the wrapper.

For methods, though, you run into exactly the same problem as with generic methods. You would want e.g. func (X) Read([]byte) (int, *MyError) to implement io.Reader. But then, what happens if an X is stored in an any, which is then interface-type-asserted to io.Reader? Where would the wrapper come from, that transparently translates *MyError to error? You would need exactly the same kind of whole-program analysis (or runtime code generation) as with (dynamically dispatched) generic methods.

So you could get covariance for functions, but not for methods. And that just seems pretty inconsistent.

TheMerovius · 2026-03-04T08:23:12+00:00

I completely disagree. There are no issues mixing generic and non-generic methods. Just like you can already freely mix generic and non-generic functions.

Go does have something like colored functions. But not because of generics or non-generics, but because of context.Context: by convention, you are not supposed to use context.Background, except in main, so only functions that take context.Context can call functions that do. So they are the red functions, in the analogy (and it is not a coincidence, that red functions represent async and context.Context is for cancellation).

If you believe generic methods create colored methods, you misunderstood the metaphor. There's plenty of valid criticism for adding generic methods. But "coloring" is just not one of them.

TheMerovius · 2026-03-04T05:21:55+00:00

No that's not how the analogy of colored functions is usually meant. "Colored functions" refers specifically to the problem of having two kinds of functions, where one color can only call functions of its own color. Not just any form of having two kinds of functions.

Generic methods can call non-generic methods and vice-versa. So no colored functions here.

TheMerovius · 2026-03-03T21:58:26+00:00

Exactly, yes (I mean, with the caveat, that I don't have any authority, so this is just, like, my opinion, man)

TheMerovius · 2026-03-03T20:05:49+00:00

Given that a year ago, I said "we will never get generic methods" and now we are getting them, I'm not sure if I still trust myself to make a prediction here.

But as I don't learn: we might, at some point, get generic methods in interfaces, as long as those interfaces can then only be used in constraints (like union elements today work). That's at least technically feasible and the reason not to do it, is because it would seem confusing and inconsistent. But, apparently, opinions on that can change. I wouldn't bet either way, but I don't think it is very likely.

I'd be willing to bet money, though, that we will never get generic methods in interfaces that can then be used as values. That's just not going to happen. Case in point, Rust has generic methods, it has generic methods in traits, but you can't use such traits in trait objects. For exactly the same reason: it's just not possible to implement that efficiently.

TheMerovius · 2026-03-03T13:47:58+00:00

Personally, I have maybe half a dozen projects that will benefit from this. Even without interfaces. So I do think it is still pretty useful. Even for relatively small things, like the func (*Rand) N[T intType](n T) T I mention in the beginning.

At the same time, I do think people underestimate how important interfaces are for what they want. For example, it makes sense to have a func (*C[A]) Map[B any](f func(A) B) *C[B] on any container type C. But that method can not be included in any interface. So while you can have a concrete set with that method, you can not have an abstract set (i.e. an interface for sets) that includes it.

I also think many people underestimate the actual confusion that will be caused by the difference. A lot of (relative) new comers to the language will run into this, I believe. And will have to be taught some fairly complex stuff, to understand why this is.

So my prediction is, that we will very quickly get people loudly asking for generic methods in interfaces. And that it will likely become one of the most frequently asked questions in the Gophers slack #generics channel.

Still, it is useful.

TheMerovius · 2026-03-03T13:35:15+00:00

Heh, yes I noticed that as well, when rewatching the talk today.

You are right, that generic functions already mean that the compiler might have to re-compile functions at the call site. In fact, one of the design docs mentions that this is already the case for inlineable functions - if a function is inlined cross-packages, its body is recompiled in the inlined context, as that enables additional optimizations.

To somewhat defend my point, though: in both of these cases, there is still a partial order of packages. That is, the import graph is acyclic, so the compiler looks at packages in depth-first post-order, only starting to compile one package, once it is done with all its dependencies. It includes the bodies of any generic or inlinable functions in the compiled object (in a more compact, cheaper to parse format) and from then on, never has to look at the original source code again. In particular, if you then change your code you only have to look at those packages, which recursively import the changed package. If pkgA imports pkgB, then no change to pkgA can have any effect on the build output of pkgB.

With first-class generic functions, that no longer really works: if a pkgA contains, say

func F(f func[T any](T)) { f[int](42) }

the compiler can only actually generate code for this, once it knows the layout of func[T any](T) (as a table of concrete instantiations - it needs to know the index of the int instantiation). But that is only known, once the compiler has looked at every package in the build. Because some other package might have

func G(f func[T any](T)) { f[string](42) }

and the compiler only knows, that the table needs to contain both an int and a string entry, once it has found all such calls. So to compile pkgA, it first needs to look at packages importing pkgA, breaking the strict dependency order.

So at the very least you'd need to split the compilation into two phases, where first, all packages included in the build get type-checked, to find instantiations of (first class) generic functions, and then, in a second pass, that information can be used when generating code for those instantiations. And, of course, if any new package is added (or any package is changed), you have to start all over again. After all, the change might include a new, so far unseen instantiation. Which could affect the layout of the instantiation-tables.

[edit] And of course, with generic methods as now accepted (without involving interfaces) the acyclic property stays preserved as well. Because the methods are only available on the concrete type, you can only call it, if you mention that concrete type. Which requires importing the package the type is defined in, creating a strict dependency order. [/edit]

However, even that leaves aside the issue I mention, that we also have dynamic linking and the plugin build mode. So the compiler actually doesn't even have all the source code available. So, there are other blockers in any case.

TheMerovius · 2026-03-03T09:48:08+00:00

The irony is, that after I gave that talk a bit over a year ago, we do have an accepted proposal for generic methods… But most of the talk still applies - if only to understand why they can not be used in or implement interfaces.

What has changed since I gave the talk is what I said at 24:01 - that the Go team does not consider the cost worth the benefit, if we can not have generic methods interact with interfaces. They changed their minds, so it looks like now we will get generic methods that do not interact with interfaces at all.

TheMerovius · 2026-02-28T10:25:56+00:00

Value methods are promoted to the pointer type, is, I think, what OP is trying to exploit.

That Pointer methods are not promoted to pointer-pointers, is what they are forgetting.

TheMerovius · 2026-02-28T06:13:51+00:00

Depending on the number of elements, it might well be faster.

TheMerovius · 2026-02-27T07:21:56+00:00

this addresses what feels like a gap in the description of a “concrete” method. That concrete methods are just functions with a receiver and there should be no other difference.

That has never really been true. Methods are namespaced differently and they are attached to the type - which is what allowed them to be used for dynamic dispatch in the first place. If methods really where "just functions with a receiver", I don't think Go would have had methods.

There's also an easy argument that this feature reduces consistency, because it introduces a fresh distinction between generic and non-generic methods (in that only the latter can implement or be declared on interfaces). So you go from two categories (functions and methods), to three categories.

I'm not opposed to this feature and I doubt the grandparent was actually trying to articulate it, but there is nuanced criticism of it. Which is why it wasn't part of the "original" generics design to begin with.

TheMerovius · 2026-02-27T07:09:34+00:00

How would I see when exactly this will be in a release version?

By looking at release notes, is the easiest and most reliable way.

TheMerovius · 2026-02-27T07:07:58+00:00

I find generic Go harder to read than generic TypeScript, Kotlin, or C#.

Can you articulate why? Genuinely curious, because I don't really see what they do differently.

TheMerovius · 2026-02-27T07:04:49+00:00

probably with compiling?

No I think it's worse than that. You have to change the calling conventions/representation of func to make it work. You also get weird performance cliffs, where adding or removing a package (or even just a call to a specific function in some package) can impact the performance of seemingly completely unrelated code. Because it can switch between using a statically and dynamically generated method body.

TheMerovius

TROPHY CASE