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

141–150 of 217 posts

Re: Thirteen Years of Go

#141

Post by doorman2 »

kaba0 wrote: post #137
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)

Personally, I hate writing Go. It's a very dull and boring language, but it's an amazing language (objectively speaking) for software development.

1) It's performant. The language itself is very fast, the GC is very fast and go routines make concurrency fast.

2) The tooling is great. Once you have the Go CLI installed, everything else "just works." Cross-compilation is super easy. Install dependencies is easy. Generating code is easy. Embedding files is easy. The ecosystem is really mature. Modules are easy to create, export, and import. Compilation time is fast. The list goes on...

3) The generics system is amazing. It beats any system that implements generics with type erasure.

4) The language itself is very easy to read and write.

5) The language is relatively new, which means less outdated cruft. The language also puts an emphasis on having only one way to do things.

So comparing it to other languages:

- Python: Terrible tooling. Not performant

- C# Bad tooling (do I need .NET, .NET Core, Mono? How do I create a project? What is this crazy project xml file? How do I export my project to be consumed by others? How do I import a dependency?). Also, as an older language, it has a bit of cruft, e.g. it has optional types, but they also aren't required? Maybe if I knew more about C#, I would find it better. But using it with Unity didn't leave a great taste in my mouth.

- JavaScript: not performant, especially in multi-core environments.

- Rust: Rust is too hard to write. It's not worth the overhead if you can afford a GC.

- C++: Same as rust, + more foot guns and unsafe memory management.

- Zig: Don't have much experience with Zig, but I'd like to.

- Ruby: Not performant, not typed.

- Swift: Tooling is bad. Compilation is slow. Cross-platform is not a priority. Swift Package Manager is buggy. Using Xcode sucks.

- JVM languages: bad tooling (maven, sbt, gradle are all a pain), generics have type erasure.

Of course, there are reasons to use other languages. If you’re writing an iOS app, the tooling for Swift is best-in-class. Or if you’re doing ML, the ML-specific ecosystem in Python outweighs all other considerations.

Re: Thirteen Years of Go

#142

Post by throwaway894345 »

kaba0 wrote: post #131
makestuff wrote: post #57

Earlier quoted context omitted.

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.

Back in 2012 I was considerably better-versed in Java (it was the main language for my CS education and a bunch of my hobby stuff). Still, I ended up picking Go because it was so much easier--no need to deal with Maven or Gradle or the alternatives, no need to pick a testing framework or a test runner, no need to configure CI jobs to publish documentation or source code packages, no need to run some external web server process, no need to worry about runtime dependencies (including the JVM itself), etc. No need to navigate an ecosystem (including stdlib) riddled with inheritance and other antipatterns, etc. No need to get a master's degree in tuning the JVM. Text editor plugins just worked. `gofmt` existed and was ubiquitous. The language itself was far smaller and it had native, idiomatic value types from inception!. Everything about Go was just so much easier than Java.

Re: Thirteen Years of Go

#143

Post by throwaway894345 »

rahen wrote: post #82
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-...

You don't even need CGo or unsafe to deal without a GC. Go's GC is written in Go and it obviously doesn't depend on a GC! You just need to know which features imply a GC/allocation and you need to take care to avoid those features. Conceivably, you could devise a linter that statically verifies your no-GC requirement.

Re: Thirteen Years of Go

#144

Post by throwaway894345 »

galangalalgol wrote: post #81
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 quart…

TinyGo still has a GC, right?

Re: Thirteen Years of Go

#145

Post by Xeoncross »

throwaway894345 wrote: post #139
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 docume…

"Gofmt’s style is no one’s favorite, yet gofmt is everyone’s favorite" - https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s

Re: Thirteen Years of Go

#146

Post by ilyt »

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.

>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.

It could've definitely be better (just Rust-like Result type would make it so much clearer to handle) but Go's insistence of dealing with it here and now means you have to think about what is exactly happening when it errors out, and are encouraged to add context to the error message instead of "here is stack trace, fuck you user, you're not worth knowing what is wrong".

But it's verboseness in common cases is inexcusable, if I have 3 steps to establish a connection, having 3 lines per error to handle is inexcusably bad. And it will be fucking 3 lines even if you write it in one line, because go fmt will expand it back to 3 lines

> Goroutines in themselves won’t give you actually correct concurrency.

Main advantage is they are cheap enough that doing goroutine per request won't bite you in most cases so you can have near-perfect parallelization of common apps by just writing essentially serial code.

The concurrency primitives are built into language and stdlibs which means when you do need synchronization, everyone does it same way.

Re: Thirteen Years of Go

#147

Post by [deleted] »

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!

[deleted]

Re: Thirteen Years of Go

#148

Post by ilyt »

halfmatthalfcat wrote: post #114
tptacek wrote: post #17

Earlier quoted context omitted.

This is an article about Go, not an article comparing Go to Rust. I'd say the same thing if the roles were reversed: don't start language debates. They spread like kudzu and choke everything else out of the threads.

If HN adhered to this policy, it would be the most boring site on the web. Tangential, complementary and/or controversial conversation in posts is where some of the best content is. Comment police/gatekeeping discussion (outside of dang actually enforcing the rules) is probably the most annoying behavior on this site.

Comment "Rust is better because I use it" does not make great discussion tho. It's just useless noise

Re: Thirteen Years of Go

#149

Post by greymalik »

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…

Are there reasonable Go alternatives to pandas, numpy, and sklearn?

Re: Thirteen Years of Go

#150

Post by erik_seaberg »

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.

I want the compiler doing as much work as it possibly can. If they can somehow make the compiler faster, I guess that’s nice, but I don’t want to be saddled with a language that’s been compromised to move work from the computer back into 0.0001 MHz human brains.
Post reply on HN