Hacker News Reader

Comment by bla2 | Hacker News Reader

> The nice things we want to do in native code are complicated to implement in C because cross-platform C is hard. The standard library is inadequate compared to modern languages. While modern versions of C++ are nice, we still support Python 2.7 and thus need to build with MSVC 2008 on Windows. It doesn't have any of the nice features that modern versions of C++ have. Things like introducing a thread pool in our current C code would be hard. But with Rust, that support is in the standard library and "just works." Having Rust's standard library is a pretty compelling advantage over C/C++ for any project, not just Mercurial.

Sounds like the main reason for rust is that Python has a weird dep on a fixed MSVC version.

View on HN

There was also this point that was phrased as a comparison to python but I think works equally as well for choosing rust over c:

> In addition to performance concerns, Python is also hindering us because it is a dynamic programming language. Mercurial is a large project by Python standards. Large projects are harder to maintain. Using a statically typed programming language that finds bugs at compile time will enable us to make wide-sweeping changes more fearlessly. This will improve Mercurial's development velocity.

Which they mention they'd still have to implement workarounds for if they adopt Rust, so I'm not sure I understand that selling point.

Switching to Rust removes a lot of papercuts from dealing with MSVC. These things could be solved in many other ways, so it's not exactly the reason, just something you also get from adopting Rust.

For C programs Windows happens to be the odd one out for lots of things. It's annoying with its unloved C compiler, missing unix-ish headers and tools, string encoding pains, very different packaging story, etc.

So I think the motivation here is they'll solve just that one CRT problem now, and will have fewer Windows problems to worry about later.

I've done that for pngquant. I can build things with Cargo rather than explain to users that `make` may be `mingw32_make`. I can parse options with Rust's getopts, rather than getting bugreports that Visual Studio can't find `getopt.h`. These aren't hard problems. I could have solved all of them, but I don't have to!

It sounds more like they don't want to be stuck using an old version of C++ for writing their fast-path, and would prefer to use Rust, because of the nice features it provides.

Reply on news.ycombinator.com