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

141–150 of 305 posts

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

#141

Post by IshKebab »

nullwarp wrote: post #62
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 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 definitely agree that learning curve is important and Go is decent IMO but that still seems like a crazy way to choose a language. You don't hire a dev for one day and then fire them.

It would be like deciding to dig the channel tunnel with a spade because TBMs are quite complicated to set up.

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

#142

Post by Night_Thastus »

aptenoforst wrote: post #119
Night_Thastus wrote: post #103

Earlier quoted context omitted.

What do you think Go is missing?

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 designed from the ground up to warn you as much as possible at compilation when something is wrong. You can rely on the compiler a lot. But adding default immutability to a language that isn't designed around the same concepts seems odd. You don't gain the same kind of benefits, but you do have to deal with the tedium. Worst of both worlds, in my view.

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

#143

Post by valenterry »

btilly wrote: post #127
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…

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 honest: it targets junior developers, or at least that was originally a major goal. It is backed by Google and is marketed.

There are just currently way more junior developers due to the demand and the developement of the field.

However, you can already see that a lot of junior developers that started with Go are not so junior anymore and now that they got more experienced, they demand language features that make them more productive - like generics. And they will be added and in the end Go will be a language that is not simple anymore, it will be the new python.

Go is a very practical and pragmatic language, no doubt. It's one if its strengths. But it is not by any means an advanced high-level language in any sense that I would know of.

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

#144

Post by zimpenfish »

za3faran wrote: post #73
nullwarp wrote: post #62

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

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.

> And I question this litmus test of using a junior dev anyway.

As you churn employees, anyone new will inevitably be "junior"[1] when it comes to your code base - Go is (mostly)[2] ridiculously easy to read because you can't (easily) do things[3] that make reading - and more importantly, maintaining - it hard.

[1] Sometimes literally a junior too.

[2] There's a few things I think might trip up someone brand new to Go.

[3] Looking at you, Perl and Ruby.

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

#145

Post by cogman10 »

cempaka wrote: post #72
nullwarp wrote: post #62

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

It skews towards languages that the developer is familiar with.

Kotlin, for example, is a decent bit more complex than java is. It has a lot of new concepts to learn.

Yet, most Java devs can be productive with kotlin in a day or two. Even with the added concepts, it's not that different of a language.

The same is true of C and C++. A C dev could jump into C++ pretty quickly (even if they are just writing C with classes to start).

Your analogy is more like "Dig a hole, here's a shovel and here's a post hole digger". The familiar tool will likely go faster than the unfamiliar tool. And, as it happens, most devs are highly familiar with imperative programming styles, not so much functional programming paradigms.

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

#146

Post by valenterry »

bborud wrote: post #42

Go didn't try to be overly clever and abstract. That rubs quite a few people the wrong way, but it also means you are less likely to have to work with people who try to be clever. My first reaction when seeing Go is that it smelled of "old fart". It looked straightforward and unexciting. I'm an old fart. I like straightforward and unexciting. It tends to lead to code that I can still read 6 months from now. I want to…

Since when has "clever" become something negative? If someone is clever, that's a good thing! I also try to be clever when I do things, be it repairing something, planning my workout routine or programming.

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

#147

Post by Veraticus »

btilly wrote: post #127
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…

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…

Right? So many complaints about "well but it's hard to make N-leaf tries in golang so we need generics!" It's like people believe the success of a programming language is correlated to its ability to express obscure computer science concepts unrelated to most peoples' jobs.

Golang works extremely well in practice, which is what I really care about.

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

#148

Post by valenterry »

Veraticus wrote: post #138
pie_flavor wrote: post #111

Earlier quoted context omitted.

There is no language feature for a tree map. Many problems require a tree map. Either inclusion of generics was a good thing, or it is worth sacrificing static typing or requiring codegen for these use cases. Repeat for numerous collections and APIs. Disallowing someone from using easy statically typed tree maps is not accomplishing any of the simplicity virtues people trumpet Go for having. While the much-warned-of…

This is a pretty arbitrary benchmark. I would guess, again, that 95% of programmers have never and will never need to create a tree map. Repeat for numerous collections and APIs that are totally irrelevant to most programmers' actual experience of programming. Go is optimized for use, not computer science edge cases. And as a result it is widely used, and some of the most complicated and widely-used open-source proje…

It's not about creating a tree map, it's just about using one. Maybe even one provided by a library, doesn't matter. I'm sure that 95% of the developers will need a tree map at least once in their career.

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

#149

Post by cogman10 »

afandian wrote: post #82
adtac wrote: post #40

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

Dang, If you didn't have the 2 requirement java could do it with this

https://docs.oracle.com/en/java/javase/20/docs/api/jdk.https...

I'll betcha 2 for the server comes soon.

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

#150

Post by worik »

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…

> PLT community

What is that?

Post reply on HN