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

101–110 of 305 posts

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

#101

Post by z0r »

Veraticus wrote: post #69
rowanseymour wrote: post #60

Earlier quoted context omitted.

The reason is the same reason that anyone ever writes a generic function (outside of writing a library) - to keep code DRY and avoid duplication. There is no upside to maintaining a large number of identical function implementations, and no scenario in which that is preferable to using generics.

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.

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

#102

Post by tomcam »

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…

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

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

#104

Post by ducktective »

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…

Your "entry level" dev finished a non-trivial Go app in about an hour without knowing anything about Go? Literally how?

Also he learned enough Clojure to mess around in, again with 0 knowledge about it. Again impressive. Or is this industry standard competency in some fields?

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

#105

Post by tredre3 »

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.

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

So you deliberately added complexity instead of using Go's own build system and it didn't work out well and that's somehow a proof that Go's cross-compilation story isn't as great as people say?

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

#106

Post by stevemk14ebr »

"What I got right...Using capitalization for the public/private distinction in functions, methods, variables, and fields"

I disagree with this strongly. Due to this when you need to change one of these things to the opposite it involves changing every use site as well. This has far reaching implications for refactoring, wrapping external code when you really do need to expose its guts, etc. Any time you need to do this in a non-manual fashion you're required to parse all of the code exactly perfectly (ASTs and such). Even go itself has not figured out how to do this, rf is still experimental and not complete: https://pkg.go.dev/rsc.io/rf.

Example use case: https://github.com/golang/go/issues/46792

I much prefer the non-viral public/private attributes other languages use.

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

#107

Post by synergy20 »

citrusybread wrote: post #49
synergy20 wrote: post #37

I learned Go on and off in recent years on the side(daily job does not need Go), I like its battery included stdlib and cross platform support. I do feel its binary size is large comparing to c and c++, and multiple Go executable can not share libraries as easily as how c/c++ uses the shared lib, when I have a few Go binaries they add up, and I do storage constrained embedded development a lot. On the desktop side, I…

>multiple Go executable can not share libraries as easily as how c/c++ uses the shared lib https://pkg.go.dev/cmd/go#hdr-Build_modes you can actually build with shared libraries :) I think most people I've seen use go, only use a single application, or have it turned into a docker container; so for them this is pointless but just fyi. I personally dislike static linking but I see why it was used so heavily with go.

not really, it's not something Golang really cares a lot to say the least, to become 'mainstream', Golang actually has to embrace more use cases.

https://github.com/golang/go/issues/47788

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

#108

Post by macintux »

drBonkers wrote: post #76
macintux wrote: post #54

Earlier quoted context omitted.

Erlang had a better concurrency story than Go, and better error handling. But alas marketing wins.

Erlang is dynamically typed.

True, and Go has a much better story in some other areas, but “…if you needed to make a highly concurrent network app you had to get into asynchronous programming that generally makes code looks shit” is inaccurate.

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

#109

Post by orwin »

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…

First time I used it, I called it 'C+-' after two weeks and a supervisord clone, but I really liked the language (except the module system). It was ~9 years ago, and other than that I only used it in coding interviews, as it's portable, simple, close enough to C that I'm not lost using it, yet simple enough that I don't introduce bugs carelessly every 30 loc.

But it's a bit boring and I'll never use it for personal projects.

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

#110

Post by tsss »

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 "swept up entire markets" because they have an unlimited marketing budget. It has nothing to do with the merits of the language itself.
Post reply on HN