Live data from Hacker News

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

blog.carlmjohnson.net

281–290 of 305 posts

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

#281

Earlier quoted context omitted.

What do you mean by "Go has succeeded"? It has found its niche, yes, but so have those HM languages (maybe the Go niche is a bit bigger), and a bunch of other languages that people also like to hate. Meanwhile, most code is still written in languages like Java, C and PHP. That's no value judgement or anything, I don't think Java is an amazing language (neither do I think it's a terrible one), but it's not like Go has…

The fact that you mention Go, an 11-year-old language, alongside a 27-year-old, a 51-year-old and a 28-year-old language proves that it has succeeded.

Then so has Ruby, Haskell, Erlang, and a bunch of other languages that espouse virtues completely contrary to Go. So I'm not sure what your point is?

Also you didn't even get my point because I explictly contrasted Go, as a niche language, with the big languages that most things are written in.

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

#282
post #268

Earlier quoted context omitted.

I still don't know what people mean by "obvious" code. Yes, there are people who create a mess with abstraction. This happens in every language, in Java people create FactoryFactories, in Haskell people play type tetris, in Ruby, people abuse metaprogramming and in Go, I assume some people go overboard with code-gen. But that said, I suspect many people, when they say, "obvious code", they mean "I can easily understa…

> I still don't know what people mean by "obvious" code. This is one of those subjective "you know it when you see it" qualities that are going to be a function of the code itself and how well it conforms to practices you are used to. I also think that we have a tendency to not notice as much when we read code and understand what it does without having to think about it too much. And you can get lost in Go too. You d…

I agree with most of what you say (including that not every minor duplication needs a refactoring) but I don't understand how this relates to using Go or some other language - and you definitely don't make it sound as if "write obvious code" is this easy fix that everyone knows how to do and that abstractions are always bad and if you don't use them, your code gets magically easy to understand.

It takes nuance and balancing tradeoffs to write good code, and that was IMHO missing from the comment I was replying to.

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

#283
post #269

Earlier quoted context omitted.

I'm not sure why you think that quoting random HN users proves anything except personal opinions of specific people? These are fine, but other people have other opinions. I don't oppose the "principles" you've quoted, but they would just as easily apply to e.g. Haskell (maybe except for the "there's only one way to do it" which however has never been true of any language, including Python). I feel like you missed my…

> I'm not sure why you think that quoting random HN users proves anything Does it have to? How do you prove that what someone expresses is something other than opinion when it comes to programming practices? This isn't a field that is easy to quantify or distill into unquestionable truth. To approach anything nearing proof we'd need data from which clear conclusions can be drawn. A look at scientific publishing on a…

I'm not looking for rigorous proof, but these are just cherry-picked example quotes instead of a coherent argument. You could just as well quote people who have experience dealing with code that is "not clever enough", e.g. 1000 line files without any internal structure. What does that show?

Writing code is about tradeoffs and not about pithy truisms lime "code should be obvious".

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

#284

Earlier quoted context omitted.

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?

Dart is advertised as a client-optimized language. Optimized for UI is what the home page says. Say Goodbye to convincing people to use it on the server.

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

#285
post #247
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…

> The Go team was populated by people who had created one of the most influential languages of all time, C Which is absolutely terrible from a programming language point of view, there were already better languages at its inception. Ken Thompson has a huge legacy in the CS world, but he is frankly not a good language designer at all. Also, appeal to authority. If go were so good, it should able to be praised on its o…

Have you read Worse Is Better?

https://www.dreamsongs.com/WorseIsBetter.html

Go and C are good in a Worse Is Better way. They are not intended for writing the perfect and ideally engineered solution. They are designed to encourage pragmatic solutions to pragmatic problems, and therefore to become popular. And the features that make them suited to becoming popular are, in fact, tied to not trying to produce absolutely ideal solutions to the hard problems.

I am therefore praising them for being good at what they were designed to be good at. And pointing to their popularity is not an appeal from authority - it is a demonstration that they succeeded at their goal.

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

#286
post #25

Earlier 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 needs a VM. Not statically typed. Poor compute performance. Poor strings.

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

#287
post #15

Earlier quoted context omitted.

> Nevertheless I think people implementing them in their own projects is basically code smell and they are a symptom of poorly thought-out code rather than excellent code. Who needs data structures right?

Uh, generics are not data structures and generics are neither the only way nor the best way to interact with data structures.

Yeah, you must hate use the golang map type then. It is a generic data-structure.

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

#288
post #268

Earlier quoted context omitted.

> I still don't know what people mean by "obvious" code. This is one of those subjective "you know it when you see it" qualities that are going to be a function of the code itself and how well it conforms to practices you are used to. I also think that we have a tendency to not notice as much when we read code and understand what it does without having to think about it too much. And you can get lost in Go too. You d…

I agree with most of what you say (including that not every minor duplication needs a refactoring) but I don't understand how this relates to using Go or some other language - and you definitely don't make it sound as if "write obvious code" is this easy fix that everyone knows how to do and that abstractions are always bad and if you don't use them, your code gets magically easy to understand. It takes nuance and ba…

Languages are not just the language definition, but the language and how people use it. The established practices and idioms. The idiomatic approach to Go tends to be very pragmatic, minimalist and direct. And in some areas: highly opinionated.

For instance, it discourages the use of frameworks and prefers libraries. It can be hard to pin down what that means.

Frameworks tend to dictate both how you structure and how you express solutions. Your code is usually very tightly bound to a framework and it is often infeasible to switch to a different framework without a major rewrite. Your application, to a large degree "lives inside a framework".

Libraries imply a greater degree of decoupling and you should be able to rip them out and replace them with something else without having to re-architect your software. If some thought has gone into the design, the change can be as little as a few lines of initialization code. (Think well designed APIs for SQL drivers).

It is important to note that this doesn't really have that much to do with the language. I wrote Java in much the same way I write Go. Prefer libraries, avoid frameworks, prefer writing concrete classes until you a) know you really need something that has to allow for abstraction/flexibility, b) know how to do it because you have already written at least one implementation of the functionality you might want to generalize.

There is nothing stopping you from writing huge frameworks in Go. And some people really want to. They can't help themselves. Thankfully, it hasn't caught on. At least not yet. Nothing in Go dictates it has to be a more "direct" language than Java. But how key people in the Go community practice programming and how idioms evolve has had that effect. It has lead to a lot more code that is approachable.

(Be happy I didn't use C++ as an example, because there every imaginable approach from "C with classes", via "templates everything" to the more modern approach exists. All at the same time. Written by people who all think they are programming in the same language :-))

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

#289
post #269

Earlier quoted context omitted.

> I'm not sure why you think that quoting random HN users proves anything Does it have to? How do you prove that what someone expresses is something other than opinion when it comes to programming practices? This isn't a field that is easy to quantify or distill into unquestionable truth. To approach anything nearing proof we'd need data from which clear conclusions can be drawn. A look at scientific publishing on a…

I'm not looking for rigorous proof, but these are just cherry-picked example quotes instead of a coherent argument. You could just as well quote people who have experience dealing with code that is "not clever enough", e.g. 1000 line files without any internal structure. What does that show? Writing code is about tradeoffs and not about pithy truisms lime "code should be obvious".

So if it isn't about trying to make things obvious, what do you think the goal is?

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

#290
post #245

Earlier quoted context omitted.

What was the marketing investment here..?

Google is using Go to implement Kubernetes. Kubernetes is cool, I want to play with Kubernetes. Maybe I should lean Go to play.

Ok, but calling this a marketing spend that has nothing to do with the language seems ridiculous.
Post reply on HN