I'll be very sad if this goes the way of Perl 6
Honestly that would be great if it took the momentum out of Go and killed the language.
I loathe working in Go.
Go 2, here we come
41–50 of 534 posts
Re: Go 2, here we come
#42I haven't been keeping up with Go much these days but is there proper debugger support now? Or is it still a half-broken experience?
Re: Go 2, here we come
#43I’m hoping that https://github.com/golang/go/issues/19623 will come through, and we’ll get a native “true integer” type (and hopefully a rational one as well, though maybe this is pushing it a bit). This is really something that should be implemented at the language level, so that “int” can become a true integer, yet still remain efficient in many cases. It is bizarre to me that languages boasting built-in language-l…
That would be quite a fundamental change. At the moment _int_ and _uint_ have certain semantics that, if changed, would surely break many applications and libraries that rely on the current semantics. I am finding it hard to think of a more sweeping and drastic change to the core of a language.
Having said that, I'm by no means a Golang expert – this is the comment of an outsider looking in. I get that the proposer is Rob Pike and obviously Mr. Pike is god-like so what is it I am missing? Is Go 2 meant to break everything? That's like, wow.
Any low-level hardware bit-banging code is going to have to be audited or break in subtle ways, will it not? Is Golang different from C and C++ and languages of that ilk that this sort of change is not that much of a problem? Help me out here folks, I'm genuinely perplexed.
Re: Go 2, here we come
#44I'll be very sad if this goes the way of Perl 6
Perl6 is amazing! Yes it took a while. Yes it doesn't have the same recognition as perl 5. Yes it's crazy. But it's crazy in fun sort of way.
So are chicken scheme and GNU Forth. The problem is that the Perl ecosystem and community are a shadow of what they used to be in the heydays of Perl 5. I used to write a lot of Perl but I wouldn't really recommend it to anybody these days, be it version 5 or 6.
Re: Go 2, here we come
#45Big fan of both Go and also Rust. It is time we move beyond C and C++
I apologize for asking a question that will likely lead to a flame war regardless of your answer, but which is better? I've used Go for a while for certain apps, but as a primarily functional programmer I find my way of thinking often clashes with the language (and I also don't like the verbosity). So, do you do functional programming, and is Rust a better (with all the subjectivity that word implies) language than G…
As a Haskell & Erlang person who currently uses Rust as my primary language at work:
> do you do functional programming, and is Rust a better (with all the subjectivity that word implies) language than Go?
Yes, yes. Obviously the Rust ecosystem has fewer mature libraries, but its type system and error handling make Go look like a toy.
Go can be okay for small one-off tools, but its safety guarantees are not far ahead of scripting languages and I think it should be considered as such.
Re: Go 2, here we come
#46Earlier quoted context omitted.
Well for the first round they are looking at: 1. Allowing generalized unicode identifiers. That is hardly likely to break anything except possibly some crazy edge cases that dont happen in real code. 2. Binary integer literals. (unlikely to break things) 3. allowing seperating groups of digits in a number with _ like 1_000_000 (unlikely to break anything) 4. Permit signed integers as shift counts (no need to cast ant…
For the first round they are testing the GO 2 selection process by applying it to proposed changes for 1.13, which limits it to non-breaking proposals. It won't get interesting until they start selecting breaking proposals.
It won't get interesting until they start selecting breaking proposals.
From what I see in the past couple of decades in popular languages, is there really a justification for breaking changes, from the POV of project maintainers?
Re: Go 2, here we come
#47Well 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,…
Isn't the premise of Go that a team sufficiently large enough will eventually act as a collective idiot in terms of code maintenance? I'm looking forward to some real research on the question of whether Go's design choices have had real world results in improving productivity with supersize code bases.
Re: Go 2, here we come
#48I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows. Haven’t tried it since. Hope lots of this change to make the language more welcoming for Newcomers to the language.
>I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows.
My experience was similar. In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs.
The other thing that turned me off from Go was testing. It has good enough support for unit testing but it really lags behind in integration testing. Sometimes you want to know that if you hit this endpoint with this payload you get this response back. It's harder than it should be to write integration testing where you spin up the application and test it end to end.
Re: Go 2, here we come
#49Big fan of both Go and also Rust. It is time we move beyond C and C++
I apologize for asking a question that will likely lead to a flame war regardless of your answer, but which is better? I've used Go for a while for certain apps, but as a primarily functional programmer I find my way of thinking often clashes with the language (and I also don't like the verbosity). So, do you do functional programming, and is Rust a better (with all the subjectivity that word implies) language than G…
This is like asking for a language war, which is the last thing we want on a language thread. You shouldn't have any problem finding already-existing Go vs. Rust discussion either in the search bar here or on Google.
Re: Go 2, here we come
#50I haven't been keeping up with Go much these days but is there proper debugger support now? Or is it still a half-broken experience?
fmt.Printf() debugging is always a time-honored tradition.