u/TheMerovius

Maybe you can make it to a future meeting then :) It won't be Neuromancer, but discovering new books is part of the fun

Are there specific monthly dates? Like first/third Friday or whatever? Because I've been seeing these announcements for months, but they only come a few days in advance (if that), which is a bit late for my planning.

Meetup zB ist ungewöhnlich tot in der Region.

Meetup ist tot, weil sie ihr Geschäftsmodell umgestellt haben und jetzt exorbitant teuer sind – nicht-kommerzielle meetups sind de facto unmöglich geworden und selbst Teilnehmende müssen jetzt für die fundamentalsten features bezahlen.

In Reaktion gibt es eine Mobilizon Instanz für die Region, die kostenlos benutzbar ist. Leider ist diese relativ schwer zu bedienen und auch nicht super gut besucht. Die Netzwerk-Effekte einer solchen Plattform sind halt schwer zum Abheben zu bewegen.

Aber ja, die Entshittification von Meetup hat leider nachhaltig die Organisation solcher Gruppen erschwert.

No what you really want isn't to avoid %v, it is to convert to int. When you do m := t/time.Minute you presumably want the number of minutes in t. But that's not a time.Duration – a time.Duration is always a number of nanoseconds. Go's arithmetic does not work as units in physics would work: Dividing a time.Duration by a time.Duration does not yield an integer, it yields a time.Duration – but one without a useful interpretation (a language like C++ with custom operators might overload division on a duration-type to return an integer, but Go doesn't have that feature).

So you want to do m := int(t/time.Minute) to get the number of minutes in t as an integer: https://go.dev/play/p/jFXVpfRYLMX.

Or you want to do m := t.Round(time.Minute) or m := t.Truncate(time.Minute) to get the "minute part" of a duration: https://go.dev/play/p/hNfu1c_4IqL

Yes that's fine. I would say roughly ~half of our members are native German speakers (me included). We also have a few people who's first language is neither English nor German. It's actually quite nice, because it means we sometimes get to compare notes against the original, when a book hasn't been written in English (for example, we just this month read a German book).

The conversation will be in English – as the name implies :) As long as that is okay with you, you are very welcome.

I do find this kind of clue a bit ambiguous. Say it says "all innocents in row 1 are connected". Say all of row 2 is innocent. Then that clue is tautologically true, because there is an orthogonal chain of innocents from any person in row 1 to any other person in row 1. So it doesn't necessarily mean that there can't be any criminals between innocents in row 1. However, that's in direct contradiction to the clarification, which says

For example "all criminals in row 1 are connected" means there are no innocents between any two criminals in that row.

I think the correct phrasing would be something like "all innocents in row 1 are connected in row 1" or something?

I also have that issue in the community puzzles, which often use "all innocents on the edges are connected". I think they usually mean "connected along the edges", but it doesn't have to mean that – if the middle 6 people are all innocent then everyone not in a corner is connected by innocents.

First, I'm not sure what made you dig up a a 10 year old comment.

Second, it is. The optimizations brought up in the last paragraph now do sometimes happen. But the relationship between string and []byte is the same as ever.

Done (hopefully) ^{^}

We just put the next event online. It will be on the Neckarwiese again (weather permitting), I'll try to come up with a solution for us to be recognizable.

You can also make an account on rheinneckar.events and subscribe to the book club (or, if you already have e.g. a Mastodon account, use that to follow), that way you can get notifications every time we put an event online. There's a website and an Instagram account coming soon as well.

We always decide on the book to read and the date to meet next at the event itself, and there is a WhatsApp Group we usually invite people into, once we've actually seen them. So once you made it to one meeting, you kind of automatically will make it to all.

I'm sorry about that. It's not the easiest to find a specific group on the Neckarwiese (usually we meet either at the DAI library or in a restaurant, which is much easier to find). It would have been useful to register (or comment or DM here in advance) because if we had known to be on the lookout, we would have posted a more precise location and kept our eyes out ourselves. We where sitting here and that's where we usually are.

I really hope you will try again. I will try to come up with something that makes us more easily recognizable.

There is also RheinNeckar.events, an open and free alternative to Meetup. And as you mentioned book clubs: our next meeting is Thursday. That's probably too short-term to actually read the book, but you can still come by and just say hello – we are always looking for new people to join us. There's also a meeting next week for a different book. We will decide on dates and books for August at those meetings and will announce them again here and on RheinNeckar.events at that point.

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:

• 2026-07-09, 19:00 at Neckarwiese: When Cranes Fly South - Lisa Ridzén
• 2026-07-17, 10:30 at the DAI library: Yolk - Mary H.K. Choi

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

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.

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:

• 2026-07-09, 19:00 at La Locanda 26 Neckarwiese: When Cranes Fly South - Lisa Ridzén
• 2026-07-17, 10:30 at the DAI library: Yolk - Mary H.K. Choi

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

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.