Go was successful because it came after decades of pretty much no language putting good networking tools in their stdlib.
The google brand name behind it also definitely played a role.
Ten years of “Go: The good, the bad, and the meh”
81–90 of 305 posts
Re: Ten years of “Go: The good, the bad, and the meh”
#82The stdlib is the killer feature of go. Several times I wrote high enough performance small services/servers that people not familiar with go were astounded with (mostly the speed of writing the code and memory usage). I made many go converts this way. And I always only had to use the stdlib (many benefits when writing within a company).
I consider the stdlib to be Go's best feature too. As a somewhat contrived example, can you name any language that lets you write a HTTP/2 TLS endpoint that computes the HMAC of a PNG file's pixels without any dependencies? And if something is still missing, it's probably in golang.org/x (which is basically stdlib)! After that, I probably consider readability at 3am [1], defer statements, explicit error handling and…
Just cos I was curious and Java has a pretty good comprehensive library.
- PNG: https://docs.oracle.com/en/java/javase/14/docs/api/java.desk...
- HMAC - https://docs.oracle.com/en/java/javase/14/docs/api/java.xml....
You need Jetty for HTTP/2.
Re: Ten years of “Go: The good, the bad, and the meh”
#83Earlier quoted context omitted.
> anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful. Go made me truly realize how insufferable the PLT community is, and why they are so absolutely lost when it comes to creating successful…
golang mainly ended up competing with and replacing the likes of python and ruby, where it was intended to compete with C and C++, where it didn't really change anything. It makes sense in retrospect of course, python and ruby are slow, dynamically typed languages, and any improvement in performance and typing is welcome. It doesn't mean that golang is inherently better somehow to other offerings. I still maintain th…
Good point. I know I'm just being bitter, but I still can't stand Python after dealing with the 2->3 transition. I code mostly Java and use Go where I might have reached for Python before. The Go built in libs make it so easy to build small CLI apps where I may have used scripting before. And the cross compile situation makes it easy to ship wherever. I'm not a PLT person, and Go is easy for me to simply solve problems with. Probably also why I'm fine using modern Java.
Re: Ten years of “Go: The good, the bad, and the meh”
#84Very insightful. Re: the generics point — As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic. I’m glad generics were implemented, if only to silence the chorus of people who didn’t even use Go but whined about the lack of them. Their inclusion has simplified the stdlib and led to some cool new functi…
> As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic. I guess you have never written a library. It's extremely useful there, stuff like "generic function that runs a channel thru X workers doing f() on it" is now easily possible with full type safety. > Nevertheless I think people implementing them i…
I have written a library actually. I found interfaces perfectly sufficient for allowing applications to consume the contracts of the library without needing generics. Of course I understand that they have a use and are useful, but it's not like there weren't excellent solutions for this in Go before generics existed.
Re: Ten years of “Go: The good, the bad, and the meh”
#85Earlier quoted context omitted.
Go really is great. There was a big argument around a new project we were starting whether to do Go or Clojure. What we did to settle the debate was to ask an entry level dev that was just starting if he was interesting in writing two sample applications in each language, having known nothing of either. Nothing complicated but touched enough points (HTTP endpoints, database interaction) A full day later was still try…
As a method for choosing a language, doesn't this just inherently skew to the smaller and more simplistic one, which may not necessarily be the best for all tasks or over a longer run where the techniques of the more involved language could be learned? It's like hiring a new farmhand and saying, "here, dig two 3 foot holes, and we'll see what takes you longer, this shovel or an excavator you have no training or exper…
I would say it skews towards languages that are easy to be immediately productive in, which is certainly one of Go's biggest strengths.
Re: Ten years of “Go: The good, the bad, and the meh”
#86Earlier quoted context omitted.
Yeah this was my primary complaint with the inclusion of generics. People will try to be all clever and their code will wind up as an unreadable, unmaintainable disaster. It has definitely led to some cool stuff, but I prefer boring, verbose, and clear any day.
Problems are generic, such as having a tree collection. For solving generic problems, you can either use language generics, or reflection, or type erasure, or codegen. The latter three are about as far from 'boring and clear' as you can get. Still verbose, though, but I don't expect that's a benefit.
I would say 95% of people who are trying to solve a complicated problem with reflection, type erasure, or codegen are solving the problem the wrong way. Obviously I'm glad these tools exist, and some problems can indeed only be solved with them. But I think people reach for them as a first solution and make bad code as a result. Go strongly encourages you not to reach for bad solutions, which is one of its bigger advantages, in my opinion.
Re: Ten years of “Go: The good, the bad, and the meh”
#87Earlier quoted context omitted.
I consider the stdlib to be Go's best feature too. As a somewhat contrived example, can you name any language that lets you write a HTTP/2 TLS endpoint that computes the HMAC of a PNG file's pixels without any dependencies? And if something is still missing, it's probably in golang.org/x (which is basically stdlib)! After that, I probably consider readability at 3am [1], defer statements, explicit error handling and…
Just cos I was curious and Java has a pretty good comprehensive library. - PNG: https://docs.oracle.com/en/java/javase/14/docs/api/java.desk... - HMAC - https://docs.oracle.com/en/java/javase/14/docs/api/java.xml.... You need Jetty for HTTP/2.
Java also has a comprehensive stdlib but the golang stdlib is designed so much better, and has a small number of simple and orthogonal concepts. (e.g io.Reader and io.Writer go a long way, compared to the 20 io interfaces in java).
Re: Ten years of “Go: The good, the bad, and the meh”
#88Earlier quoted context omitted.
Go really is great. There was a big argument around a new project we were starting whether to do Go or Clojure. What we did to settle the debate was to ask an entry level dev that was just starting if he was interesting in writing two sample applications in each language, having known nothing of either. Nothing complicated but touched enough points (HTTP endpoints, database interaction) A full day later was still try…
As a method for choosing a language, doesn't this just inherently skew to the smaller and more simplistic one, which may not necessarily be the best for all tasks or over a longer run where the techniques of the more involved language could be learned? It's like hiring a new farmhand and saying, "here, dig two 3 foot holes, and we'll see what takes you longer, this shovel or an excavator you have no training or exper…
Potentially. Devs might get up and running with Scratch even faster than Go. But I'm assuming the OP already determined that Go or Clojure would work well for the task.
Go probably has a leg up on Clojure for reputation in production projects, considering Docker, K8s, Terraform, InfluxDB, and Geth are all written in Go. The biggest ones I can find written in Clojure are Puppet and CircleCI.
Re: Ten years of “Go: The good, the bad, and the meh”
#89I'd categorize not being able to convert "unused thing" errors into warnings during development iterations as one of "The Bad". Just today I had a couple blocks of code which were causing erratic issues. Wanted to see if it was the second one, so I quickly commented it out. This is just an exploratory development session, no need to comply with code quality guidelines. Still, the code failed to compile because now I…
I use a technique I call "runtime comments": if false { ... stuff I don't want to run right now but the compiler still has to deal with it ... }
Well, for that specific case (it was a well defined block that could be all selected and commented out in order to disable it), your technique would have worked fine, true :)
But of course it can get tiring and not be very practical if the logic to disable is a little bit more spread out (I'd say having to "if false" anything more than 2 paragraphs or blocks of code would already start to feel annoying)
Re: Ten years of “Go: The good, the bad, and the meh”
#90> Again, it shows how things have changed that I praised Go’s type inference as an advance in the state of the art, but now the Hacker News crowd considers Go’s type inference to be very limited compared to other languages. "You either die a language nobody uses or live long enough to be one people complain about." This rubs me the wrong way. Even back when Go first came out, anyone who knew anything about programmin…
> anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system And Go has succeeded despite these condescending diatribes on how a language needs to have a Hindley-Milner type system with ADTs and type classes to be useful. Go made me truly realize how insufferable the PLT community is, and why they are so absolutely lost when it comes to creating successful…
> you can learn in a day and keep in your head.
I'm not sure that this successpoint is really that valuable. It sounds more valuable for those who want butts in seats than it does for long term satisfaction and survivability of your code base.