@vic @ins0mniak @lanodan @lonelyowl13 I'm fine without the defaults and I don't really mind the iota stuff; I did a lot of Limbo. What I do mind is the lack of macros: it's really nice to have lambdas, it's kind of sucky to have to repeat myself. I get the concerns about preprocessor abuse but if you look at the "Coroutines in C" paper, you can't do that kind of thing in Go. (Go has coroutines but what I mean is that without some kind of macro system, you have to hook into the compiler directly to avoid repeating yourself.) Like, the provisioning stuff in CofeSpace, I had a stack of undoable actions, right, "Create the database" was paired with pushing "Drop the database" onto the undo stack so that if something failed down the line, it'd pop things off the undo stack one at a time and this is pretty obviously the correct structure for something like that, but everything that should have been one line was six or seven, like "do this, if it succeeds, do this, and if it fails, execute the undo stack and return". In a C macro, you could drop two blocks in and have the macro handle the repetitive bits of the control flow, and Go doesn't have something nice like that. (At this point, there's so much "if err != nil {" that if they did add a preprocessor, everyone would cover their entire codebase in indecipherable macros and they want a compiler that you can use at large companies, and I begin to suspect that you can't make a language that is good for both large teams of interchangeable cogs and also good for 1-5 hackers to hack some shit together with.)

Something I miss from Limbo is typed tuples. So, Go you've got to do a struct, right, but in Limbo you could use tuples as an ad-hoc data structure and not have to name/allocate/etc. a bunch of shit. This is especially painful with channels. In Limbo, you can have "x := chan of (string, int)" where Go wants you to do a struct.

> Channels could be a little more intuitive on some of the edge cases like sending to vs reading from a closed channel.

Yeah; I end up just using the I/O primitives, like they seem to want to steer you in that direction and just to use channels for synchronization primitives. So it panics when you look at a channel wrong, and that's fine.

> I haven't touched generics,

I don't think they were really needed. They look fine, like, just fine; interfaces handled everything I wanted generics to handle. (If I have a gripe, it's that the compiler doesn't seem to let me get too creative with interfaces, so I had to "type XList []*X" instead of satisfying the sort interface by defining "func (xs []*X) Len() int". It seems there are a lot of types you have to make to keep the compiler happy; see previous remarks about tuples in Limbo.)

> I guess it's the least bad option for the kind of stuff I like to do.

I would just go back to doing normal programs in C if they had added a stupid fuckin' analytics snitch in the compiler.