Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go's Sweet 16

go.dev

Post reply on HN
Print view View original

141–150 of 280 posts

Re: Go's Sweet 16

#141

Post by tptacek »

9rx wrote: post #92
culebron21 wrote: post #87

To me, Go is like Rust oversimplified beyond reason. It edits your code when you don't ask, removing things you just started; it lacks iterators -- every time you must write a big cycle instead. It lacks simple things like check if a key exists in a map. Proponents say it has nothing under the hood. I see under-the-hood-magic happen every time. 1) The arrays append is one example. Try removing an element from an arra…

> proper enums It has proper enums. Granted, it lacks an enum keyword, which seems to trip up many. Perhaps what you are actually looking for is sum types? Given that you mentioned Rust, which weirdly[1] uses the enum keyword for sum types, this seems likely. Go does indeed lack that. Sum types are not enums, though. > sensible arrays & slices, without any magic and awkward syntax Its arrays and slices are exactly th…

I wish Go had sum types too. But I like being able to write a mutable tree structure without first having to read a whole book on the subject and inventing a new system of pointers. Every language is tradeoffs.

Re: Go's Sweet 16

#142

Post by ModernMech »

arccy wrote: post #120
ModernMech wrote: post #69

Earlier quoted context omitted.

That's not the point, no one uses 99% of languages, so if that's the standard then it's a free-for-all. The PL community is small, so norms are important. PL naming code is: 1. Whoever uses the name first, has claim to the name. Using the name first is measured by: when was the spec published, or when is the first repo commit. 2. A name can be reused IFF the author has abandoned the original project. Usually there's…

Like how C and C# are different languages, Go and Go! are different. There's not name reuse here.

Go and Go! are pronounced the same way, so yes, they're the same.

Moreover the author of Go! personally requested that Google not step on his life's work. The man had dedicated a decade and authored a book and several papers on the topic, so it wasn't a close call. Additionally C# built on C++ which built on C. Go had no relationship to Go! at all. Homage and extension are one thing, but Go was not that.

A policy of "do no evil" required Google to acquiesce. Instead they told him to pound sand.

Re: Go's Sweet 16

#143

Post by zimpenfish »

egl2020 wrote: post #37
roncesvalles wrote: post #23

Earlier quoted context omitted.

The nice thing about Go is that you can learn "all of it" in a reasonable amount of time: gotchas, concurrency stuff, everything. There is something very comforting about knowing the entire spec of a language. I'm convinced no more than a handful of humans understand all of C# or C++, and inevitably you'll come across some obscure thing and have to context switch out of reading code to learn whatever the fuck a "part…

I've been writing go professionally for about ten years, and with go I regularly find myself saying "this is pretty boring", followed by "but that's a good thing" because I'm pretty sure that I won't do anything in a go program that would cause the other team members much trouble if I were to get run over by a bus or die of boredom. In contrast writing C++ feels like solving an endless series of puzzles, and there is…

> I'm pretty sure that I won't do anything in a go program that would cause the other team members much trouble

Alas there are plenty of people who do[0] - for some reason Go takes architecture astronaut brain and wacks it up to 11 and god help you if you have one or more of those on your team.

[0] flashbacks to the interface calling an interface calling an interface calling an interface I dealt with last year - NONE OF WHICH WERE NEEDED because it was a bloody hardcoded value in the end.

Re: Go's Sweet 16

#144

Post by zerr »

tptacek wrote: post #141
9rx wrote: post #92

Earlier quoted context omitted.

> proper enums It has proper enums. Granted, it lacks an enum keyword, which seems to trip up many. Perhaps what you are actually looking for is sum types? Given that you mentioned Rust, which weirdly[1] uses the enum keyword for sum types, this seems likely. Go does indeed lack that. Sum types are not enums, though. > sensible arrays & slices, without any magic and awkward syntax Its arrays and slices are exactly th…

I wish Go had sum types too. But I like being able to write a mutable tree structure without first having to read a whole book on the subject and inventing a new system of pointers. Every language is tradeoffs.

As a C++ dev, such comments reinforce my hesitation to pick up either Go or Rust seriously :) It seems I already have the golden middle after all.

Re: Go's Sweet 16

#145

Post by zerr »

tschellenbach wrote: post #2

10 week onboarding program we use here for go backend devs: https://www.reddit.com/r/golang/comments/1eiea6q/10_week_pla... go is amazing. switches from python to go 7 years ago. It's the reason our startup did well

One thing I don't like when it comes to Golang jobs - it is rare to see pure software engineering positions. For some reason, most Go jobs requirements include AWS, Kubernetes/Docker, CI/CD setup, etc... DevOps stuff, which is not the case for positions in other stacks.

Re: Go's Sweet 16

#146

Post by nicodjimenez »

wanderlust123 wrote: post #48
nicodjimenez wrote: post #47

Golang to me is a great runtime and very poor language. I could maybe get used to the C pointer-like syntax and to half of my code checking if err != nil, but the lack of classes is a step too far. The Golang idiomatic approach is to have a sprawling set of microservices talking to each other over the network, to manage complexity instead of having classes. This makes sense for things like systems agents (eg K8) but…

I think lack of classes is highly desirable. So much enterprise code is poorly put together abstractions. I think go needs some more functional aspects, like iterators and result type/pattern matching.

The solution to bad abstractions it not to make it very difficult to create abstractions at all. For systems code I think it's fine but for application code you probably want some abstractions or else it's very hard to scale a codebase.

Re: Go's Sweet 16

#147

Post by EnergyAmy »

tptacek wrote: post #141
9rx wrote: post #92

Earlier quoted context omitted.

> proper enums It has proper enums. Granted, it lacks an enum keyword, which seems to trip up many. Perhaps what you are actually looking for is sum types? Given that you mentioned Rust, which weirdly[1] uses the enum keyword for sum types, this seems likely. Go does indeed lack that. Sum types are not enums, though. > sensible arrays & slices, without any magic and awkward syntax Its arrays and slices are exactly th…

I wish Go had sum types too. But I like being able to write a mutable tree structure without first having to read a whole book on the subject and inventing a new system of pointers. Every language is tradeoffs.

I like the language saying "it's not as easy as you think" when I'm about to do something ill-advised like roll my own mutable tree structure.

Re: Go's Sweet 16

#148

Post by lenkite »

culebron21 wrote: post #111
Mawr wrote: post #107

Earlier quoted context omitted.

> it lacks iterators -- every time you must write a big cycle instead It has iterators - https://pkg.go.dev/iter . > It lacks simple things like check if a key exists in a map. What? `value, keyExists := myMap[someKey]` > Try removing an element from an array - you must rely on some magic and awkward syntax, and there's no clear explanation what actually happens under the hood (all docs just show you that a slice is…

> `value, keyExists := myMap[someKey]` If I don't need the value, I have to do awkward tricks with this construct. like `if _, key_exists := my_may[key]; key_exists { ... }`. Also, you can do `value := myMap[someKey]`, and it will just return a value or nil. Also, if the map has arrays as elements, it will magically create one, like Python's defaultdict. This construct (assigning from map subscript) is pure magic, de…

> Also, if the map has arrays as elements, it will magically create one, like Python's defaultdict.

Err, no Go doesn't do that. No insertion happens unless you explicitly assign to the key.

Re: Go's Sweet 16

#149

Post by estebank »

Measter wrote: post #83
throw1111221 wrote: post #54

Earlier quoted context omitted.

Just because it was a design goal doesn't mean it succeeded ;) From Russ Cox this time: "Q. What language do you think Go is trying to displace? ... One of the surprises for me has been the variety of languages that new Go programmers used to use. When we launched, we were trying to explain Go to C++ programmers, but many of the programmers Go has attracted have come from more dynamic languages like Python or Ruby."…

It's interesting that I've also heard the same from people involved in Rust. Expecting more interest from C++ programmers and being surprised by the numbers of Ruby/Python programmers interested. I wonder if it's that Ruby/Python programmers were interested in using these kinds of languages but were being pushed away by C/C++.

The people writing C++ either don't need much convincing to switch because they see the value or are unlikely to give it up anytime soon because they don't see anything Rust does as being useful to them, very little middle ground. People from higher level languages on the other hand see in Rust a way to break into a space that they would otherwise not attempt because it would take too long a time to reach proficiency. The hard part of Rust is trying to simultaneously have hard to misuse APIs and no additional performance penalty (however small). If you relax either of those goals (is it really a problem if you call that method through a v-table?), then Rust becomes much easier to write. I think GC Rust would already be a nice language to use that I'd love, like a less convoluted Scala, it just wouldn't have fit in a free square that ensured a niche for it to exist and grow, and would likely have died in the vine.

Re: Go's Sweet 16

#150

Post by lenkite »

culebron21 wrote: post #87

To me, Go is like Rust oversimplified beyond reason. It edits your code when you don't ask, removing things you just started; it lacks iterators -- every time you must write a big cycle instead. It lacks simple things like check if a key exists in a map. Proponents say it has nothing under the hood. I see under-the-hood-magic happen every time. 1) The arrays append is one example. Try removing an element from an arra…

> This makes you split functions in many pieces, turning your code into enterprise Java.

Umm..in Java you won't have to split functions here. Maybe you should study some modern Java ?

Post reply on HN