Hacker News Reader

> Why am I writing all this ceremony (comparatively little compared to other languages, but ceremony nonetheless) when the new, better way is coming?

Whether or not the new way will be better is far from assured.

I'm outing myself as a bit of a "get off my lawn" greybeard here, but as long as such a large swathe of the industry remains trapped in a permanent state of convulsion where everyone competes to build the next monument to their own cleverness, the unprecedented consistency, clarity and productivity that vanilla Go 1 provides will remain under-appreciated.

There's an awful lot of sound and fury over generics and error handling. I sincerely hope that if and when something is done about it, it isn't done in a way that gives anyone a license to be clever.

> "use channels, share memory by communicating"

They walked back a bit from this, thankfully, and I'm seeing less and less nasty "channels for the sake of it" code these days as a result. The party line seems to be closer to "channels are good and bad, mutexes are good and bad, favour whichever is goodest" nowadays, and the larger projects I've worked on have typically been about 50/50 [1]

  [1]: https://github.com/golang/go/wiki/MutexOrChannel

Whenever I think something is missing, I find it helpful to remind myself that Go is kind of the ultimate "80%" experience. Absolutely everything is 80% complete, from the language, to the tools, to the stdlib, it's performance relative to vanilla C... everywhere. 80%. I also think this is the secret of its success.

Interesting about channels. I had been wondering why, despite always being touted as a core feature and reason for Go being awesome, I find them quite rare when looking at other people's code. I've only found them particularly useful for communication between goroutines on one project (filtering events, sending them to the correct workers), and the rest of the time mostly used to implement timeouts (and wishing for some syntactic sugar there, since it can be non-obvious how to to avoid leaking the timers).

Channels in Go do not allow to prioritize messages and proper support for cancelation is highly non-trivial. Both are necessary in complex software. With mutexes one can build all these things, but lack of language support for mutexes sucks.

That's a really good point actually, I hadn't thought directly about this before. I've just evolved a position on it without articulating it directly: I almost never include them in my public APIs, almost never see them in the better APIs, and tend to count it as a strike against a package if I see that they're used without strong justification.

I find there's a lot you have to do manually to handle them correctly and it's easy to miss details. I think they're best cordoned off behind isolated, encapsulated parts of a channel-free public interface.

To walk back a tiny bit from my earlier "80%" claim, I reckon channels are probably more like 50% complete. The existence of "context.Context", itself very much half-baked, is a symptom of that.

You have to think long and hard about cancellation and blocking every time you interact with them (even if you decide you don't ultimately need to), and the results, once you've (hopefully) handled all the corner cases can degenerate into a tangled mess that's hard to reason about, harder to test, and impossible to change. I like to call this kind of code "channel soup".

I'd be interested to see proposals for what the 80% version of channels would look like. What we have now is a great start, but it's not great yet.

Why named arguments? The parameters should show up in any decent editor showing their type and the name chosen by the implementor. The only reason I can think of for named arguments is to allow for default values to be left out of function calls, which just wouldn't fit in with Go.

The point of named arguments is to be more explicit at the call sites. It's also a way to be more robust against API changes -- you can add new optional named arguments or change their order, without breaking existing invocations. You can use named arguments to make a function interface with many optional arguments -- the kind of thing you would otherwise make a builder style interface for. But that's only the idea; Not saying it is necessarily a good idea to include named arguments.

Many people aren't using "decent text editors". vim isn't one. Webpages and prints of code chunks aren't. Information that you must inquire interactively is simply not the same as static information expressed inline in the code. Such is always a little more typing work but often it's worth it.

I would argue `by` and `data` are the two most powerful keywords from any of the modern languages (~last 10 years) maybe next to `go`.

You should check out the "with" keyword from elixir, (but the #1 all time best elixir feature is the |> (pipe) operator combined with IO.inspect)...

What does `data` do, and in which language?

I think he means `data` class in kotlin.

https://kotlinlang.org/docs/reference/data-classes.html

Yes, it looks like this. Thanks!

IMO `async/await` (C# / JavaScript), `defer` (Go), and `guard` (Swift) have changed the structure and flow of programs and are commonly used in their respective languages. Why do you believe that `by` and curiously `data` are so powerful?

> `data` > modern

Everything old is new again.

I was considering `data` specifically in the context of the JVM. I understand we’ve had structs for ages but the concept of anything other than a reference is so terrribly foreign to the JVM it has made so many really shitty programs noticeably less shitty.