Go 2 Considered Harmful: https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...
I came here just to say that. Glad to see I wasn't the only one.
Go 2, here we come
131–140 of 534 posts
Re: Go 2, here we come
#132I smell the second coming of the Python 3 fiasco.
I'd be surprised if something similar to python 2/3 happens. The go team have been very explicit in saying that all go 1 code must continue to compile, and transitioning to go 2 needs to be as seamless as possible (most likely using tooling to automatically migrate code across, a la go fix from the early days).
Re: Go 2, here we come
#133I really really hope Go 2 can do something about `context`. Context is the biggest hidden wart of Go. We need the capabilities of context in different packaging.
This doesn't seem to be a popular opinion, but I agree. It's such a pervasive functionality in concurrent programs that it really should be a built-in aspect of a goroutine. The problem with context isn't necessarily the interface, it is that it is "viral". If you need context somewhere along a call chain, it infects more than just the place you need it — you almost always have to add it upwards (so the needed site g…
[deleted]
Re: Go 2, here we come
#134Earlier quoted context omitted.
I would love to completely avoid it, and I do when I can, but it has started to creep into every job out there now and especially in areas I spend a lot of time. So just avoiding it is not possible. I maintain it has been shoved down the industries throat for no good reason other than Google. It does nothing better than any of the existing mainstream languages and in many cases is a large step backwards. So no, I wil…
> It does nothing better than any of the existing mainstream languages... Why say this? Even if you don't like Go it's objectively false. What languages are you comparing it to, Java? C++?
What would you say Go does objectively better?
I think you might say threading. Maybe? The JVM can be tuned to get similar performance. Where it fails to get similar threading performance, it has better tuning in general.
Simplicity of the language? Maybe? It's simple, but I think it's too simple. One of my issues with Go is that it's hard to tell what implements what. VSC support is a little hit or miss. The fact that I have to use an IDE, or extension pack in VIM/Emacs, to figure this out is terrible. I like that in C++, Java, Python, C#, and Typescript I can clearly see which things a current struct implements. It makes code navigation easier. The lack of generics makes certain natural, and I mean natural as in how the majority of other languages do things, solutions to problems hard. Do you want a set, i.e. a unique collection of things? Use a map, but keep in mind that equality is at the whole struct level so one field being off and you have logical duplicates. You can't make structs immutable.
Community lead structural design? Most Go apps appear to be transaction scripts where the database connection is created at the handler and explicitly passed down or perhaps buried in a Context. This makes testing hard. You have to mock/stub the DB interface to test business logical. If I want to introduce interfaces that wrap the DB away, I'm told by the community that I'm "overthinking things" or I'm not a true gopher.
Produces a binary? I agree.
Re: Go 2, here we come
#135I'm curious if making go an ISO standard was ever considered.
Given that go is already pretty well specified (and, perhaps more importantly, has 2 mature implementations) it's hard to see what advantages having it formally standardised would bring.
Re: Go 2, here we come
#136Big fan of both Go and also Rust. It is time we move beyond C and C++
Once C++ modules support comes out it will become a lot more interesting, removing the need for makefiles hopefully. https://clang.llvm.org/docs/Modules.html
Modules are not a build system. You will still need a build system to build real C++ code.
Re: Go 2, here we come
#137> We are constrained by the fact that we now have millions of Go programmers and a large body of Go code Are there really "millions" (plural) of Go programmers? Sounds like a bit of an overestimate, no?
Vague estimate is that there are 18 million programmers in the world[1] and that 4% of them use Go[2], so 0.7 million would be a starting point guess as the total number. Note that these were the first two Google search results I found for "number of programmers in the world" and "percentage of programmers in different languages" so... being off by a factor of 10 or more is likely. [1] https://www.computerworld.com/a…
These numbers seem pretty accurate, and I wouldn't expect that they're off by anywhere like a factor of 10.
Think about it: the number of programmers in the world is certainly not off by 10 factor - no way there are 180 million programmers in the world, only 18 of which are visible.
Similarly, there's no way that 43% of programmers in the world are Go programmers, that's again quite clearly off.
I think an estimate of 700k Go programmers makes a lot of sense, maybe with a factor of x2. I would very strongly doubt that there are more than 2 million Go programmers in the world.
Re: Go 2, here we come
#138Go 2 Considered Harmful: https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...
this kind of comment says a lot about current state of HN
this is the new Reddit
Re: Go 2, here we come
#139I really really hope Go 2 can do something about `context`. Context is the biggest hidden wart of Go. We need the capabilities of context in different packaging.
It's not the fastest thing in the world, but task-local storage in C# is pretty great. Miss it much in TypeScript.
Re: Go 2, here we come
#140Go 2 Considered Harmful: https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...
I appreciate a good joke, but is this really necessary on a thread like this? Here's the equivalent Reddit thread; better suited for this sort of comment: https://www.reddit.com/r/golang/comments/a1j3h6/go_2_here_we...
[deleted]