Hacker News Reader

Comment by lumost | Hacker News Reader

I sometimes wonder if the problem with rust is that we have not yet had a major set of projects which drive solutions to common dev problems.

Go had google driving adoption, which in turn drove open source efforts. The language had to remain grounded to not interfere with the doing of building back-end services.

Rust had mozilla/servo which was ultimately unsuccessful. While there are more than a few companies uinf rust for small projects with tough performance guarantees - I haven't seen the “we manage 1-10 MM sloc of complex code using rust” type projects.

View on HN

Microsoft is rewriting quite a bit of their C# to Rust for performance reasons. Especially within their business line products. Rust have also become rather massive in the underlying tech in the telecommunications infra structure in several countries.

So I’m not sure that your take is really so on point. Especially as far as comparing it with Go goes (heehee), at least not in terms of 3rd party libraries where most of the Go ecosystems seems to be either maintained by one or two people or abandoned as those two people got new jobs. I think Go is cool by the way, but there is a massive difference in the maturity of the sort of libraries we looked into using during our PoCs.

Anyway. A lot of Rust adoption is a little quiet, and well, rather boring. So maybe that’s why you don’t hear too much about it.

Quiet adoption often means that a couple people in a company chose to invest in at least a small effort. It's unknown if those people would do it again, and they are unlikely to invest 2-3 devs to improve the rust library and language ecosystem.

Major adoption gets you tools like guice, 50+ person tools teams, and more.

Microsoft rewrote one, maybe two microservices as it was driven by a lead interested in using Rust and is rewriting parts of NT kernel (way more important).

It’s much more than that, even now they are continuously opening job postings with a focus on re-writing the 365 platform from C# to Rust.

It’s a bad habit to read too much into a single job posting.

(oh, I remember now, it’s the account traumatized by odata)

I’m not sure why you’re trying to make it seem like Microsoft isn’t rewriting the core of their 365 business products from C# to Rust, but you do you I guess.

As far as I’m aware I was never traumatised by OData. It’s true that I may have ranted about the sorry state of the public packages available outside of C# or Java. Not unwarranted criticism I think, but I wrote our own internal adaptation which now powers basically all our API clients for Typescript as a single shared no-dependency library.

But you seem to think you know me? Have we met?

Alright, if not for that one job posting, I’m curious where you are getting this information from?

I really think the problem of Rust is the borrow checker. Seriously. It is good but it is overkill. You have to do and plan all things around it and discourages a lot of patterns or makes them really difficult to refactor.

I would encourage people to understand Hylo's object model and mutable value semantics. I thinks something like that is far better, more ergonomic and very well-performing (in theory at least).

You can use unsafe code and pointers if you really want, but code will be unsafe, like C or C++.

Look at Hylo. Tell me what you think. You do not need all that juggling. Just use value semantics with lazy copying. The rest is handled for you. Without GC. Without dangling pointers.

TBF, unsafe Rust still enforces much more correctness than C or C++ (Rust's "unsafety" is more similar to Zig than C or C++).

TBF this is not really true. Unsafe Rust is a lot harder than comparable C/C++, because it must manually uphold all safety invariants of Safe Rust whenever it interacts with idiomatic Rust code. (These safety invariants are also why Safe Rust can often be compiled into better-optimized code than the idiomatic C/C++ equivalent.)

With more enforced correctness of Rust (also unsafe Rust) I mean small details like Rust not allowing implicit conversion between integer types. That alone eliminates a pretty big source of hidden bugs both in C and C++ (especially when assigning a wider to a narrower type, or mixing signed and unsigned integers).

All in all I'm not a big fan of Rust, but details like this make a lot of sense (even if they may appear a bit draconic at first) - although IMHO Zig has a slightly better solution by allowing implicit conversions that do not lose information. E.g. assigning a narrower to a wider unsigned integer type works, but not the other way around.

I wonder if Rust is killing flies with canons (as we say in spanish). There are perfectly safe alternatives or very safe ones.

Even in a project coded in Modern C++ with async code included, activating all warnings (it is a cards game) I found two segfaults in like almost 5 years... It can happen, but it is very rare at least with my coding patterns.

The code is in the tens of thousands of lines of code I would say, not sure 100%, will measure it.

Is it that bad to put one share pointer here and there and stick to unique pointers and try to not escape references? This is ehat I do and I use spans and string views carefully (you must with those!). I stick to the rule of zero. With all that it is not that difficult to have mostly safe code in my experience. I just use safe subsets except in a handful of places.

I am not saying C++ is better than Rust. Rust is still safer. What I am saying is that an evolution of the C++ model is much more ergonomic and less viral than this ton of annotations with a steep learning curve where you spend a good deal of your time fighting the borrow checker. So my question is:

- when it stops being worth to fight the borrow checker and just replace it with some alternative, even smart pointers here and there? Bc it seems to have a big viral cost and refactoring cost besides preventing valid patterns.

> What I am saying is that an evolution of the C++ model is much more ergonomic and less viral than this ton of annotations with a steep learning curve where you spend a good deal of your time fighting the borrow checker. So my question is:

That "evolution of the C++ model" (the C++ Core Guidelines) has an even steeper learning curve than Rust itself, and even more invasive annotations if you want to apply it across the board. There is no silver bullet, and Rust definitely has the more principled approach to these issues.

I'm not answering your question here, just saying my opinion on C++ vs Rust. I think that the big high-level difference (before diving into details like ownership and the borrow checker) is that C++'s safety is opt-in, while Rust's safety is opt-out. So in C++ you have to be careful each time you allocate or access memory to do it in a safe way. If you're working in a team, you all have to agree on the safe patterns to use and check that your team members are sticking with it during code rewiews. Rust takes this burden from you, at the expense of having to learn how to cooperate with the borrow checker.

So, going back to your question, I think that the answer is that it depends on many factors, including also some non-strictly-technical ones like the team's size.

An evolution of the C++ model could be something like Hylo. Hylo is safe. Hylo does not need a borrow checker. Hylo does not need a garbage collector.

That is what I mean by evolution. I do not mean necessarily C++ with Core Guidelines.

I think you replied to the wrong reply.

Unsafe Rust is not harder or safer than C/C++. If you can uphold all safety invariants for C/C++ code (OMG!), then it will be easier to do same thing for unsafe Rust, because Rust has better ergonomic.

Better ergonomics for what? For refactoring with a zillion lifetime annotations? Annotations go viral down the stack call. That is a headache. Not useless. I know it is useful. Just a headache, a price to pay. For linked structures? For capturing an exception.

No, it is not more ergonomic. It is safer. That's it.

And some parts of that enforcement via this model is terribly unergonomic.

? I believe the Rust efforts in Firefox were largely successful. I think Servo was for experimental purposes and large parts were then added to Firefox with Quantum: https://en.wikipedia.org/wiki/Gecko_(software)#Quantum

My recollection was that those were separate changes - servo didn’t get to the stage where it could be merged, but it was absolutely the plan to build a rendering engine that outperformed every other browser before budget cuts hit.

We did port Servo’s WebRender to Firefox and shipped it everywhere. The only caveat is that it took multiple years of upgrades, fixes, and rewriting it.

It would be interesting to hace a postmortem of what went well, wrong, etc. for this initial effort.

I believe work continues now somewhere else but it would be absolutely nice to know more from the experience from others.

> Go had google driving adoption

This is commonly said but I think it's only correct in the sense that Google is famous and Google engineers started it.

Google never drove adoption; it happened organically.

> Rust had mozilla/servo which was ultimately unsuccessful.

There's lots of Rust code in Firefox!

> I haven't seen the “we manage 1-10 MM sloc of complex code using rust” type projects.

Meta has a lot of Rust internally.

The problems with Rust for high-level indie game dev logic, where you're doing fast prototyping, are very specific to that domain, and say very little about its applicability in other areas.

Servo is an ongoing project, it has not "failed" or been unsuccessful in any sense.

I think the original poster is perhaps speaking to previous articles (ie https://news.ycombinator.com/item?id=39269949) which from the outside looking in made me feel that perhaps this infact was the case (at least for a period).

Reply on news.ycombinator.com