Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ten years of “Go: The good, the bad, and the meh”

blog.carlmjohnson.net

Post reply on HN
Print view View original

151–160 of 305 posts

Re: Ten years of “Go: The good, the bad, and the meh”

#151

Post by wk_end »

worik wrote: post #150
softirq wrote: post #57

Earlier 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…

> PLT community What is that?

“Programming Language Theory”

Re: Ten years of “Go: The good, the bad, and the meh”

#152

Post by valenterry »

jerf wrote: post #131
za3faran wrote: post #80

Earlier quoted context omitted.

It still doesn't catch everything.

I am not aware of an option that "catches everything", in any langauge.

In terms of default, there are enough languages where all errors are detected and you are forced to handle them. But if you want a particular mean language, check Idris. No chance to ignore an error by accident.

Re: Ten years of “Go: The good, the bad, and the meh”

#153

Post by cheriot »

softirq wrote: post #57
wk_end wrote: post #46

> 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…

I'd phrase it as: ruby, python, and javascript created a generation of programmers that didn't know how to use a type system. When they needed something more light weight and performant, they migrated to the language with the most primitive type system.

Typescript and swift have shown a better type system can appeal to the masses.

Re: Ten years of “Go: The good, the bad, and the meh”

#154

Post by Veraticus »

valenterry wrote: post #143
btilly wrote: post #127

Earlier quoted context omitted.

Even back when Go first came out, anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system, including the inference. The Go team was populated by people who had created one of the most influential languages of all time, C. Who created the new language based on theories about how to encourage good engineering practice. Theories that they were able to test…

C is also a very low-level and close to the machine language. Just because you can build a microchip doesn't mean you can build a spaceship and vice versa. So I'm not surprised about that they e.g. left out generics and said they did so because they didn't know a good or right way to add them to the language. They were honest at least which I value a lot. As to the success of Go that you mention. Well, let's be hones…

Not advanced or high-level enough for Kubernetes, eh?

Most senior programmers I know love Golang. It is easy to teach, easy to read, easy to understand, and easy to be productive in. And it is difficult to make unclear, complicated, or extremely bad code. A trade-off is that it is more verbose than other languages (if err != nil is a meme for a reason), but I think most people wind up prefer the clarity and correctness rather than hiding error handling.

Re: Ten years of “Go: The good, the bad, and the meh”

#155

Post by Veraticus »

z0r wrote: post #101
Veraticus wrote: post #69

Earlier quoted context omitted.

But you probably will have to differentiate at some point between what you're inserting. Why not just do that, instead of artificially combine it into one function? Nevertheless I feel like I'm getting lost in the weeds of this example. Obviously DRY and less duplication is good. However, you have to strike a balance between being clever and being clear. And frankly I would prefer 3 lines of clear code to 1 line of h…

Writing and reading repetitive code leads to unintentional defects. This is why for loop syntax that directly iterates through a collection is less error prone than the equivalent loop built on indexed look-ups. "Clever" code, at least when it is shorter, is often clearer than "simple" code.

I entirely disagree; defects are created by complexity, not repetition.

Re: Ten years of “Go: The good, the bad, and the meh”

#156

Post by LinXitoW »

softirq wrote: post #57
wk_end wrote: post #46

> 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…

Go has succeeded because it's not horrible and supported and used by one of the biggest companies out there. That means you end up with a long list of decent libraries, which to me feels like the main factor of success for a language.

Re: Ten years of “Go: The good, the bad, and the meh”

#157

Post by sethammons »

LinXitoW wrote: post #156
softirq wrote: post #57

Earlier 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 has succeeded because it's not horrible and supported and used by one of the biggest companies out there. That means you end up with a long list of decent libraries, which to me feels like the main factor of success for a language.

Why has Dart not taken off?

Re: Ten years of “Go: The good, the bad, and the meh”

#158

Post by wk_end »

tomcam wrote: post #102
softirq wrote: post #57

Earlier 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…

Now you’ve got me curious. I’d like to type inference in go. Can you tell me what languages do it better?

In ML-lineage languages (including Haskell) you almost never need any type annotations whatsoever, at least not unless you’re poking around at the fringes of those languages (GADTs, various GHC extensions).

Type annotations for top-level definitions are often encouraged for readability and better error messages, but the compiler can almost always figure everything out itself.

Re: Ten years of “Go: The good, the bad, and the meh”

#159

Post by rowanseymour »

Veraticus wrote: post #140
joshuamorton wrote: post #114

Earlier quoted context omitted.

> But you probably will have to differentiate at some point between what you're inserting. Why not just do that, instead of artificially combine it into one function? Why prematurely optimize for differences that may not (and in practice aren't really likely to) happen? Keep in mind that the tradeoff with generics is usually not 3 lines of clear or 1 line of hard to read, it's one line of clear code (T -> T), one lin…

I would say that a BulkInsert(Any) is a significant premature optimization over just inserting an object as would apply specifically to that object. Because it sounds like you'd have to do weird reflection stuff on the object to determine how and what to insert where. If you are inserting an object, you should insert it, rather than create complicated generic insert methods that morph themselves based on the object b…

My example was a bit simplified but basically the function takes a SQL statement and a slice of structs that use db:column field tags. It's no more doing "weird reflection stuff" than say json.Marshal

Re: Ten years of “Go: The good, the bad, and the meh”

#160

Post by aptenoforst »

Night_Thastus wrote: post #142
aptenoforst wrote: post #119

Earlier quoted context omitted.

Anything that made programming easier in the last 30 years. I miss Hindley Milner type inference, ADTs, default immutability, sane error handling, pattern matching, and functional collection manipulation. I'm not even mentioning the time it took to add generics to the language, which should've come from the beginning, and we got a bad implementation of it. Not saying that it HAS to have all of this, but at least 1 or…

TBH, it sounds like you want a functional language (type inference, pattern matching, collection manip), of which there are many. GO is not such a language. But then you want ADTs, which aren't really functional. I'm not sure you can have both in a clean way. The closest you might get is a multi-paradigm language that tries to allow both, like C++. Default immutability is great in a language like Rust where it's desi…

Not exactly. I don't think Go should have ALL those, but some would be extremely helpful. That's just a wishlist.

There are some examples of languages that have a nice blend of functional features built in that are not fully functional languages, and the developer experience is fantastic (e.g. C#, Typescript, Kotlin, Swift, Java 11+)

They could've improved the developer experience, but they made some kind of C+- with easier concurrency.

And I find it all sad because Go ticks many of my boxes for a "perfect" general-purpose programming language.

Post reply on HN