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

201–210 of 280 posts

Re: Go's Sweet 16

#201

Post by grey-area »

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…

Microservices are entirely unrelated to classes and in no way endemic to go.

Go’s lack of inheritance is one of its bolder decisions and I think has been proven entirely correct in use.

Instead of the incidental complexity encouraged by pointless inheritance hierarchies we go back to structure which bundle data and behaviour and can compose them instead.

Favouring composition over inheritance is not a new idea nor did it come from the authors of Go.

Also the author of Java (Gosling) disagrees with you.

https://www.infoworld.com/article/2160788/why-extends-is-evi...

Re: Go's Sweet 16

#202

Post by [deleted] »

zimpenfish wrote: post #167
culebron21 wrote: post #111

Earlier quoted context omitted.

> `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, you can do `value := myMap[someKey]`, and it will just return a value or nil. It might if your map is a `map[typeA]*typeB` but it definitely won't return a `nil` if your map is anything like `map[typeA]typeC` (where `typeC` is non-nillable; i.e. int, float, string, bool, rune, byte, time.Time, etc.) - you'll get a compile error: "mismatched types typeC and untyped nil".

[deleted]

Re: Go's Sweet 16

#203

Post by gf000 »

morshu9001 wrote: post #155
ttoinou wrote: post #57

Earlier quoted context omitted.

Yeah I’m pretty sure people who say JS is easy don’t know about its Prototype based OOP

You don't have to know about it, but if you do, it's actually simpler than how other languages do OOP.

Not convinced. Especially with property flags.

Re: Go's Sweet 16

#204

Post by gf000 »

zer00eyz wrote: post #42
Xeoncross wrote: post #3

I know they say that your programming language isn't the bottleneck, but I remember sitting there being frustrated as a young dev that I couldn't parse faster in the languages I was using when I learned about Go. It took a few more years before I actually got around to learning it and I have to say I've never picked up a language so quickly. (Which makes sense, it's got the smallest language spec of any of them) I'm…

I write a lot of Go, a bit of Rust, and Zig is slowly creeping in. To add to the above comment, a lot of what Go does encourages readability... Yes it feels pedantic at moments (error handling), but those cultural, and stylistic elements that seem painful to write make reading better. Portable binaries are a blessing, fast compile times, and the choices made around 3rd party libraries and vendoring are all just icing…

Error handling is objectively terrible in Go and the explicitness of the always repeating pattern just makes humans pay less attention to potentially problematic lines and otherwise increases the noise to signal ratio.

Re: Go's Sweet 16

#205

Post by zero_shift »

roncesvalles wrote: post #23
Xeoncross wrote: post #3

I know they say that your programming language isn't the bottleneck, but I remember sitting there being frustrated as a young dev that I couldn't parse faster in the languages I was using when I learned about Go. It took a few more years before I actually got around to learning it and I have to say I've never picked up a language so quickly. (Which makes sense, it's got the smallest language spec of any of them) I'm…

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 learned Go this year, and this assertion just... isn't true? There are a bunch of subtleties and footguns, especially with concurrency.

C++ is a basket case, it's not really a fair comparison.

Re: Go's Sweet 16

#206

Post by reppap »

ashishb wrote: post #31

Contributing to a new Go codebase is easy. The Go codebases look all alike. Not only the language has really few primitives but also the code conventions enforced by standard library, gofmt, and golangci-lint implies that the structure of code bases are very similar. Many language communities can't even agree on the build tooling.

I like that I can understand a Go file without deciphering 15 layers of macros.

Re: Go's Sweet 16

#207

Post by gf000 »

Xeoncross wrote: post #177
vips7L wrote: post #63

Earlier quoted context omitted.

Go is in the same performance profile as Java and C#. There are tons of benchmarks that support this.

1) for one-off scripts and 2) If you ignore memory. You can make about anything faster if you provide more memory to store data in more optimized formats. That doesn't make them faster. Part of the problem is that Java in the real world requires an unreasonable number of classes and 3rd party libraries. Even for basic stuff like JSON marshaling. The Java stdlib is just not very useful. Between these two points, all m…

Memory is the most common tradeoff engineers make for better performance. You can trivially do so yourself with java, feel free to cut down the heap size and Java's GC will happily chug along 10-100 times as often without a second thought, they are beasts. The important metric is that Java's GC will be able to keep up with most workloads, and it won't needlessly block user threads from doing their work. Also, not running the GC as often makes Java use surprisingly small amounts of energy.

As for the stdlib, Go's is certainly impressive but come on, I wouldn't even say that in general case Java's standard library is smaller. It just so happens that Go was developed with the web in mind almost exclusively, while Java has a wider scope. Nonetheless, the Java standard library is certainly among the bests in richness.

Re: Go's Sweet 16

#208

Post by gf000 »

echelon wrote: post #26
Xeoncross wrote: post #15

Earlier quoted context omitted.

Yes, for me I've always pushed the limits of what kinds of memory and cpu usage I can get out of languages. NLP, text conversion, video encoding, image rendering, etc... Rust beats Go in performance.. but nothing like how far behind Java, C#, or scripting languages (python, ruby, typescript, etc..) are from all the work I've done with them. I get most of the performance of Rust with very little effort a fully contain…

Rust is the most defect free language I have ever had the pleasure of working with. It's a language where you can almost be certain that if it compiles and if you wrote tests, you'll have no runtime bugs. I can only think of two production bugs I've written in Rust this year. Minor bugs. And I write a lot of Rust. The language has very intentional design around error handling: Result , Option , match, if let, functio…

> I really want a fast, memory managed, statically typed scripting language somewhere between Rust and Go that's fast to compile like Go, but designed in a safe way like Rust

OCaml is pretty much that, with a very direct relationship with Rust, so it will even feel familiar.

Re: Go's Sweet 16

#209

Post by bccdee »

zer00eyz wrote: post #156
bccdee wrote: post #123

Earlier quoted context omitted.

Nail guns are great because they're instant and consistent. You point, you shoot, and you've unimpeachably bonded two bits of wood. For non-trivial tasks, AI is neither of those. Anything you do with AI needs to be carefully reviewed to correct hallucinations and incorporate it into your mental model of the codebase. You point, you shoot, and that's just the first 10-20% of the effort you need to move past this piece…

> Nail guns are great because they're instant and consistent. You point, you shoot, and you've unimpeachably bonded two bits of wood. You missed it. If I give a random person off the street a nail gun, circular saw and a stack of wood are they going to do a better job building something than a carpenter with a hammer and hand saw? > Anything you do with AI needs to be carefully reviewed Yes, and so does a JR engineer…

> If I give a random person off the street a nail gun, circular saw and a stack of wood

If this is meant to be an analogy for AI, it doesn't make sense. We've seen what happens when random people off the street try to vibe-code applications. They consistently get hacked.

> Yes, and so does a JR engineer

Any junior dev who consistently wrote code like an AI model and did not improve with feedback would get fired.

Re: Go's Sweet 16

#210

Post by gf000 »

bbkane wrote: post #73
MagicMoonlight wrote: post #62

I just can’t get over the idiotic syntax. Instead of “int x” You have “var x int” Which obscures the type, making it harder to read the code. The only justification is that 16 years ago, some guy thought he was being clever. For 99.99% of code, it’s a worse syntax. Nobody does eight levels of pointer redirection in typical everyday code.

I prefer this, especially for more complex types like functions- https://go.dev/blog/declaration-syntax gives an overview of their thought process

"x: int p: pointer to int a: array[3] of int These declarations are clear, if verbose - you just read them left to right. Go takes its cue from here, but in the interests of brevity it drops the colon and removes some of the keywords "

And in the process makes it significantly harder for human eyes to find the boundary between identifier and type.

Post reply on HN