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

121–130 of 217 posts

Re: Thirteen Years of Go

#121

Post by 0x445442 »

doorman2 wrote: post #44
0x445442 wrote: post #35

Earlier quoted context omitted.

By amazing do you mean specifically for Go? Because I don’t see how it differs from working on two Maven projects simultaneously in Java where one depends on the other.

In maven, don't you need to update the pom file of the projects to point to the local copy? What's nice about the Go workspace system is that the workspace lives above the individual modules, meaning that the individual modules don't need any modification to pull in local dependencies. E.g. if your workspace looks like this: workspace/ mod1/ mod2/ Then both mod1 and mod2 will pull their dependencies remotely. But if…

See https://news.ycombinator.com/user?id=rad_gruchalski response

Re: Thirteen Years of Go

#122

Post by origin_path »

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…

"Errors always get handled because the linter points them out and the devs don't cheat by setting up multi-function try/catch blocks"

My experience with Go has been that errors get "handled" by propagating them up the stack manually and then logging them, without keeping proper track of how the error got there. So there is error handling but only in theory, in practice what you get is a sort of hand-written stack unwinding logic with far worse functionality and consistency than exceptions, at 100x the verbosity.

Re: Thirteen Years of Go

#123

Post by origin_path »

tgv wrote: post #100
dangoor wrote: post #83

Earlier quoted context omitted.

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…

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 is, that wasn't really well advertised or understood, so people would see a Java program using lots of memory and assume that this is how much it really required. The elasticity wasn't apparent. These days the JVM can kick off background collections from time to time to reduce memory usage if the app is idle. However it still won't aggressively collect if the app is running because, again, if you haven't capped it then it figures that it's better to serve requests than do lots of "pointless" GC work.

Re: Thirteen Years of Go

#124

Post by alyandon »

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…

Similar experiences with Go vs Java and Python. One thing that has stuck with me to this day was how quickly I was able to write a proxy to distribute keys consistently across a set of Redis servers to break out of a bottleneck in an internal processing pipeline.

Re: Thirteen Years of Go

#125

Post by slekker »

sdevonoes wrote: post #120

Interesting to see many comments regarding "Go is my favourite programming tool, but not my favourite programming language". I totally agree. I love the tooling (go build, go fmt, etc.), the performance, the ecosystem... but the language itself is not the best out there. I would love a mix between Python and Go: Python as the language with Go's tooling. That would be amazing!

Maybe that's Nim (or Nim2)?

Re: Thirteen Years of Go

#126

Post by 5e92cb50239222b »

TrustPatches wrote: post #113
KingOfCoders wrote: post #88

Earlier quoted context omitted.

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 i…

Not sure if it’s an exact parallel, but you can also embed files into rust binaries with “include_bytes!” and “include_str!”.

It's a bit more advanced than what Rust macros provided last time I checked. You can shove whole directories in there and then traverse them or serve as static resources with pretty much one line of code.

Random blog post with a few examples:

https://blog.carlmjohnson.net/post/2021/how-to-use-go-embed/

Re: Thirteen Years of Go

#127

Post by [deleted] »

Beltalowda wrote: post #92
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…

> 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. I've never been "stuck" with Go in the sense that I wasn't able to do something I wanted. I've programmed in plenty of more expressive languages over the years, and I don't think there's much difference in terms of produ…

[deleted]

Re: Thirteen Years of Go

#128

Post by kaba0 »

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.

Re: Thirteen Years of Go

#129

Post by rob-olmos »

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…

What sticks out most for the Java code being pretty awful? Was the PHP code just as awful too in similar aspects?

Re: Thirteen Years of Go

#130

Post by divan »

Laiho wrote: post #37

I really want to love this language, a fast and simple garbage collected lang, but feel like they missed the spot a little. I just wish they did something different with error handling / nil, doesn't feel right for the language. Also whats up with stuff like unused imports being such a big deal?

> Also whats up with stuff like unused imports being such a big deal?

https://go.dev/doc/faq#unused_variables_and_imports

Post reply on HN