
What’s Coming in Go 1.13 [slides] - dcu
https://docs.google.com/presentation/d/e/2PACX-1vRo5urog_B76BcnQbIo7I391MZUKFj7l3gku6hypJ-WK1KCFw40A7BiM6NOVsqD17sA9jS7GyzCfnN4/pub?slide=id.g550f852d27_228_0
======
cryptos
This slide deck might be nice as a wallpaper for a presentation, but it is not
a good read.

Is there a blog post targeting readers in the web?

~~~
andy_ppp
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.

------
lovetocode
Finally a better module experience inside of gopath. That was a major hang up
for me

------
andy_ppp
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.

~~~
NotPaidToPost
A programming language should be stable, not add/change things all the time.

~~~
andy_ppp
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.

~~~
kc1116
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.

~~~
andy_ppp
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.

~~~
apta
> 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.

