Hacker News new | past | comments | ask | show | jobs | submit login

> https://language-compare.glitch.me/

Putting numbers to things like this is a fuzzy business of course, but I'd be interested in comparing notes on some of them:

- I'm surprised Go gets a 1.0 for thread safety, while Java only gets a 0.5. My understanding is that, at the lowest level, producing e.g. a torn pointer is not possible in the Java memory model, while it is possible in Go.

- I think C++ deserves at least a point or two over C for thread safety, for the same reason it gets a couple points for memory safety. The distinction between raw pointers and smart pointers makes it a lot clearer who is supposed to be owning what, and seeing shared_ptr in the code can be a good reminder that something is likely to race.

- Is Rust really harder to learn than C++? :) I'd normally give C++ a lot of points for familiarity, but that's already split into a separate row.




> - I'm surprised Go gets a 1.0 for thread safety, while Java only gets a 0.5. My understanding is that, at the lowest level, producing e.g. a torn pointer is not possible in the Java memory model, while it is possible in Go.

Some of the original reasoning behind the numbers is swapped out, but much of this scoring was that we were burnt so much by the ease of passing objects between threads and accidentally racing that we dinged Java. Our company's experience with Go has just been better, but Go also has first-class goroutines that mostly enforce doing stuff "right", and had better tooling around multithreaded race detection [1] especially at the time.

> - I think C++ deserves at least a point or two over C for thread safety, for the same reason it gets a couple points for memory safety. The distinction between raw pointers and smart pointers makes it a lot clearer who is supposed to be owning what, and seeing shared_ptr in the code can be a good reminder that something is likely to race.

That's a good point. We might have scored it somewhat differently if we were more familiar with C++ at the time but most of our C++ knowledge on the team was pretty old, and especially sparse around multi-threading.

> - Is Rust really harder to learn than C++? :) I'd normally give C++ a lot of points for familiarity, but that's already split into a separate row.

IIRC, the rationale was that C++ is mostly familiar concepts that senior developers have encountered in some form, while Rust introduces brand new concepts that we just don't have a good reference point for.

This is absolutely fuzzy business, and a different team will have different weights/scores than us!

[1] https://blog.golang.org/race-detector


> Putting numbers to things like this is a fuzzy business of course, but I'd be interested in comparing notes on some of them.

Me too. I'm especially surprised that Rust gets a 1.0 for size ("What’s the size impact of this language on the framework we would deliver for our customers?"). For comparison, C also got a 1.0 and Go got a 0.3. I _far_ prefer working in Rust to working in either Go or C, but my experience hasn't been that Rust binaries are anywhere near as small as equivalent C ones.


Have you tried making them small? Rust doesn't optimize programs for size by default, there's a lot of easy ways to shrink binaries (like stripping symbols).

https://github.com/johnthagen/min-sized-rust


> Have you tried making them small? Rust doesn't optimize programs for size by default, there's a lot of easy ways to shrink binaries (like stripping symbols).

Yeah, I have. I'd come across the guide you linked, any frequently use the subset of those techniques that are available on stable Rust. And I've ended up with simple CLI apps in the 2 to 4 MiB range – which is _fine_ for my use-case, but a bit closer to the size of a Go binary than a C one. (Though, like I said, it's fine for my use case and, if it were important to me, I'm sure I could trim that a bit by picking different dependencies or even dropping to `no_std` in some cases)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: