Its a shame that Go as a language is so lacking, the tooling is amazing.
I wish there was something like Go but with an actually good programming language attached.
Ten years of “Go: The good, the bad, and the meh”
71–80 of 305 posts
Re: Ten years of “Go: The good, the bad, and the meh”
#72Earlier 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…
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 experience with," and then concluding the shovel is superior for all digging tasks from that point on.
Re: Ten years of “Go: The good, the bad, and the meh”
#73Earlier 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…
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…
golang and Clojure are not in the same space, so it doesn't make sense to compare them. And I question this litmus test of using a junior dev anyway.
Re: Ten years of “Go: The good, the bad, and the meh”
#74Earlier quoted context omitted.
The documentation for DBNull [1] seems to have some idea that DBNull represents something entirely different. > Do not confuse the notion of null in an object-oriented programming language with a DBNull object. In an object-oriented programming language, null means the absence of a reference to an object. DBNull represents an uninitialized variant or nonexistent database column. For all the explanation though, I coul…
I don't know C#, but I'll take a guess: I think it's exactly the same issue as null in Lisp and Lua — you sometimes want to differentiate between null as in "I returned no value", and null as in "I returned the fact that there is no value". Or null vs false vs empty list in the context of Lisp. This distinction becomes very clear (and sometimes very annoying) when you realize that in Lua, setting a table key to null…
There is no difference between "no value" and "the fact that there is no value". "The fact that" is just rhetorical verbiage.
There is an ambiguity in a polymorphic container between a present entry indicating a null value, and a null return indicating there is no entry.
E.g. hash table being used to represent global variables. We'd like to diagnose it when a nonexistent variable is accessed, while allowing access to variables that exist, but have a null value.
This is because the variables are polymorphic and can hold anything.
When we are dealing with a typed situation (all entries are expected to be of a certain type, and null is not a member of that type's domain) then there is no ambiguity: if a null appears in the search for a value that must be a string, it doesn't matter whether "not found" is being represented by an explicit entry with a null value, or absence of an entry.
Re: Ten years of “Go: The good, the bad, and the meh”
#75I am immensely thankful for Go. The simplicity of the language and the stdlib is shockingly well thought out -- things like io.Reader are so obvious and yet not part of many other languages. The language has made me a better programmer. And the cross-compilation story is chefs kiss . Working on a cross-platform project where in Go, I write code and it just builds. In Java, I fight with Gradle. In Swift, I fight the t…
> Working on a cross-platform project where in Go, I write code and it just builds
I've worked on large golang code bases that had to build on bazel, and I had the same experience fighting it. It has nothing to do with the language.
> In Java, I fight with Gradle.
So gradle's issue, not Java's. See above.
Re: Ten years of “Go: The good, the bad, and the meh”
#76Earlier quoted context omitted.
Not just networking but focusing on concurrency. In before if you needed to make a highly concurrent network app you had to get into asynchronous programming that generally makes code looks shit (or at least slightly worse) and harder to debug. With Go and goroutines taking IIRC around 8k for start you can "just" spawn as many of them as there are connections and write your code as if it was serial one. Add some half…
Erlang had a better concurrency story than Go, and better error handling. But alas marketing wins.
Erlang is dynamically typed.
Re: Ten years of “Go: The good, the bad, and the meh”
#77> 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…
> 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
Fine. But it's beside your parent comment's point. The article claims that everyone thought Go's type system was an advance on the state of the art. This isn't even close to true.
Re: Ten years of “Go: The good, the bad, and the meh”
#78Earlier 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…
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…
I mean if you have ever written a for loop before you know enough go to get started. I like go fine but this seems like a very short sighted thing to optimize for.
Re: Ten years of “Go: The good, the bad, and the meh”
#79Worked with Go over 6 years; my biggest annoyance at the beginning, verbosity of error handling, has mostly gone away. In most cases the explicit error handling helped us hardening the code. What does still bother me is the lack of proper enum support. I remember when Java boosted their enum support and the way it impacted the quality of the code. Sure would love to see something similar in Go.
Java now has records, record patterns, pattern matching, and switch expressions. Things that the golang author still don't seem to understand the need for (quite ironic for a language that claims it makes concurrency easy).
Re: Ten years of “Go: The good, the bad, and the meh”
#80Earlier quoted context omitted.
a, err := f() if err != nil { return } a, err = f() This will compile.
I consider use of the "errcheck" linter mandatory for a professional Go programmer, and honestly even the hobbiest really ought to be using it. Yeah, it might be nice if it were integrated into the language but on the overall cost/benefits analysis of my actual costs & benefits rather than merely aesthetic ones, this one doesn't actually factor very high for me because using errcheck is easy. And I supplement all lan…
It still doesn't catch everything.