What’s Coming in Go 1.13 [slides](docs.google.com)
docs.google.com
What’s Coming in Go 1.13 [slides]
https://docs.google.com/presentation/d/e/2PACX-1vRo5urog_B76BcnQbIo7I391MZUKFj7l3gku6hypJ-WK1KCFw40A7BiM6NOVsqD17sA9jS7GyzCfnN4/pub?slide=id.g550f852d27_228_0
21 コメント
If you wanted you could copy every slide into a HN comment and then people wouldn't have to read the article. There is not much.
There will be release notes once the release is getting closer. The slides are just very early.
At no point did anybody claim it was a blog post, it even has [slides] in the title.
Finally a better module experience inside of gopath. That was a major hang up for me
They made Go faster (priorities), added some very niche number types and TLS 1.3 support?
The only language features they seem to have added are small improvements to error handling.
The only language features they seem to have added are small improvements to error handling.
On a 6-month release-cycle, how much change do you want each release? (1.13 is scheduled to be released in August, following 1.12's release in February)
It's mostly not new number types, it's new number syntactic niceties.
As the guy who ends up maintaining the build tooling at work, I'm _very_ excited about a lot of the tooling changes:
- "Reproducible builds (independent of build path)" means 2 things to me: That customers building plugins for our product will no longer need to care about how our CI set GOPATH, and that I can drop hacks around the linker on macOS including timestamps (which would otherwise result in expensive Docker rebuilds)
- "Let 'go build' write many binaries" will let me adjust the build scripts to be faster, especially in mostly-no-op cases that my coworkers like to gripe about how slow it is.
I'm also excited about os.UserConfigDir.
It's mostly not new number types, it's new number syntactic niceties.
As the guy who ends up maintaining the build tooling at work, I'm _very_ excited about a lot of the tooling changes:
- "Reproducible builds (independent of build path)" means 2 things to me: That customers building plugins for our product will no longer need to care about how our CI set GOPATH, and that I can drop hacks around the linker on macOS including timestamps (which would otherwise result in expensive Docker rebuilds)
- "Let 'go build' write many binaries" will let me adjust the build scripts to be faster, especially in mostly-no-op cases that my coworkers like to gripe about how slow it is.
I'm also excited about os.UserConfigDir.
I just want Golang to become a language suitable for my needs; it could be if they added generics (meh) or much better first class macros support (please don't tell me go generate it's not even close).
priorities != faster.
priorities == latency control.
In fact, since the scheduler is now more complex, there will be more overhead (however small) and hence slower overall.
priorities == latency control.
In fact, since the scheduler is now more complex, there will be more overhead (however small) and hence slower overall.
Yes, all the go rewrite expectations I was pinning on this 6 month release. I’m sad too.
Time to move back to JavaScript.
Time to move back to JavaScript.
A programming language should be stable, not add/change things all the time.
Sure, it’s just that Golang deliberately lacks features to create abstractions which means every time I look at it I’m disappointed.
It’s very frustrating how unstable and slow in terms of dev speed things are in the last THREE places I’ve worked (as a frontend with the backends all written in Golang). Go teams seem to rebuild everything from scratch and they never seem to understand micro services in the context of distributed systems. I mean we are doing microservices, Golang, grpc, cockroach dB and we have a few thousand users maximum. It drives me up the wall that this stack is so popular and the engineers championing it can’t deliver reliable software quickly in it... most of them can't even optimise queries in SQL and are concatenating strings together in SQL queries.
Take the Elixir ecosystem; I could outpace a team of three Golang engineers easily writing stuff in Elixir and my software would almost never crash or panic and be very flexible when changes were needed. Everything in Golang is calcified around current product requirements and a nightmare to change. So forgive me when I think Golang has a long way to go before it's something I'd want to use for anything but the smallest of command line tools.
It’s very frustrating how unstable and slow in terms of dev speed things are in the last THREE places I’ve worked (as a frontend with the backends all written in Golang). Go teams seem to rebuild everything from scratch and they never seem to understand micro services in the context of distributed systems. I mean we are doing microservices, Golang, grpc, cockroach dB and we have a few thousand users maximum. It drives me up the wall that this stack is so popular and the engineers championing it can’t deliver reliable software quickly in it... most of them can't even optimise queries in SQL and are concatenating strings together in SQL queries.
Take the Elixir ecosystem; I could outpace a team of three Golang engineers easily writing stuff in Elixir and my software would almost never crash or panic and be very flexible when changes were needed. Everything in Golang is calcified around current product requirements and a nightmare to change. So forgive me when I think Golang has a long way to go before it's something I'd want to use for anything but the smallest of command line tools.
Sounds like you worked with shitty backend engineers. I don’t understand how Go has anything to do with that. Nobody uses elixir bud, and saying basically “my software would be perfect” is a naive silly thing to say.
I just think I've had this happen three times in a row, as if there is something likely to be wrong with the types of programmer who choose this technology.
I never said my code is perfect or bug free at all, you just made up a straw man to weaken my anecdotal evidence.
I never said my code is perfect or bug free at all, you just made up a straw man to weaken my anecdotal evidence.
> I just think I've had this happen three times in a row, as if there is something likely to be wrong with the types of programmer who choose this technology.
You can add a datapoint to that based on what I have experienced as well at an employer. Exactly what you mentioned, so much time wasted either due to reinventing the wheel, or because of language friction and it being way underpowered to model the problem at hand. I keep laughing that Java would have been a way superior fit in practically all fronts.
You can add a datapoint to that based on what I have experienced as well at an employer. Exactly what you mentioned, so much time wasted either due to reinventing the wheel, or because of language friction and it being way underpowered to model the problem at hand. I keep laughing that Java would have been a way superior fit in practically all fronts.
If you can't make abstractions in golang without generics your programming wrong.
imho, none of the mainstream languages are in such a state. from venerable C on one hand to Python to Rust to Erlang, even Fortran ! every single one of them is changing.
and, once again imho, this state of affairs is _exactly_ right as well. newer h/w, a deeper perspective on what works and what doesn’t all contribute significantly to this flux.
embrace the change :)
and, once again imho, this state of affairs is _exactly_ right as well. newer h/w, a deeper perspective on what works and what doesn’t all contribute significantly to this flux.
embrace the change :)
C is stable. There's a massive difference between a few changes every 10 years and new features every year.
Golang has been very stable while still adding new features...
Is there a blog post targeting readers in the web?