5 ms·

To agree with you with a slight rephrase: what makes idiomatic go code is very murky lately. With new changes in the horizon (Go 2 proposals around error checki

by jzoch 8y ago

To agree with you with a slight rephrase: what makes idiomatic go code is very murky lately. With new changes in the horizon (Go 2 proposals around error checking and generics) the current solutions just dont feel idiomatic. Before these proposals started coming in, people staunchly (and many still do) defended error checking and lack of generics. Now, it feels a bit weak. Why am I writing all this ceremony (comparatively little compared to other languages, but ceremony nonetheless) when the new, better way is coming? Additionally, I agree that the idiomatic design patterns of go aren't well defined beyond "use channels, share memory by communicating, handle errors, and dont ever use functional precepts". A lot of go feels really good which makes the not as good parts really stand out. Personally, I'd like to see small QoL improvements (beyond generics and error handling) like named arguments, native functional operators like map, reduce, filter that take advantage of go's great runtime, and something cool like kotlin's by keyword for delegating ( https://kotlinlang.org/docs/reference/delegation.html https://kotlinlang.org/docs/reference/delegation.html)

dcow 8y ago
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`.
- dnautics 8y ago
  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)...
- ngrilly 8y ago
  What does `data` do, and in which language?
  - letientai299 8y ago
    I think he means `data` class in kotlin. https://kotlinlang.org/docs/reference/data-classes.html https://kotlinlang.org/docs/reference/data-classes.html
    - ngrilly 8y ago
      Yes, it looks like this. Thanks!
- bluk 8y ago
  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?
- jstimpfle 8y ago
  > `data` > modern Everything old is new again.
  - dcow 8y ago
    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.
shabbyrobe 8y ago
> 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.
- stubish 8y ago
  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).
  - fpoling 8y ago
    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.
sethammons 8y ago
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.
- jstimpfle 8y ago
  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.

by jzoch 8y ago

dcow 8y ago

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`.

dnautics 8y ago
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)...
ngrilly 8y ago
What does `data` do, and in which language?
- letientai299 8y ago
  I think he means `data` class in kotlin. https://kotlinlang.org/docs/reference/data-classes.html https://kotlinlang.org/docs/reference/data-classes.html
  - ngrilly 8y ago
    Yes, it looks like this. Thanks!
bluk 8y ago
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?
jstimpfle 8y ago
> `data` > modern Everything old is new again.
- dcow 8y ago
  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.

shabbyrobe 8y ago

> 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.

stubish 8y ago
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).
- fpoling 8y ago
  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.

sethammons 8y ago

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.

jstimpfle 8y ago
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.