Generics!!!
I can't wait for all the different data structure libraries to embrace it. It will make Go adoption in Data Science use-case easier.
Go 1.18
21–30 of 614 posts
Re: Go 1.18
#22LET THE REWRITING BEGIN!…
Re: Go 1.18
#23This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…
> I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the language design, but I suspect that doesn't account for all of it. It seems to me that the intensity with which some people fixated on the absence of generics cannot be explained just by frustration with writing non-generic code, which by all accounts was annoying but not overwhelmingly so.
> In any case, it's something I've been trying to figure out for a while and I don't think I have a complete explanation still. Curious to see what others think.
Couldn't the same be said for every programming language, ever? People often spend more energy complaining relative to the pain that they went through, I don't think there is anything specific about to Go about this. Just look at every discussion about C, C++, Java, JavaScript, Python, Ruby or even better, PHP.
Re: Go 1.18
#24This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…
I'm not the target market for your question, but I stopped using Go mainly because I felt constrained. I prefer functional programming style and that was very difficult in Go. More than that, I hated having the language dictate to me where my code had to live (this has since been fixed). I also disliked the lack of a package manager (also since fixed). I do dislike the verbosity of Go programs (some of which is forced by the language, other of which is self-inflicted by devs writing very long functions), although this is more of a style choice, and style is something that you can get used to.
I don't dislike Go though, and I still use it occasionally. I love the go formatter, and I like the built in channels (although now that I've experienced Elixir/Erlang I think the actor model is pretty great).
I think of it as a flavor of ice cream: some people will like it, others won't. Even if I hated Go, I still believe that the diversity in languages is a good thing and I have yet to see a language that didn't contribute to overall progress.
Re: Go 1.18
#25No post body was provided.
Re: Go 1.18
#26This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…
I like the simplicity of the language. What I did not like was the complete denial of functional patterns for problem solving. The language has first class functions but language's "best practices" and the core library are imperative and all 3rd party libraries (rightly) follow suit.
I appreciate that the language designers had a specific vision for their language. I have much respect for them. They have a lot of experience and expertise. I prefer functional patterns so I decided to discontinue go and learn a different language.
Re: Go 1.18
#27Now time to update interface{} usage and shift to any.
$ gofmt -r 'interface{} -> any' -l **/*.go
Re: Go 1.18
#28This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…
> I would like to understand a bit more about where a lot of the Go criticism comes from. Go is really s souped up version of C. It's a design rooted in the 70s with some fixes to make it a good language for writing small networked apps. Insofar as that goes¹, the language is fine. However the creators of Go responded to critiques of the language in a patronizing manner and talked down to their own programming commun…
> However the creators of Go responded to critiques of the language in a patronizing manner and talked down to their own programming community at Google as being unable to handle complex languages.
Can you provide examples of that? Because the closest thing I can remember is Go creators saying that C++ had too many features interacting in weird ways, and that they wanted to avoid that. Which is a perfectly normal design goal.
Re: Go 1.18
#29This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…
I work at a Go shop that was a Python + RoR shop when I joined. I don't dispute Go's benefits at our scale. As a matter of personal preference, I don't enjoy Go. Go is Blub ( http://www.paulgraham.com/avg.html ). I think the industry is in a place where Blub makes sense! Lots of VC money is floating around, and schools are training a lot of people to hire with that money. Commercially relevant ideas most often succee…
Go wins because it's generally simple and consistent. People like simplicity rather than kitchen-sink languages. And this doesn't only apply to the grammar and type system, but also to the tooling--Go doesn't require you to:
* Pick a testing framework / runner
* Learn a DSL to manage dependencies
* Learn how to configure the build system to ship static binaries
* Debate code formatting rules
* Build a CI pipeline to build and publish source code packages
* Build a CI pipeline to build and publish documentation packages
* Tune a GC for low-latency + low-memory
Re: Go 1.18
#30This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…
> So, for those of you who are willing to explore the part of this that goes beyond a simple rational analysis and criticism of language design, whats bugging you?
Error handling is a big one for me. This could be generalized to lack of expressivity; it takes an unreasonably large amount of code to accomplish anything. Generics will help with the general case, but they don't do anything for error handling.
Lack of sum types, as you already mention, are another.
Go really likes forcing you to either write a ton of tests or discover your errors in production. More expressive features (sum types, etc) effectively mean that compiler provides those tests to me for free. _Can_ I write them myself? Yes, obviously, but that brings us right back to having to write way too much code to accomplish anything.
Farther down the list is escape analysis. Rather than just giving me control over whether allocation happens inline or indirect, if I have some performance critical submodule, I have to sit there and box with escape analysis; this is not only time consuming, but extremely brittle.
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... is a good read for fairly specific issues that _mostly_ haven't directly impacted me, but on the rare occasion they have, they've been infuriating.