Comment by Xeoncross

1 day ago

Yes, for me I've always pushed the limits of what kinds of memory and cpu usage I can get out of languages. NLP, text conversion, video encoding, image rendering, etc...

Rust beats Go in performance.. but nothing like how far behind Java, C#, or scripting languages (python, ruby, typescript, etc..) are from all the work I've done with them. I get most of the performance of Rust with very little effort a fully contained stdlib/test suite/package manger/formatter/etc.. with Go.

Go is in the same performance profile as Java and C#. There are tons of benchmarks that support this.

  • 1) for one-off scripts and 2) If you ignore memory.

    You can make about anything faster if you provide more memory to store data in more optimized formats. That doesn't make them faster.

    Part of the problem is that Java in the real world requires an unreasonable number of classes and 3rd party libraries. Even for basic stuff like JSON marshaling. The Java stdlib is just not very useful.

    Between these two points, all my production Java systems easily use 8x more memory and still barely match the performance of my Go systems.

    • I genuinely can’t think of anything the Java standard library is missing, apart from a json parser which is being added.

      It’s your preference to prefer one over the other, I prefer Java’s standard library because atleast it has a generic Set data structure in it and C#’s standard library does have a JSON parser.

      I don’t think discussions about what is in the standard library really refutes anything about Go being within the same performance profile though.

    • Memory is the most common tradeoff engineers make for better performance. You can trivially do so yourself with java, feel free to cut down the heap size and Java's GC will happily chug along 10-100 times as often without a second thought, they are beasts. The important metric is that Java's GC will be able to keep up with most workloads, and it won't needlessly block user threads from doing their work. Also, not running the GC as often makes Java use surprisingly small amounts of energy.

      As for the stdlib, Go's is certainly impressive but come on, I wouldn't even say that in general case Java's standard library is smaller. It just so happens that Go was developed with the web in mind almost exclusively, while Java has a wider scope. Nonetheless, the Java standard library is certainly among the bests in richness.

Rust is the most defect free language I have ever had the pleasure of working with. It's a language where you can almost be certain that if it compiles and if you wrote tests, you'll have no runtime bugs.

I can only think of two production bugs I've written in Rust this year. Minor bugs. And I write a lot of Rust.

The language has very intentional design around error handling: Result<T,E>, Option<T>, match, if let, functional predicates, mapping, `?`, etc.

Go, on the other hand, has nil and extremely exhausting boilerplate error checking.

Honestly, Go has been one of my worst languages outside of Python, Ruby, and JavaScript for error introduction. It's a total pain in the ass to handle errors and exceptional behavior. And this leads to making mistakes and stupid gotchas.

I'm so glad newer languages are picking up on and copying Rust's design choices from day one. It's a godsend to be done with null and exceptions.

I really want a fast, memory managed, statically typed scripting language somewhere between Rust and Go that's fast to compile like Go, but designed in a safe way like Rust. I need it for my smaller tasks and scripting. Swift is kind of nice, but it's too Apple centric and hard to use outside of Apple platforms.

I'm honestly totally content to keep using Rust in a wife variety of problem domains. It's an S-tier language.

  • > I really want a fast, memory managed, statically typed scripting language somewhere between Rust and Go that's fast to compile like Go, but designed in a safe way like Rust

    OCaml is pretty much that, with a very direct relationship with Rust, so it will even feel familiar.

  • I agree with a lot of what you said. I'm hoping Rust will warm on me as I improve in it. I hate nil/null.

    > Go... extremely exhausting boilerplate error checking

    This actually isn't correct. That's because Go is the only language that makes you think about errors at every step. If you just ignored them and passed them up like exceptions or maybe you're basically just exchanging handling errors for assuming the whole thing pass/fail.

    If you you write actual error checking like Go in Rust (or Java, or any other language) then Go is often less noisy.

    It's just two very different approaches to error handling that the dev community is split on. Here's a pretty good explanation from a rust dev: https://www.youtube.com/watch?v=YZhwOWvoR3I

    • It’s very common in Go to just pass the error on since there’s no way to handle it in that layer.

      Rust forces you to think about errors exactly as much, but in the common case of passing it on it’s more ergonomic.