Hacker News Reader

Comment by tialaramex | Hacker News Reader

> I'm sure there are plenty of reasons this is wrong, but it feels like Go gets me 80% of the way to Rust with 20% of the effort.

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

The type system doesn't feel anything alike, I guess the syntax is alike in the sense that Go is a semi-colon language and Rust though actually basically an ML deliberately dresses as a semi-colon language but otherwise not really. They're both relatively modern, so you get decent tooling out of the box.

But this feels a bit like if somebody told me that this new pizza restaurant does a cheese pizza that's 80% similar to the Duck Ho Fun from that little place near the extremely tacky student bar. Duck Ho Fun doesn't have nothing in common with cheese pizza, they're both best (in my opinion) if cooked very quickly with high heat - but there's not a lot of commonality.

View on HN

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

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

It could as well be Haskell :) Only partly a joke: https://zignar.net/2021/07/09/why-haskell-became-my-favorite...

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.

Borgo could be that language for you. It compiles down to Go, and uses constructs like Option<T> instead of nil, Result<T,E> instead of multiple return values, etc. https://github.com/borgo-lang/borgo

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

just be careful with unwrap :)

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.

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.

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.

ZGC? It should be on par or better than Go.

Java’s collectors vastly outperform Go’s. Look at the Debian binary tree benchmarks [0]. Go just uses less memory because it’s AOT compiled from the start and Java’s strategy up until recently is to never return memory to the OS. Java programs are typically on servers where it’s the only application running.

[0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Also -- Java versus Java native-image

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

IIRC the native image GC is still the serial GC by default. Which would probably perform the worst out of all the available GCs.

I know on HotSpot they’re planning to make G1 the default for every situation. Even where it would previously choose the serial GC.

I guess the 80% would be a reasonably performant compiled binary with easily managed dependencies? And the extra 20% would be the additional performance and peace of mind provided by the strictness of the Rust compiler.

Single binary deployment was a big deal when Go was young; that might be worth a few percent. Also: automatically avoiding entire categories of potential vulnerabilities due to language-level design choices and features. Not compile times though ;)

Wild guess but, with the current JS/python dominance, maybe it’s just the benefits of a (modern) compiled language.

Reply on news.ycombinator.com