Ten years of “Go: The good, the bad, and the meh” • Hacker News Board

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

#91

Post by woooooo » Tue, Jul 18, 2023, 6:09 PM UTC

Veraticus wrote: post #86

pie_flavor wrote: post #68

Earlier quoted context omitted.

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

Collections obviously need to be generic though. Slices and maps were generic from day 1 in go so it's not like this is controversial.

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

#92

Post by mr_00ff00 » Tue, Jul 18, 2023, 6:10 PM UTC

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…

This seems good, except that it would always push for the languages that produce now and leave bugs for production.

Python would beat anything by this measure, but static typing is amazing for stopping bugs.

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

#93

Post by rowanseymour » Tue, Jul 18, 2023, 6:16 PM UTC

iamcalledrob wrote: post #43

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

It's the simplicity of the tooling for me. There's no config file besides a list of dependencies. I push my code to github and it can be a dependency because a dependency is just a URL. My code is automatically formatted and there's no config for that.

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

#94

Post by Veraticus » Tue, Jul 18, 2023, 6:17 PM UTC

woooooo wrote: post #91

Veraticus wrote: post #86

Earlier quoted context omitted.

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

Collections obviously need to be generic though. Slices and maps were generic from day 1 in go so it's not like this is controversial.

For sure — a lot of language features need to be generic. But most people aren’t coding language features, and giving them the ability to do so can lead to, well, CodeFactoryFactoryMakerGenericMethodHelpersFactory, rather than good, clear, usable code.

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

#95

Post by 708145_ » Tue, Jul 18, 2023, 6:19 PM UTC

masklinn wrote: post #64

xchkr1337 wrote: post #31

Earlier quoted context omitted.

default values for everything without significantly increasing language complexity

As far as I'm concerned, that's a drawback. Ubiquitous default values are an attractive nuisance. One which C# had already demonstrated 10 years prior. The removal of nil leading to the removal of ubiquitous default values would have been positive.

I think default values are a major flaw, much worse than nil. An unintended default value causes data corruption. All types should be nillable in my opinion, using types that have fallback to a default value is source of nasty silent bugs. In Java for example I would never use a primitive data type.

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

#96

Post by anonyfox » Tue, Jul 18, 2023, 6:21 PM UTC

Comparison with Emacs: an awesome operating system that still needs a great editor.

Go: amazing tooling/libs, only needs a great language :-)

But a few tweaks, like proper Enums and a Option/Return Type (to avoid excessive err != nil), maybe a compilerflag to force dealing with errors (instead of _ it) - much better. If I can wish for something, then some native map/filter/reduce to avoid excessive for-loops…? :-)

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

#97

Post by maccard » Tue, Jul 18, 2023, 6:23 PM UTC

za3faran wrote: post #75

iamcalledrob wrote: post #43

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

Pretty much every golang project I've ever touched builds with `go build`. Most that have makefiles just call `go build`, and the makefile is more for building docker containers, or doing infra-related things. If a project is in go, 98% of the time `git clone XXX && cd XXX && go build` will work.

That is absolutely not the case with C, C++, Java, python.

> So gradle's issue, not Java's. See above.

The issue exists with maven too, but _not_ with go build, which is OP's point.

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

#98

Post by SPBS » Tue, Jul 18, 2023, 6:27 PM UTC

Pxtl wrote: post #5

seeknotfind wrote: post #3

Great article. Go may have generics, but because old Go code doesn't, and the standard library doesn't, it still feels like the language doesn't sometimes.

Basically learning the lessons of Java and C# all over again. Yes, there are features you can defer implementing until later, but their absence infects everything until you do. I still see cases where people have to drop down into ADO.Net code for C#, and the fact that you still see DBNull.Value instead of just a simple null value, much less a proper Option type is infuriating. Like I write a lot of Powershell code a…

> Yes, there are features you can defer implementing until later, but their absence infects everything until you do. I still see cases where people have to drop down into ADO.Net code for C#, and the fact that you still see DBNull.Value instead of just a simple null value, much less a proper Option type is infuriating.

This DBNull.Value may be a problem for C#, but idiomatic Go has largely been untouched by the introduction of generics.

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

#99

Post by kansface » Tue, Jul 18, 2023, 6:27 PM UTC

aptenoforst wrote: post #71

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.

This is pretty much my take, too. Go as a compilation target?

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

#100

Post by maccard » Tue, Jul 18, 2023, 6:29 PM UTC

Veraticus wrote: post #94

woooooo wrote: post #91

Earlier quoted context omitted.

Collections obviously need to be generic though. Slices and maps were generic from day 1 in go so it's not like this is controversial.

For sure — a lot of language features need to be generic. But most people aren’t coding language features, and giving them the ability to do so can lead to, well, CodeFactoryFactoryMakerGenericMethodHelpersFactory, rather than good, clear, usable code.

I've spent a lot of time writing library-level C++, a reasonable amount of time writing application-level C++, and a reasonable amount of time writing both library and application-level golang.

> But most people aren’t coding language features

It's definitely a tough lever, but supporting generics for the people who are means that the people who aren't can write cleaner code. I think go got it right, eventually.