Hacker News Reader

Hacker News

Comment by ayewo | Hacker News Reader

Full thread

ayewo

Rewriting in Rust is not a meme, it's a cycle.

Before Rust became viable, rewrites were done in Go.

From the archives:

- Rewriting a large production system in Go https://news.ycombinator.com/item?id=6234736 (2013)

- How We Moved Our API From Ruby to Go https://news.ycombinator.com/item?id=9693743 (2015)

- Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App https://news.ycombinator.com/item?id=16938545 (2018)

- Toward Vagrant 3.0 https://news.ycombinator.com/item?id=27476676 (2021)

- I’m porting the TypeScript type checker tsc to Go https://news.ycombinator.com/item?id=30074414 (2022)

View on HN

Which is why old timers eventually learn to just deliver with boring technology.

> Which is why old timers eventually learn to just deliver with ~~boring~~ buggy technology.

There's a reason why folks take the time to rewrite things in Rust. No matter how good you are at C/C++ you will encounter bugs that you would not have if you had written it in Rust.

Assuming there is even a Rust library replacement to start with.

People keep forgetting C++ has 30 years of being deployed in production.

Rust is 2022 is like using C++ in 1990's in terms of ecosystem.

This is just plain false. C++ in the 1990s had nothing like serde for example.

The minimum bar for a language has moved up significantly since the 1990s. It isn't enough to just have a neat new idea, you need to ship with nearly-best-of-breed JSON serialization, a web server, a huge standard library with not just strings but things like compression and a lot of networking, and a laundry list of other things (give or take a few things) just to make it to the "barely viable alternate choice" point.

Nice as a language consumer, but a bummer that building new languages and getting some attention is so much harder than it used to be.

Well, Rust checks all of those boxes.

Yes, it's a problem for that language you plan on creating (try specializing into a niche). But it's not something that should impact Rust's adoption.

With various levels of completeness.

Where are the production grade and pure rust tls library ? Key-value store ? Ldap client ? SSH client ?

> production grade and pure rust tls library

You mean rustls? https://github.com/rustls/rustls

Pure rust ? No.

You’re right, I see some *.md-files in the GitHub repo

“ ring exposes a Rust API and is written in a hybrid of Rust, C, and assembly language.”

Aren't the most commonly used libraries for all of those written in C, not C++?

Regardless, I'm surprised you haven't heard of rustls - https://github.com/rustls/rustls

You have great c++ libraries for those. Not in pure rust though.

I haven't used them much, but sled, ldap3 and thrussh do exist. As Rust gains further in popularity I'd expect more of these to become production ready. Meanwhile there's always C and C++ interop.

Sled and thrussh are not production grade. I don’t particularly want to delve into details as I think the effort is laudable. I can explain my position in private if need be.

OK. I mean they're probably less mature, yeah. But high-quality Rust bindings to libssh2 and RocksDB do exist so shrug

And? A drop in the ocean of libraries.

And virtually no one should be starting new projects in C++ and everyone should switch to Rust.

Start by removing C++ from Rust compiler.

Then go around for Khronos, NVidia, Microsoft, Sony, Nintendo, Unreal, Godot,.... to support Rust on their SDKs.

The C++ IDEs available up until about 10 years ago were complete garbage. C++ still doesn't even have a good package manager. All the build systems are pure chaos. The largest C++ package manager has 1500 packages. In comparison, rust's package manager and build system are way easier to use and already have 94,000 packages available to users.

That's not exactly fair to C++ because entire categories of dev tools (like build systems, package managers, IDEs, debuggers, version control, static analyzers, etc.) have matured after C++ did. And let's not forget that when C++ was new, most libraries were proprietary licensed and paid for, whereas today almost all libs are open source. And those improvements (along with general size of the programming community) mean that a trendy language today is going to develop and mature a lot faster than a formerly trendy language did 30 years ago.

IMO Rust in 2022 is a lot closer to java in 2005 than C++ in the 1990s.

Another one that never used Borland, Apple, IBM IDEs.

Where is the Rust IDE that is half as capable as C++ Builder, MPW/Metrowerks, Visual Age, Zortech?

Considering all features they offered across the board in the box, not only code completion.

I've used Borland. I'm sure it was marvelous at the time, but it doesn't hold a candle to CLion or Visual Studio in the 2010s or later.

CLion now ships a cross platform C++ framework with it?

As for Visual Studio, yeah it is great in all aspects, except having nothing else beyond MFC to offer on the GUI department, WinUI is still a mess after UWP.

In any case your examples are for C++ IDEs, reinforcing my case of C++ tooling versus Rust.

I honestly feel like rust is boring technology in most senses of the word. It “just works” more than almost any other technology that I’ve used. The ownership system is new and different, but that’s really the only thing.

Rust is not boring technology. There's too much ecosystem churn, and new language features are deployed too often.

C++ isn't boring technology, either. If you just want to deliver value, I'd recommend Java.

> There's too much ecosystem churn, and new language features are deployed too often.

Not much of an issue if you stick to the stable subset of the language, and libraries that work within that subset.

> There's too much ecosystem churn, and new language features are deployed too often.

That kinda feels like saying Linux is too crazy because new apps get made for Linux frequently.

You can use the same part of the language tomorrow that you used today. Nothing is changing out from under you. If you're afraid of libraries, don't use them. You'd have the same problem in any ecosystem that is new, no?

> That kinda feels like saying Linux is too crazy because new apps get made for Linux frequently.

Apps are okay, but other parts of userland that roll out breaking changes on a regular basis are definitely a problem [1] [2] [3]. Even if they aren't technically part of the kernel, they are usually used with it to provide a complete working system, and they break stuff all the time.

[1]: https://lwn.net/Articles/904892/

[2]: https://lwn.net/Articles/840430/

[3]: https://lwn.net/Articles/777595/

With my (admittedly limited) experience with the Hadoop ecosystem, I'd sincerely beg for people to stop writing databases in Java... Apart from the way bigger system requirements, dependency version hell, having to monitor GC pauses is just so, so annoying

I've led and been on teams that have written multiple production-grade Rust services that have together delivered 100MM+ USD of value. The number of production bugs has been in the single digits, with exactly one outage that lasted more than a few minutes in the last 3 years. How about yourself?

In my experience, Rust delivers by far the fewest number of bugs in production out of any mainstream language. It gets the fundamentals right like nothing before it. &, &mut, Send and Sync take care of many classes of bugs in the inner loop of productivity.

Honestly, so is Go. I used to use Go, and it's boring as hell. I hate it for a few choices they made, but they definitely achieved their goal. It is quite boring.

I agree with you though, so is Rust. The less boring areas imo these days aren't languages (at least none i see), as all the good languages are boring. Zig for example, is pretty mundane too.

The older i get the more i value confidence in a product. Confidence that it won't crash at runtime. Confidence that i won't be bugged over the weekend. etc

The stable release of Go was maybe four years or so before Rust. So what you’re saying seems to be that people like to rewrite their tech in young and hyped (for good or bad or neutral) languages. Because there is little connection between Rust and Go (other than chronology).

Reply on news.ycombinator.com