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

Thirteen Years of Go

go.dev

Post reply on HN
Print view View original

81–90 of 217 posts

Re: Thirteen Years of Go

#81

Post by galangalalgol »

andrewmcwatters wrote: post #65

Go has almost everything going for it. I only wish it was a bit more C-like and you had the ability to run it without a garbage collector, and that it was more suitable for systems and embedded programming. Perhaps one day someone will come up with an implementation of Go that doesn’t use a GC. It’s just such an incredible language, and it deserves the type of Rust fanaticism that Rust has, but I suspect Go users are…

Just got told about tinygo on another thread where I was saying rust is the obvious only choice. But tinygo looks nice. I've written very little go professionally, and rust only for a few months more. Go does seem super easy. But rust doesn't really seem hard either. And the fearless concurrency is really attractivento not have to think much about data races too much.

Either one is nicer than c++ which I have a quarter century of experience at.

Re: Thirteen Years of Go

#82

Post by rahen »

andrewmcwatters wrote: post #65

Go has almost everything going for it. I only wish it was a bit more C-like and you had the ability to run it without a garbage collector, and that it was more suitable for systems and embedded programming. Perhaps one day someone will come up with an implementation of Go that doesn’t use a GC. It’s just such an incredible language, and it deserves the type of Rust fanaticism that Rust has, but I suspect Go users are…

> I only wish it was a bit more C-like and you had the ability to run it without a garbage collector

"import C, import unsafe".

You absolutely can, at least for performance critical sections where you cannot afford garbage collection.

https://dgraph.io/blog/post/manual-memory-management-golang-...

Re: Thirteen Years of Go

#83

Post by dangoor »

pipeline_peak wrote: post #71

Why exactly is Go so special? For a compiled language it's not very fast and doesn't seem to be making much traction. I think people simply like it because of it's Bell Labs heritage and pretty syntax.

Your comment has been good at generating some discussion around what makes Go special.

Since the sibling comments already addressed everything else, I'll talk about this one:

> For a compiled language it's not very fast

This is essentially true, _but_ a lot of Go users are coming from Python, JavaScript, and maybe Ruby and Go is much faster. Additionally, it comes _close enough_ to Java while typically having a much smaller memory footprint that it really performs quite well in a cloud environment.

Re: Thirteen Years of Go

#84

Post by Laiho »

dontlaugh wrote: post #76
tptacek wrote: post #51

Earlier quoted context omitted.

I keep count in my own code of the number of bugs Go's "damnable use requirement" has caught for me, and I'm now up to 5. It's not a big number, but they were real bugs that would have annoyed the shit out of me if they'd made it into shipping code. I think this is one of the polarizing decisions Go made that is going to turn out to be universal orthodoxy 10 years from now. I think error handling is the thing about G…

The biggest problem with the error handling is that it's not composable. It's better than unchecked exceptions, but that's not saying much. The second problem is nil, use of which is common and doesn't enforce error handling.

I find it inconstant to be so pedantic about unused vars/imports to avoid bugs, but then leave error handling to what it is.

Re: Thirteen Years of Go

#85

Post by dimgl »

pipeline_peak wrote: post #71

Why exactly is Go so special? For a compiled language it's not very fast and doesn't seem to be making much traction. I think people simply like it because of it's Bell Labs heritage and pretty syntax.

> For a compiled language it's not very fast

…really? Go seems blazing fast to me…

Re: Thirteen Years of Go

#86

Post by valenterry »

seanw444 wrote: post #56
valenterry wrote: post #36

Earlier quoted context omitted.

Simply because it's limiting. Which is good if you are inexperienced, but not so great once you grow and try to become more productive. A more expressive language is a must then or you'll be stuck. For some people it's this feeling of being stuck that they don't like - others can live with it more easily. > I honestly also have no idea why Rust always makes an appearance in a Go thread Both Rust and Go people are ver…

The language is limited , but I do not find it limiting .

That's okay! You should use what you like. People are different, otherwise we would all use the same few languages.

Re: Thirteen Years of Go

#87

Post by valenterry »

rob74 wrote: post #60
valenterry wrote: post #36

Earlier quoted context omitted.

Simply because it's limiting. Which is good if you are inexperienced, but not so great once you grow and try to become more productive. A more expressive language is a must then or you'll be stuck. For some people it's this feeling of being stuck that they don't like - others can live with it more easily. > I honestly also have no idea why Rust always makes an appearance in a Go thread Both Rust and Go people are ver…

> Which is good if you are inexperienced, but not so great once you grow and try to become more productive. A more expressive language is a must then or you'll be stuck. Ok, I get it that there are developers that can't live with languages that don't have tons of shiny features to play with, but please don't disparage the others as "inexperienced"! If you have ever gone back to some "expressive" code you wrote months…

It's not "shiny features". It's things that can make you more productive. Or would you say golang's channls are also a shiny feature?

Also, I'm not "disparaging" anyone here. Please read it again and notice that I was simply saying that golang is good if you are inexperienced. That does not mean that every golang dev is inexperienced. If you interpreted my post in that way, I think you should probably ask yourself why that is.

Re: Thirteen Years of Go

#88

Post by KingOfCoders »

Xeoncross wrote: post #43

I've enjoyed writing Go for years. However, it's not been the language that does it for me. It's been the combination of features and ecosystem that makes it a default. It's hard to explain, but the language is one you can throw into a team of random developers and come out with benchmarks, tests, CI/CD pipelines, unified code formatting, and good parallel work models (via goroutines) almost every time. Builds are in…

I currently write a SaaS website in Go after doing quite some Rust. I do prefer Rust as a language - it's more expresive and I greatly prefer Result over error, but it has two major downsides for me compared to Go. First compilation is much slower and Go feels like a non-compiled language because of the compilation speed (my last startup I've used Scala with horrendous compilation speeds, the main reason not to use it) The second is the borrow checker. It's excellent mostly (love explicit mut) but fails for me for structs with sub-structs coming from different owners. Very fast you have Arc noise everywhere. The Go GC just works. A simple GC as a -gc=on with auto-arc for variables without lifetime annotations for people that don't need Rust for embedded applications would be a dream come true.

I do love 'import "embed"' in Go to embed web files (templates) inside a binary and then deploy/manage that one binary with systemd with zero downtime updates with systemd port activation. Slick.

Re: Thirteen Years of Go

#89

Post by nogridbag »

makestuff wrote: post #57
Xeoncross wrote: post #43

I've enjoyed writing Go for years. However, it's not been the language that does it for me. It's been the combination of features and ecosystem that makes it a default. It's hard to explain, but the language is one you can throw into a team of random developers and come out with benchmarks, tests, CI/CD pipelines, unified code formatting, and good parallel work models (via goroutines) almost every time. Builds are in…

Yeah I was at a startup where maybe 10% of engineering had used go before and 20% had used Java before (it was a PHP monolith so most people were PHP developers). The Java code that was written was pretty awful (I was hired probably due to my java experience, so I had a decent idea of good java). However, the Go services were actually really good. There is something about having a simple language that works really we…

I think the main difference is there's just an order of magnitude more awful Java devs than Go developers due to Java being the most popular backend language for N years.

If the timeline was flipped and Java was the new language on the block while Go had been around for 25 years, I bet you'd see the quality of Java code was vastly superior simply due to Java attracting passionate developers interested in learning new technology.

I still see Java devs with 15-20 years "experience" coding like 1st year CS students. It really wouldn't matter what language they were coding in.

Re: Thirteen Years of Go

#90

Post by Beltalowda »

throwawaaarrgh wrote: post #70
pyentropy wrote: post #28

Earlier quoted context omitted.

Go is the best documented ecosystem I've seen. Since godoc is so widespread, people write doc comments and examples all the time. Every single public project has a doc page at pkg.go.dev too. The syntax rules and the reference spec of the language is very concise too.

Then you clearly have been living with some crap ecosystems. Go is very poorly documented. Basic functionality that is hidden behind environment variables isn't documented at all sometimes. Just figuring out how to compile an app statically took searching through four docs and guessing. The build and install options don't even result in a binary half the time and its not clear why.

The number of flags required to statically compile stuff when using cgo is indeed a bit complex (if you're not using cgo it will always statically compile), partly because interfacing with C is a bit complex.

There is an issue to make it easier[1], and doesn't seem too hard to find more information about it[2].

More general: I think I've seen every language described as "badly documented" at this point. Someone new comes to the language, knows what they want to do, gets stuck/frustrated because it's a little bit outside the "mainstream path", and calls it "badly documented".

[1]: https://github.com/golang/go/issues/26492

[2]: https://duckduckgo.com/?q=go+compile+static

Post reply on HN