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

31–40 of 305 posts

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

#31

Post by xchkr1337 »

veber-alex wrote: post #21
fsociety wrote: post #18

Earlier quoted context omitted.

Nil is a carefully chosen name in Go, and was a trade-off which was made. It’s not quite right to compare it to null in other languages. I agree it is not as safe as a language like Rust, however it was the right trade-off to make in my opinion. The main protection you have against nil pointers are nil receivers, and knowing when to use reference semantics vs value semantics.

What's the tradeoff? what advantage having null pointers give?

default values for everything without significantly increasing language complexity

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

#32

Post by Mesopropithecus »

Veraticus wrote: post #10

Very insightful. Re: the generics point — As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic. I’m glad generics were implemented, if only to silence the chorus of people who didn’t even use Go but whined about the lack of them. Their inclusion has simplified the stdlib and led to some cool new functi…

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

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

#33

Post by wolfspaw »

Veraticus wrote: post #10

Very insightful. Re: the generics point — As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic. I’m glad generics were implemented, if only to silence the chorus of people who didn’t even use Go but whined about the lack of them. Their inclusion has simplified the stdlib and led to some cool new functi…

A PL without Generics is just Terrible DX for me, let me abstract the types in my Algorithms and Data Structures Goddammit!

Now Golang is saved, with Generics it's actually an Awesome Incredible PL.

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

#34

Post by stefncb »

recursive wrote: post #6
Pxtl wrote: post #5

Earlier quoted context omitted.

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…

The documentation for DBNull [1] seems to have some idea that DBNull represents something entirely different. > Do not confuse the notion of null in an object-oriented programming language with a DBNull object. In an object-oriented programming language, null means the absence of a reference to an object. DBNull represents an uninitialized variant or nonexistent database column. For all the explanation though, I coul…

I don't know C#, but I'll take a guess:

I think it's exactly the same issue as null in Lisp and Lua — you sometimes want to differentiate between null as in "I returned no value", and null as in "I returned the fact that there is no value". Or null vs false vs empty list in the context of Lisp.

This distinction becomes very clear (and sometimes very annoying) when you realize that in Lua, setting a table key to null completely removes it, so there's no way to store the concept of a missing value unless you define a special value (like DBNull). A slot being null literally signifies its absence.

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

#35

Post by Veraticus »

rowanseymour wrote: post #17
Veraticus wrote: post #10

Very insightful. Re: the generics point — As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic. I’m glad generics were implemented, if only to silence the chorus of people who didn’t even use Go but whined about the lack of them. Their inclusion has simplified the stdlib and led to some cool new functi…

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.

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

#36

Post by Veraticus »

icholy wrote: post #15
Veraticus wrote: post #10

Very insightful. Re: the generics point — As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic. I’m glad generics were implemented, if only to silence the chorus of people who didn’t even use Go but whined about the lack of them. Their inclusion has simplified the stdlib and led to some cool new functi…

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

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

#37

Post by synergy20 »

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 really hope Go can have a GUI in its stdlib, something like what Flutter/Dart does: adding a Skia kind of engine and let me do GUI cross platform, that will make Go main stream like wild fire.

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

#38

Post by Veraticus »

Mesopropithecus wrote: post #32
Veraticus wrote: post #10

Very insightful. Re: the generics point — As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic. I’m glad generics were implemented, if only to silence the chorus of people who didn’t even use Go but whined about the lack of them. Their inclusion has simplified the stdlib and led to some cool new functi…

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.

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

#39

Post by marssaxman »

wolfspaw wrote: post #28

Go has turned into an Awesome language. I'm one of those that cannot use a PL that has no generics... It kills the DX of Algorithms and Data Structures. Now it has Generics, soft RT GC, and it might even get official Arena Allocation. I /LOVED/ the Matklad comment of |error handling converging|, indeed -- it seems that PL community evolved to "any-error" + annotation-at-call-site.

> the DX of Algorithms and Data Structures

sorry, what does this phrase mean?

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

#40

Post by adtac »

crop_rotation wrote: post #7

The stdlib is the killer feature of go. Several times I wrote high enough performance small services/servers that people not familiar with go were astounded with (mostly the speed of writing the code and memory usage). I made many go converts this way. And I always only had to use the stdlib (many benefits when writing within a company).

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 fast compile time to be the most important.

[1] Readability of not just your code: being able to go-to-definition into stdlib and immediately understanding it without having to grok a million unrelated decorators/FactoryFactoryFactory/std::_Vector_iterator>> is incredible

Post reply on HN