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

121–130 of 280 posts

Re: Go's Sweet 16

#121

Post by osigurdson »

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'm sure there are plenty of reasons this is wrong, but it feels like Go gets me 80% of the way to Rust with 20% of the effort.

By 20% of the effort, do you mean learning curve or productivity?

Re: Go's Sweet 16

#122

Post by rollulus »

I love Go. It makes that I get shit done. I picked up Go more than ten years ago, because it was HN’s darling and when I didn’t know about hype cycles. No regrets.

Re: Go's Sweet 16

#123

Post by bccdee »

zer00eyz wrote: post #66
cwbriscoe wrote: post #55

Earlier quoted context omitted.

Error handling isn't even a pain to write any more with AI autocomplete which gets it right 95%+ of the time in my experience.

You're not wrong but... there is a large contingent of the Go community that has a rather strong reaction to AI/ML/LLM generated code at any level. I keep using the analogy, that the tools are just nail guns for office workers but some people remain sticks in the mud.

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 of code. Some people like this tradeoff, and fair enough, but that's nothing like a nailgun.

For trivial tasks, AI is barely worth the effort of prompting. If I really hated typing `if err != nil { return nil, fmt.Errorf("doing x: %w", err) }` so much, I'd make it an editor snippet or macro.

Re: Go's Sweet 16

#124

Post by goranmoomin »

jchw wrote: post #25
morshu9001 wrote: post #24

Earlier quoted context omitted.

This is also what I like about JS, except it's even easier than Go. Meanwhile Python has a surprising number of random features.

Just so we're on the same page, this is the current JS spec: https://262.ecma-international.org/16.0/index.html I don't agree. (And frankly don't like using JS without at least TypeScript.)

While I might not think that JS is a good language (for some definition of a good language), to me the provided spec does feel pretty small, considering that it's a language that has to be specified to the dot and that the spec contains the standard library as well.

It has some strange or weirdly specified features (ASI? HTML-like Comments?) and unusual features (prototype-based inheritance? a dynamically-bounded this?), but IMO it's a small language.

Re: Go's Sweet 16

#125

Post by Someone »

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…

> Which makes sense, it's got the smallest language spec of any of them

I think go is fairly small, too, but “size of spec” is not always a good measure for that. Some specs are very tight, others fairly loose, and tightness makes specs larger (example: Swift’s language reference doesn’t even claim to define the full language. https://docs.swift.org/swift-book/documentation/the-swift-pr...: “The grammar described here is intended to help you understand the language in more detail, rather than to allow you to directly implement a parser or compiler.”)

(Also, browsing golang’s spec, I think I spotted an error in https://go.dev/ref/spec#Integer_literals. The grammar says:

  decimal_lit    = "0" | ( "1" … "9" ) [ [ "_" ] decimal_digits ] .
Given that, how can 0600 and 0_600 be valid integer literals in the examples?)

Re: Go's Sweet 16

#126

Post by trenchpilgrim »

tail_exchange wrote: post #8

I was very skeptical of Go when I started learning it, but it quickly became my favourite language. I like how simple but powerful it is. If I had a magic wand, the only things I would add is better nulability checks, add stack traces by default for errors, and exhaustive checks for sum types. Other than that, it does everything I want.

> better nulability checks

In development: https://github.com/uber-go/nilaway

Re: Go's Sweet 16

#127

Post by dmoy »

Mawr wrote: post #105
the_gipsy wrote: post #84

Earlier quoted context omitted.

> This is why unused dependencies are a compile time error. https://go.dev/doc/faq?utm_source=chatgpt.com#unused_variabl... > There are two reasons for having no warnings. First, if it’s worth complaining about, it’s worth fixing in the code. (Conversely, if it’s not worth fixing, it’s not worth mentioning.) Second, having the compiler generate warnings encourages the implementation to warn about weak cases that can…

Yeah, but just going back to warnings would be a regression. I believe the correct approach is to offer two build modes: release and debug. Debug compiles super fast and allows unused variables etc, but the resulting binary runs super slowly, maybe with extra safety checks too, like the race detector. Release is the default, is strict and runs fast. That way you can mess about in development all you want, but need to…

> Debug compiles super fast and allows unused variables etc, but the resulting binary runs super slowly, maybe with extra safety checks too, like the race detector.

At least in the golang / unused-vars at Google case, allowing unused vars is explicitly one of the things that makes compilation slower.

In that case it's not "faster compilation as in less optimization". It's "faster compilation as in don't have to chase down and potentially compile more parts of a 5,000,000,000 line codebase because an unused var isn't bringing in a dependency that gets immediately dropped on the floor".

So it's kinda an orthogonal concern.

Re: Go's Sweet 16

#128

Post by pclmulqdq »

kermatt wrote: post #36
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'm convinced no more than a handful of humans understand all of C# or C++ How would the proportion of humans that understand all of Rust compare?

I'm pretty convinced that nobody has a full picture of Rust in their head. There isn't even a spec to read.

Re: Go's Sweet 16

#129

Post by neild »

Someone wrote: post #125
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…

> Which makes sense, it's got the smallest language spec of any of them I think go is fairly small, too, but “size of spec” is not always a good measure for that. Some specs are very tight, others fairly loose, and tightness makes specs larger (example: Swift’s language reference doesn’t even claim to define the full language. https://docs.swift.org/swift-book/documentation/the-swift-pr... : “The grammar described he…

0600 and 0_600 are octal literals:

    octal_lit      = "0" [ "o" | "O" ] [ "_" ] octal_digits .

Re: Go's Sweet 16

#130

Post by baby »

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…

It really is a lovely language and ecosystem of tools, I think it does show its limitations fairly quickly when you want to build something a bit complex though. Really wish they would have added sumtypes
Post reply on HN