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

51–60 of 305 posts

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

#51

Post by Mesopropithecus »

Veraticus wrote: post #38
Mesopropithecus wrote: post #32

Earlier quoted context omitted.

Comments like this are why I like to joke that the G in Golang stands for gaslighting.

Do you actually have anything of value to add to this discussion? Because this comment is pretty bad.

I have to apologize, I misread the context of "people whining..", which was in fact about those that don't even use the language. If this was not intended to be aggressive, sorry.

Funny though that I did get triggered by it. Out of the Go community I've heard way too often "you don't really need xyz", when they mean "we're not going to support xyz, here's why, and if you disagree, we respectfully ask you to look elsewhere".

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

#52

Post by Veraticus »

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…

Yeah this was my primary complaint with the inclusion of generics. People will try to be all clever and their code will wind up as an unreadable, unmaintainable disaster. It has definitely led to some cool stuff, but I prefer boring, verbose, and clear any day.

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

#53

Post by codyb »

ilyt wrote: post #25
whimsicalism wrote: post #8

Go was successful because it came after decades of pretty much no language putting good networking tools in their stdlib.

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's been around forever, also a fairly simple language. I'd imagine concurrency's easier than on Go.

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

#54

Post by macintux »

ilyt wrote: post #25
whimsicalism wrote: post #8

Go was successful because it came after decades of pretty much no language putting good networking tools in their stdlib.

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.

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

#56

Post by dewey »

stpedgwdgfhgdd wrote: post #27

Worked with Go over 6 years; my biggest annoyance at the beginning, verbosity of error handling, has mostly gone away. In most cases the explicit error handling helped us hardening the code. What does still bother me is the lack of proper enum support. I remember when Java boosted their enum support and the way it impacted the quality of the code. Sure would love to see something similar in Go.

Fully agree with your points. In my experience if people flag error handling it almost always means they didn't spend enough time with the language yet, as in the day to day work it's a non-issue.

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

#57

Post by softirq »

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

In under a decade Go swept up entire markets with a simple, down to earth language you can learn in a day and keep in your head. It optimized for the masses and the common cases and has absolutely eaten the lunch of these languages with lauded type systems that takes several courses in formal logic to even get started with.

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

#58

Post by marssaxman »

unmole wrote: post #45
marssaxman wrote: post #39

Earlier quoted context omitted.

> the DX of Algorithms and Data Structures sorry, what does this phrase mean?

DX is Developer Experience .

Thanks! I had vaguely imagined it might be related to differentials.

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

#59

Post by adtac »

ilyt wrote: post #30
veber-alex wrote: post #23

Earlier quoted context omitted.

a, err := f() if err != nil { return } a, err = f() This will compile.

a isn't used so it won't ;p Honestly the thing that I think lacks more is macros. With macros it would be trivial to write a := Must!(f()) that * assigns last return value to err * calls return with that error if it is not nil

    b, err := os.ReadFile(path)
    if err != nil {
      return nil, fmt.Errorf("read %s: %w", path, err)
    }
is so much better than

    b := Must!(os.ReadFile(path))
because when things go wrong, I have exactly the right amount of information I want. Assigning to err magically (it's not even mentioned in the source code) is exactly the kind of thing that'll turn out to be the cause of a subtle bug 6 months later. Why not spend the a couple of extra lines thinking about the error when the context is still in your head?

Additionally I like how error handling acts as a visual delimiter, especially when you use meaningful fmt.Errorfs as strings are usually highlighted with a different colour, making it easy to quickly jump through code.

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

#60

Post by rowanseymour »

Veraticus wrote: post #35
rowanseymour wrote: post #17

Earlier quoted context omitted.

Prior to generics we relied heavily on dynamic typing via interface{}, for example: BulkInsert(db *sql.DB, objs []interface{}) This unfortunately meant that any time you had []Foo.. you had to allocate a new []interface{} and copy over the items. Now a function like that can look like: BulkInsert[T any](db *sql.DB, objs []T) And we're not wasting CPU cycles to copy the slice of []Foo. I'm struggling to see how that's…

Dynamic typing via interface{} is also huge Go code smell though, so... Generics are definitely better for you. But I would say the overall pattern you're employing of bulk inserting different kinds of data structures with one function is the problem. Of course, I don't know your code so I'm sure you have a good reason for choosing what you did, but a BulkInsert of Any certainly made me raise my eyebrow.

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.
Post reply on HN