Comment by klodolph

1 day ago

> I don't see it. Can you say what 80% you feel like you're getting?

I read it as “80% of the way to Rust levels of reliability and performance.” That doesn’t mean that the type system or syntax is at all similar, but that you get some of the same benefits.

I might say that, “C gets you 80% of the way to assembly with 20% of the effort.” From context, you could make a reasonable guess that I’m talking about performance.

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.

      2 replies →

  • 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

      1 reply →