Hacker News Reader

Comment by bigfishrunning | Hacker News Reader

> Surely that gap has been filled for at least a decade, even if only by Rust itself?

I think this is the argument made by the "Rust Evangelism Task Force" -- that Rust provides the features that C and C++ are missing. What i meant by "gap" is "the distance between C or C++ and Rust is greater then the distance between C++ and Go (in Go's target use case) or between Java and Kotlin". For the record, I do think all of these languages are great; I'm just trying to reason out the "rewrite it in Rust" mantra that has taken hold in many online communities, including this one.

> You don't? https://tinygo.org

I wasn't aware of this, thank you.

View on HN

> the distance between C or C++ and Rust is greater then the distance between C++ and Go (in Go's target use case) or between Java and Kotlin

What, exactly, does distance mean here?

The other explicitly told design consideration for Go was for it to "feel like a dynamically-typed language with statically-typed performance". In other words, the assumption was that Googlers were using C++ for network servers not because of C++, but because something like Python (of which Google was the employer of van Rossum at the time!) was too slow. Go was created to offer something more like Python but with performance more like C++. It was a "C++ replacement" only in the sense that C++ is what Google was using where it was considered the "wrong tool for the job". Keep in mind that Go was created before we knew how to make actually dynamically-typed languages fast.

Putting things into perspective, the distance between C++ and Go is approximately the same as the distance between C++ and Python. Which is a pretty big distance, I'd say. C, C++, and Rust are much closer. They are all trying to do essentially the same thing, with Rust only standing out from the other two thanks to its at-the-time unique memory model. So it is apparent that we still don't understand "gap" to mean the same thing.

How I interpret his comment about the distance: The benefit of switching from C/C++ to Rust is higher than switching from C++ to Go (in the similar use-cases) or from Java to Kotlin.

Another argument offered for Rust is that it's high-level enough that you can also use it for the web (see how many web frameworks it has). So I think that Rust's proponents see it as this universal language that could be good for everything.

> The benefit of switching from C/C++ to Rust is higher than switching from C++ to Go

Ten years ago the memory model was a compelling benefit, sure, but nowadays we have Fil-C, that C++ static analyzer posted here yesterday, etc. There is some remaining marginal benefit that C and C++ still haven't quite caught up with yet, but is that significantly smaller and continually shrinking gap sufficient to explain things as they stand today?

You are right that the aforementioned assumption did not play out in the end. It turns out that C++ developers did, in fact, choose C++ because of C++ and would have never selected Python even if Python was the fastest language out there. Although, funnily enough, a "faster Python" ended up being appealing to Python developers so Go does ultimately have the same story, except around Python (and Ruby) instead of C++.

> Another argument offered for Rust is that it's high-level enough that you can also use it for the web

It was able to do that ten years ago just as well. That doesn't really explain things either.

> Keep in mind that Go was created before we knew how to make actually dynamically-typed languages fast.

Would you mind elaborating on this? The strongtalk heritage of VMs has been around for a while now, and certainly before go was started.

Reply on news.ycombinator.com