←back to thread

Go subtleties

(harrisoncramer.me)
235 points darccio | 1 comments | | HN request time: 0.2s | source
Show context
DarkNova6 ◴[] No.45667140[source]
As somebody who only views Go from a distance, I see this list as a combination of „what‘s the big deal?“ and „please don‘t“.
replies(2): >>45667192 #>>45672374 #
OvervCW ◴[] No.45667192[source]
I'm amused by posts like this because it shows that Go is finally slowly moving away from being an unergonomically simplistic language (its original USP?) to adopt features a modern language should have had all along.

My experience developing in it always gave me the impression that the designers of the language looked at C and thought "all this is missing is garbage collection and then we'll have the perfect language".

I feel like a large amount of the feeling of productivity developers get from writing Go code originates from their sheer LOC output due to having to reproduce what other languages can do in just a few lines thanks to proper language & standard library features.

replies(8): >>45667300 #>>45667358 #>>45667372 #>>45667409 #>>45667468 #>>45667838 #>>45668913 #>>45675568 #
1. DanielHB ◴[] No.45667838[source]
I remember when I first got out of uni and did backend Java development, I thought I was incredibly productive because of the sheer amount of typing and code I had to pump out.

After doing a bit of frontend JS I was quickly dissuaded of that notion, all I was doing was writing really long boilerplate.

This was in the Java 6 days, so before a lot of nice features were added, for example a simple callback required the creation of a class that implements an interface with the method (so 3 unique names and a bunch of boilerplate to type out, you could get away with 2 names if you used an anonymous class).