I really wish Go 2 can make dependency management easier.
Go 2, here we come
111–120 of 534 posts
Re: Go 2, here we come
#112I smell the second coming of the Python 3 fiasco.
Re: Go 2, here we come
#113Earlier quoted context omitted.
Same here. For me it was primarily the syntax. So many people think that syntax is something you get used to, but I don't. Syntax matters a lot for me, and the way Go does it just isn't compatible with my brain. Regular grammars are great for parsers. But really, having an easy to read (conceptually!) language is way more important imho. But call me crazy when I say that I like C++ and can read it effortlessly :)
Well of course you get used to it, like you did get used to C++ (unless you were born that way which I doubt). It just takes time, you don't want to spend that time getting used to Go and that's perfectly understandable.
"you'll get used to it" is a bad measure of usability.
Re: Go 2, here we come
#114I 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.
Not making Go routines values like Ada Tasks is what led to awkward solutions shouldered by the developer such as "context". Too many time Go developers were told to solve issues in user-land, this is the consequence of that.
Re: Go 2, here we come
#115Go 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...
Re: Go 2, here we come
#116Well I must say the Go team is certainly putting in the work to avoid a catastrophic major version bump (e.g. Python). That said, any major additive change to Go, especially generics and/or try/catch will push me away from the language. If I need a well designed language, I have Rust. Go's sell for me is it's so naively simplistic it's actually useful when your team members are idiots. If they bolt on type variables,…
If Go implement generics I’m out
Re: Go 2, here we come
#117I'll be very sad if this goes the way of Perl 6
It won't. It's an explicit requirement that it will not. Or even a Python 3. I had a slide saying as such in an earlier presentation: https://docs.google.com/presentation/d/1DmyTABhGLvN0m2uHktvk... (slide 140) Ian had a good talk & doc about this too recently: https://github.com/golang/proposal/blob/master/design/28221-... https://www.youtube.com/watch?v=LqKOY_pH8u0
How can you have an "explicit requirement" not to end up like Perl 6? Nobody planned to "end up like Perl 6", it's just something that happens when your new, backwards-incompatible version of the language doesn't catch on.
Also, sounds like Go 2 is going to make backwards-incompatible language changes. How is that different from Python 3, or even Perl 6?
Re: Go 2, here we come
#118> 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?
Not sure, but I wouldn't be surprised. There seem to be a lot of Go developers in China and elsewhere who don't really participate in the English-speaking Go community.
I don't really see a reason why there'd be a large iceberg of Go developers in China. There's no reason why programmers in China would use Go in higher proportion than elsewhere in the world.
Re: Go 2, here we come
#119Go 2 Considered Harmful: https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...
When I started work in the early 80's as a COBOL analyst programmer, I encountered ideology vs reality of GOTO. When I learned COBOL, I was taught Jackson Structured Programming. No use of GOTO at all, even exception handling. Fast forward in my first week into work and having done a nice JSP program for the task at hand a senior came over with my code and had a chat. Then took me to the system developers who did all…
Are there normal coding patterns that are much faster with explicit gotos? Modern compilers seem to do a pretty good job of converting normal (goto-less) code into efficient binaries.
E.g, the simple switch statement has several possible machine-code implementations that compilers will switch (heh) between, depending on the characteristics of the cases.
Re: Go 2, here we come
#120Earlier 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++?
Java and Python. It's two closest peers.
Go does not compete with C or C++ in my mind because of GC.
The ONLY thing it does better is packaging because of its standalone native binaries. But most folks using Go are writing software for servers and those are predominantly Linux x86_64... so ¯\_(ツ)_/¯