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

131–140 of 217 posts

Re: Thirteen Years of Go

#131

Post by kaba0 »

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…

Go is not really an easier language than Java, though.

Re: Thirteen Years of Go

#132

Post by AnimalMuppet »

lghh wrote: post #105
AnimalMuppet wrote: post #95

Earlier quoted context omitted.

> > it's Bell Labs heritage > I have never met a person (in person, offline) who has cared about this at all. People care about it because the language has the Bell Labs "feel". They don't care about it the way a dog breeder would care about a dog's ancestry. (And of those who care about the "feel", some view it as a positive, others as a negative...)

> People care about it because the language has the Bell Labs "feel" I'm not attacking, I am honestly asking: What does that mean? That it feels C-like? Or something different? A lot of languages are C-like in syntax, so Go is not exactly unique in that aspect.

The difference between C and Pascal was a certain pragmatism. Pascal (at least the original) could make it hard or impossible to do certain things. C let you do things, even things that the language designers hadn't thought of.

The difference was that C was written by people who were trying to write an OS, and they had to create a language that was able to handle all the odd things involved, like writing directly to hardware. Pascal really didn't want you to do that.

I'm not saying that Go lets you talk directly to hardware - I don't know whether it does or not. But I think that Go has the "get out of the programmers way and let them write code" approach more than, say, Haskell, or even Rust. That (plus the C-like syntax) probably is the Bell Labs feel.

Re: Thirteen Years of Go

#133

Post by kaba0 »

Xeoncross wrote: post #112
za3faran wrote: post #109

Earlier quoted context omitted.

Java is the new Java :) With features like records, virtual threads, pattern matching, sealed types, string templates, and more to come, it's shaping up very nicely.

The compile times and the fact it takes 10x the memory for a lot of services is certainly something I would like to see addressed. Not to mention that Java for things like serverless has painfully slow startup times. Java runs nice and quick when it's ready, but it's slow to get there and quite a memory hog.

Compile times? Besides gradle’s startup time, java compiles just as fast as go imo. Go barely does any optimization, but javac does even less - so I don’t really see it a problem on actually similarly sized projects.

Memory usage is a tradeoff — a good GC works best with a bit more overhead.

Re: Thirteen Years of Go

#134

Post by anderspitman »

Go has been my default language for a couple years now. I don't use it for everything, but I use it for most things.

It makes some of the best tradeoffs I've ever seen, which is maybe the highest praise I can give as an engineer.

Re: Thirteen Years of Go

#135

Post by smasher164 »

kaba0 wrote: post #128
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…

Error handling is strictly worse than pretty much any other language out there — you are only making you believe that you are handling your error cases. A pragmatic “handle it here or bubble it up” is a much better approach, as more often than not you can’t actually handle the error at call site. Goroutines in themselves won’t give you actually correct concurrency. I really hope that Go doesn’t replace Java.

> A pragmatic “handle it here or bubble it up” is a much better approach

This is exactly the approach used in Go code, so I'm not sure what you're referring to. If you're talking about the fact that you can technically ignore an error result like

    res, _ := doWork()
then that's a fair point. But we still have https://staticcheck.io/docs/checks#SA4006 for that.

Re: Thirteen Years of Go

#136

Post by tgv »

origin_path wrote: post #123
tgv wrote: post #100

Earlier quoted context omitted.

I never got the feeling it was slower than Java, but I've only used the standard JVM. In benchmarks, they don't really differ. But the memory footprint is amazing. I've got three servers plus up to 10 test environments running on one small VPS (Virtual Private Server), and everything runs as smooth as can be; memory usage stays below 1GB, leaving enough space for the db server. In a previous job, we had a Java/Tomcat…

The reason the Tomcat filled memory is that for the longest time Java would only run GCs if you were actually running out of memory. The assumption was, if there's RAM there doing nothing then why would you waste CPU and electricity on cleaning up the heap. If you needed that RAM for something else, OK, tell the JVM there's a cap on how much it can use. It'll then do enough GC work to use that much (ish). The problem…

I think Go shows that that's a false dichotomy. Go can GC very quickly, almost without pauses, and the pauses are sub millisecond. That should be fast enough for almost all backends. Capping isn't great, although doable if you've got a steady workload.

Re: Thirteen Years of Go

#137

Post by kaba0 »

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…

What exactly is fantastic about it, objectively? I really can’t come up with anything besides goroutines. It’s quite inexpressive and is pretty much like the litany of other managed languages (I am honestly baffled how it gets compared to Rust — wouldn’t you be surprised if someone was going on about C vs JS? That’s the same thing)

Re: Thirteen Years of Go

#138

Post by traceroute66 »

gw98 wrote: post #63
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…

Agree on all points. I'd like to add that it just tends to not punch you in the balls. I originally picked it up trying to solve a simple web hook integration problem. I had a Python Flask app running which received a webhook, did some data transformation and did a POST to an API. After spending a whole morning pissing around trying to get uWSGI, systemd via ansible etc working I went for lunch. Came back, learned en…

> I had a Python ....

IMHO, the biggest win of Go over anything Python is the single distributable.

You write once. Compile (or cross-compile) once. Distribute the binary. Job done.

Python you've got the hell of dependencies. Write your script once, but then users have to endure pip hell for the hundreds of libraries you've depended on. And then the potential different dependencies between different Python stuff.

Go is awesome for that and the Go stdlib has 80+% of what most people need.

Re: Thirteen Years of Go

#139

Post by throwaway894345 »

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…

Not only that, but all of the features Go doesn't have means that you don't have to navigate the "which subset of the language does this project use?" problem. Every project uses pretty much the same language features. Similarly, the code formatter is universal and minimally configurable, so the code formatting looks the same across the ecosystem. Virtually everyone uses the same test runner too. Also, you get documentation (including links to third party and standard library packages!) for free--no need to set up a CI pipeline for publishing documentation packages. Same with package hosting--no need to set up a CI pipeline to publish packages.

There's a ton of this kind of stuff that amounts to a whole lot of productivity that gets overlooked in all of the pennywise-pound-foolish type-system navel-gazing that programmers fixate on.

Re: Thirteen Years of Go

#140

Post by throwaway894345 »

traceroute66 wrote: post #138
gw98 wrote: post #63

Earlier quoted context omitted.

Agree on all points. I'd like to add that it just tends to not punch you in the balls. I originally picked it up trying to solve a simple web hook integration problem. I had a Python Flask app running which received a webhook, did some data transformation and did a POST to an API. After spending a whole morning pissing around trying to get uWSGI, systemd via ansible etc working I went for lunch. Came back, learned en…

> I had a Python .... IMHO, the biggest win of Go over anything Python is the single distributable. You write once. Compile (or cross-compile) once. Distribute the binary. Job done. Python you've got the hell of dependencies. Write your script once, but then users have to endure pip hell for the hundreds of libraries you've depended on. And then the potential different dependencies between different Python stuff. Go…

Also, you can run that Go binary on any Linux system whereas with Python you'll be lucky if you can run on any non-Ubuntu/RHEL Linux system. Moreover, that Go binary will be like 10% of the size of a Python artifact (which amounts to significantly faster deployments and cold start times for things like Lambdas) and it will perform about 2-3 orders of magnitude faster than Python and there will be headroom to optimize (whereas with Python you're usually not going to eek much performance out beyond the naive implementation without substantially overhauling the architecture).
Post reply on HN