Hacker News Reader

Comment by TrackerFF | Hacker News Reader

The organization (gov.) I work for recently took over a product where the entire back-end was written in Rust. Basically the product was developed by a bunch of Rust enthusiasts in a R&D group, and the product was wholly financed by gov. grants. When that money dried out, they were faced with either just shutting it down, or trying to sell or give the product away. Some higher-ups decided this could be a great internal tool, and got it for free.

The product works great, but the codebase is around 400k LOC of Rust, and we don't have any budget to hire Rust developers. And when we had a budget in November, it was really hard to find anyone local (work requires a high security clearance, and remote is not possible for this kind of work due to said security issues).

So we're kind of stuck with just keeping it around until better times, or just re-writing the entire back-end in something we know better. Not to sound like a downer, just an example of what Rust adaption could look like from the other side.

View on HN

That sounds like a good opportunity to learn the language. I've had to learn things under duress in my career, often rhat 'low-code' platform whose app is now broken or needs some change, that COBOL system being migrated, whose rules were written before I was born, etc.

Most of what I learn ends up being throw-away, done out of necessity. However, I feel like something written in a popular and growing language like Rust, with an opportunity to learn, maintain, change and improve, would be a net positive.

I'm biased because I learnt Rust in ~2018 and have enjoyed it, however if this were say Scala or Go before I learnt them, I'd feel the same way.

Yesterday I was in a jam session with a colleague, we prototyped something quick and dirty, got it to work, and then refactored it into something neat and clean. This was such a pleasure, because I feel like the language empowers me to make large refactors mostly without introducing breakages (at least when you're shuffling code and types around).

> I've had to learn things under duress in my career

This is how I've learned most things in my career :D

For something like Rust (or other languages like go or objc) though, I could see how it would be hard for someone whose only background is in js or python. There are concepts completely missing or hidden from the programmer that they now have to deal with.

> I could see how it would be hard for someone whose only background is in js or python.

As someone who has trained several Rust programmers, I've seen people hit two major snags:

- Like TypeScript, Rust is a strongly-typed language that gently encourages functional programming.

- Like C/C++, Rust is a language where you need to know about references vs values, and the stack vs the heap.

Someone who's comfortable in TypeScript and C++ will often take to Rust like a duck to water. But someone who's never called "map" or who has never worked with pointers may take longer. A pure C programmer might struggle as much as pure Python programmer, just from the opposite direction.

That said, I love Rust precisely because it allows me to move between a TypeScript mindset and a C mindset as needed. When I want something fast, solid, correct and easy to maintain, it's my favorite tool. But for many team projects, Rust is overkill—garbage collected languages are often perfectly affordable. And there are many excellent choices!

Never heard this before but will now look out for it.

I was always surprised when people said rust had a steep learning curve, yet it seemed relatively easy to pick up to me.

My first language in school was C++ and my first language on the job was Typescript, exactly as you described. I knew both well and then heard about rust and tried it.

> But someone who's never called "map" or who has never worked with pointers may take longer.

When I wrote my comment I was thinking way back to when I was in undergrad and pointers were a huge stumbling block for many. Maybe things have changed, but if someone hasn't had to think about them ever, it could make learning a language with explicit pointers challenging.

That's not say people can't learn, I'm just thinking about how long it takes someone to get up to speed.

> Maybe things have changed, but if someone hasn't had to think about them ever, it could make learning a language with explicit pointers challenging.

To be clear, safe Rust doesn't actually have pointers. (Well, it does, but only unsafe Rust can dereference them.)

But Rust does have pass by value and pass by reference. It has both stack allocation and heap allocation. And it has a notion of who "owns" something. These aren't technically pointers, but taken together, they're basically a safe interface to doing "pointer stuff." Conceptually, all these ideas should make sense to anyone who has worked with pointers and allocation.

Similarly, Rust allows easy mutable state as long as only one piece of code can see the mutation happen. But many programmers are used to being able to share mutable state between widely separated bits of code. And this affects how you design the architecture of your program! Anyone who has done functional programming will see the implications of this early: "Oh, I need build my architecture around immutable state!" So something like an old-school game engine where any entity can update any other entity is a huge headache in Rust. But a game architecture like ECS that carefully restricts mutation (like Bevy) works beautifully with in Rust.

I don't want to trivialize this: Pointer stuff and mostly-functional architectures are both real skills that take time to learn. Rust is amazing for situations where you feel torn between TypeScript and C/C++. But lots of projects just need a nice GCed language and a good standard library, and Rust wouldn't be the right choice for many teams.

I agree with you. I’m learning Rust as a Python-only (bit of Typescript) mostly data-analyst experience and Rust has been challenging, but I’m slowly getting it thanks in part to its new popularity and variety of tutorials.

That said I don’t get what you meant by knowing about the stack vs heap in Rust. I’m not from C++ land so maybe this flew over my head, could you elaborate?

The simpler parts of Rust feel like TypeScript, let's say as long as you're doing simple things as a start and don't worry about threading.

Rust was probably also a lot easier to learn pre-async-await, because one would have to explicitly opt in to multithreading through std::thread.

My first productive language was JavaScript via NodeJS (I learned PHP first, but it was a mess). I did so much with it that by the time I learnt other languages on my own, it was out of necessity.

From a language syntax and concept angle, I'd say Java + Scala were difficult to grok at first. Java for the boilerplate, Scala because I could never understand what the underscore is for.

Kotlin became a breeze and pleasure, then Rust after that. I learnt each language by converting my projects from a previous language to a new one. So that helped me limit the concepts I'd introduce.

Mostly do some calcs, interact with a DB and expose stuff via gRPC. By the time I started with futures, channels and threads, I had gotten far enough programming against a single core.

I often advise people starting out to be gentle with themselves and stick to what they know first. Like other complex languages, one might remain a learner for very long.

> Rust was probably also a lot easier to learn pre-async-await, because one would have to explicitly opt in to multithreading through std::thread.

Worse, you can use both in the same program, which, while safe, is really complicated.

There's a lot to be said for Go's green threads for routine web back end stuff. They avoid the async/thread distinction, because they're both lightweight and can block.

I'm beginning to wonder if it's actually more difficult for C++ developers to learn Rust, at least speaking from personal experience. There are so many things I want to do in Rust when mapping from my C++ knowledge that are genuinely unsafe, e.g. copying around reference objects (including iterators) but convincing myself through rigorous testing that none of them ever dangle despite the somewhat unrelated lifetimes.

Perhaps when one isn't trying to map some similar-ish knowledge onto Rust it becomes easier, as one doesn't have to drop preconceived notions.

This very much feels like the time I tried to snowboard after having skied for a couple of decades; why can't I move my feet like before?!

> I'm beginning to wonder if it's actually more difficult for C++ developers to learn Rust, at least speaking from personal experience.

It seems to go one of two ways with C++ developers:

- Some C++ developers were alsready hyper aware of object lifetimes and were effectively enforcing Rust's constraints on their own code manually anyway. They find Rust the easiest of anyone

- Some C++ developers were blissfully unaware of object lifetimes and played fast and loose with them so long as it worked. Those C++ struggle with Rust more even those with no previous low-level experience.

> There are so many things I want to do in Rust when mapping from my C++ knowledge

As someone who came to Rust from JavaScript, I can attest that with a few exceptions the opposite is true for JS knowledge: basically everything I was used to being to do from JavaScript I can do in Rust.

> copying around reference objects (including iterators) but convincing myself through rigorous testing that none of them ever dangle despite the somewhat unrelated lifetimes

The underlying issue with this kind of informal assurance is that it may become incorrect in a large-scale project as it evolves. This is why "unsafe" in Rust is best used locally, as part of something that provides a safe interface to the rest of the code.

Oh, there are plenty of idioms you can use in C++ that are easy to make safe (as long as you don't make a mistake on some very small amount of code) that Rust will make a nightmare to implement.

Just like there are plenty of idioms you can use in Haskell that are easy to make simple that Rust will make a nightmare to implement.

At the end of the day, Rust is neither of those. It is a safe low level language, and that comes with plenty of restrictions. The language is amazing for how little restrictions it actually has when compared to a naive estimate, but there are still plenty of them.

The problem is that very few idioms are both safe and compositional (which you need if you want your development approach to scale to the largest projects). Rust focuses on these as a sensible default, for everything else there's unsafe.

> Oh, there are plenty of idioms you can use in C++ that are easy to make safe (as long as you don't make a mistake on some very small amount of code) that Rust will make a nightmare to implement

Like? I know double linked lists and graphs are harder to get right, but aren't impossible.

But on the flip side getting Optional and Send/Sync to work in C/C++ and not to rely on people using best practices is downright impossible.

> There are concepts completely missing or hidden from the programmer that they now have to deal with.

Hence the part about learning.

I feel like it took me 2 weekends to "learn Rust" enough to make feature changes, and another 2 weekends to really "get it" enough to build basic abstractions.

I feel like it would take another week or two to learn some of the UnsafeCell/Pin/Generators type stuff, but none of that is needed for 95%+ of Rust code.

I think if you and your team just started learning Rust week by week, you'd find in 3 weeks that you're equally productive in Rust than your current languages. Especially given the code base already exists. Even just starting to learn Rust by writing tests (if there aren't) would be sufficient to improve that system rather than wait to hire or re-write it.

As a counterpoint, I’m a senior engineer at FAANG with 15 professional YOE. I’ve mostly used scripting languages in my career though.

It took me probably more like 1-2 months to really understand how to code in Rust. I do not think a typical team of JS/Python devs would be productive in 3 weeks. I think it would be more like 3 months. Developers with C++ experience seem to pick it up much quicker.

Also, at this point I’m pretty proficient in rust but I’m still far slower than I would be in a scripting language. So I don’t think anyone would ever reach “equally productive” unless they’re comparing themselves to another compiled language.

I like Rust, but it’s challenging, and it’s certainly not a language for rapid development.

> It took me probably more like 1-2 months to really understand how to code in Rust. I do not think a typical team of JS/Python devs would be productive in 3 weeks. I think it would be more like 3 months.

This is actually a very fast learning curve. Imagine a typical Python/JS developer becoming proficient with real, production-quality C++ in 3 months? The very notion seems ludicrous to even think about. So the Rust folks are not wrong when they point out that Rust is about empowering developers and enabling higher quality software across the board.

You’re correct. I actually spent the summer before I learned Rust learning C++. While that definitely helped learning Rust I was barely capable of writing anything in C++ after 3 months. (Though that wasn’t 3 months full-time)

Fair point! I've tried to learn and failed c++ 4 times (I knew C, python, typescript, java), I learned rust in a month after reading a 700 page book.

It's 692 pages, I did it in 5 days, 12 hours per day.

I’ve done C++ in some projects and still think 3 months re-training might be necessary for new language features, and old foot-machine-guns for that matter! C++ is a dangerous beast if I ever saw one.

Our very first Rust project (to learn the language) was a path tracer that was done (fully functional) in 2 weeks. I doubt it would take a team 3 months to become productive in Rust. There's always more to learn, but "being productive" is quite a low bar if they already know basic programming concepts.

With that said, "typical JS/Python devs" might not even know said basic programming concepts, so maybe you're talking about those? Regardless, 3 months is an extremely conservative estimate.

-Emily

A path tracer is a classic classroom project example. I really do not think knowing how to write one is even remotely related to "knowing a programming language" at least in the way it's expected in a professional setting

>"With that said, "typical JS/Python devs" might not even know said basic programming concepts"

If Python / JS is all they've ever used they most likely have gaping holes in regards to many general concepts of computing and some might not be able to grasp those for a loooong time.

Pather tracing / ray tracer are very easy to implement because it requires basic programming concept. It's all about the math not really programming. You can copy paste from one language to another.

Indeed, in fact the raytracing weekend is one of my hello worlds to try out new languages.

I have 30 years in c++, and yeah, rust was easy, but I'll still admit I'm more productive in matlab or julia or pytorch. And I'm still in that phase where I have to check the internet every 10min in python. But deploying in those languages has throughput and/or latency impacts that may or may not be ok depending on the situation. The reliability is also a thing. Assuring correctness in a dynamic language takes a lot more time, more unit tests are needed. It is still faster to iterate to a solution in abdynamic language though. But rather than write all those tests and live with constraints, I usually rewrite in a non dynamically types language.

"equally productive" is misleading. IME Rust is slower to write but faster overall because you spend much less time debugging and maintaining the code.

"If it compiles it works" happens often to me, which is why I'm such a fanboy.

For this reason I'd be much more comfortable jumping into an unknown Rust code base than anything else.

> For this reason I'd be much more comfortable jumping into an unknown Rust code base than anything else.

Rust also promotes simple control flow and acyclic data structures by making writing complex control flow and cyclic data structures extremely hard. Its tpe system is also very explicit about who owns what and about sharing.

Imagine you see the following Python function for the first time:

    def foo(x: Bar):
       foobarize(x)

Although you're lucky that someone included the type annotation for x, and you might know what Bar really is, you still can have no idea whether e.g you can safely modify x in this function. Because maybe something else holds another reference to this very same instance and will be confused if the object suddenly changes here.

In Rust if you encounter:

    fn foo(x: Bar) {
       foobarize(x);
    }

you know there is nothing else holding x, and this function can do whatever it likes with it. You can very quickly deduce who owns what, what is shared and what is not shared. IMHO this helps understanding complex systems very much.

Yes, the key thing about being productive with Rust is that it heavily nudges you towards designs that compose well, avoiding shared state and enforcing a clear, RAII-based lifecycle for every object. There are facilities that you can use when you need something a bit more general than that, but you should only use them when appropriate - ideally, you'll want to document the reason for their use.

It's a very compelling thing about Rust that problematic designs are clearly marked with boilerplate, so you know exactly what to look for and perhaps refactor. There isn't really a close equivalent to this in other languages, e.g. in C++, the "modern" facilities you're supposed to use have the heaviest syntax, and this is often true in Python, Ruby, JS etc.

I really think c++23 and future releases should adopt cpp23{} to designate code where the compiler is allowed to break old stuff in the name of enforcing modern practice.

>"equally productive" is misleading.

You're right... but just to add.

In any Enterprise project involves a lot of talking to other systems(think Salesforce, Netsuite, Slack) or implementing existing protocols(SAML, OAuth,LDAP) and other such things. Python being popular for very long means there's prior work in almost every area. I believe this can be one definition of "productive", basically re-using something existing and spend your time on other better things. In a lot of the same projects performance at the CPU level might not be a bottleneck because you're stuck waiting 10 seconds for an API call to Salesforce.

I'm more excited about PyO3 and other Python+Rust advances, where it seems you can offload lot of CPU intensive stuff to Rust but keep the Python layer and its ecosystem.

In Rust it's easier for me to use the web API's than it is in C++, and in Rust it's easier for me to use the C/C++ API's than it is in scripting languages.

Of course in most projects one or the other usage dominates so my glib response isn't particularly compelling, but in my current project we do use a similar amount of both.

But we still have some Python Django code and will probably end up with C in driver code.

> IME Rust is slower to write

For a backend webservice prototype, that's probably true. It's not true for everything, though. Especially if there are performance requirements or you need to handle errors properly.

I've found Rust to be extremely productive for implementating interpreters, for example, thanks in no small part to algebraic data types and pattern matching. It's not quite as ergonomic as Haskell/OCaml, since you can't currently match under Box's, but hopefully that feature will get stabilized soonish.

I also have used it for computationally intensive apps, such as a poker odds calculator. Going from a single threaded ~24 hr runtime to a ~15 min runtime on 96 vCPU took a few minutes, thanks to rayon. Of course C/C++ with openmp loop annotations is similarly quick for trivially parallel problems, but Rust's built in unit testing and package management make me far more productive for things like this than in C/C++.

I thought this is what would be the case but the reason it is slow for me is not because it takes me a long time to get to compilation. (It’s true but it’s a small factor.)

The reason is most things are immutable. Frankly I’m just not used to writing code in that way (even though most of my scripting code is functional and not imperative). I find that when I refactor my Rust it requires significant work.

In mutable code I can just modify a class/struct when something needs to change but when it’s mostly immutable those changes often require significant redesigns.

Perhaps this is just because I’m new to Rust, but that’s just proving my point that it’s hard. I’m better setup to learn a new language than the majority of programmers for sure and it’s been a real struggle.

At this point I would probably be struggling as much in a language like Haskell I suspect. My issue isn’t the borrow checker, it’s immutability.

Rust only prevents shared mutable data by default. You can always mutate things in a local context (i.e. objects that are either owned or uniquely borrowed) or use the "cell" constructs to opt-in to shared mutable state.

> You can always mutate things in a local context (i.e. objects that are either owned or uniquely borrowed)

You do have to explicitly declare them mutable, though, and will warn you if you have a mutable variable that you never mutate. This is helpful for avoiding surprises.

I agree with this. I may not be able to have a non-working prototype that crashes on its first input as quickly with Rust as with Python, but I can create a working prototype more quickly, and that prototype will transform into production code far more quickly.

Scale up a bit, and you end up with far fewer (often zero) subtle bugs when other people change other parts of the codebase, or when you do a significant refactor - some of these being the kinds of bugs that are difficult to test for.

I would call that "more productive", personally.

>""If it compiles it works" happens often to me, which is why I'm such a fanboy."

This completely ignores domain / logic /algorithmic errors which in my experience completely dwarf types of errors Rust is supposed to take care of.

I think you underestimate memory errors. In large C and C++ projects, ~70% of discovered security vulnerabilities have memory errors as their cause. Source: https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...

On the other hand, Google reports that "to date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code." Source: https://security.googleblog.com/2022/12/memory-safe-language...

Rust is fabulous at avoiding those types of errors. Use rich types to avoid domain errors, use Rust's enum's to hold state data and then use exhaustive match etc to avoid logic and algorithmic errors, use wrapping_add et al to avoid arithmetic errors.

These features are helpful no doubt but would in no way guarantee "if it compiles it works" promise.

Nobody made a promise. The comment you're reacting to said "happens often to me".

It only has to help infrequently for it to be a win. And it helps more than infrequently.

It's not a promise, it's an observation

lets call it a lure.

You can if you want, but it sounds a lot more like FUD than anything else.

If you use the type system well you rarely get wiring issues you would normally get at runtime (wasting an entire "programming cycle" of writing code and trying it out).

But overall I agree: you need tests for business logic.

Another thing that Rust gets right is that you're incentivised to write some tests right in the same file where you're writing the implementation (it just works out of the box with cargo test), so even complex logic is easy to test out.

You don't have to go through the "oh, let me setup mocha to add a test... never mind I won't bother right now"

>"If you use the type system well you rarely get wiring issues you would normally get at runtime (wasting an entire "programming cycle" of writing code and trying it out)."

I assume this goes for scripting languages with weak / no typing.

>"You don't have to go through the "oh, let me setup mocha to add a test... never mind I won't bother right now""

Same thing.

It also depends on the larger ecosystem. If you know Python, it's not just Python the language, but the frameworks, libraries and tooling around it that boost productivity in specific tasks: for example Django and Pandas. Rust may have rough equivalents but they may or may not be as well developed and supported for all the edge cases.

I’d add that this is a great opportunity for OP to treat it as akin to “rustlings” or a possible analogue, where they break different functions that they know work, and building it up again s.t. the tests pass fine.

> The product works great, but the codebase is around 400k LOC of Rust, and we don't have any budget to hire Rust developers.

So learn Rust? You've already said the product works great so it doesn't seem like a reasonable rewrite candidate.

The vast majority of software doesn't need to be super cutting edge, doesn't do anything particularly difficult, and isn't written by geniuses. Honestly, any developer worth being hired should also be good enough to pick up another language during the work day over the course of a few months.

Rust in particular has a bit of a learning curve, I'll give you that (so I've heard, I don't know it well enough to write production code in it). But "it's hard" doesn't seem like a particularly good reason to throw out a perfectly good 400k line codebase.

There seems to me like there is a clear third option here which is for the organisation to buy an online rust course or select some of the (many) free materials online and pay a few existing employees (or new employees with previous programming experience but no rust experience) to do nothing but study those resources for two months before making them the senior devs/tech leads of the codebase. What is it with organisations refusing to pay to train and upskill employees nowadays? It is such short minded thinking to not invest in your own people.

How would you like it to hear that you’ll be a Rust programmer tomorrow if you have been a happy X programmer working on system Y for, say, 10 years?

Tbh mate I think this is a bit of a daft contrarian take. Clearly you would offer it to existing employees to see if anyone was interested then, if not, hire new employees like I said in the comment. If you've still failed to find an employee (who is going to get paid to do nothing but learn a brand new language and then be senior dev/tech lead for it which would be a pretty sweet gig for a lot of people) you would then do the heavy handed approach of forcing an employee to learn it. At the end of the day you can't have a critical piece of organisation infrastructure completely unmaintained and if you have to, then you'll have to strong arm someone in to it, but you should always aim to do that as the complete last resort. And if you are going to do it, you can probably sweeten the deal with a pay rise or other perks. But I seriously don't think you'd have to because if you were a junior/intermediate dev and someone offered you an opportunity like this to both learn a new language whilst getting paid and rise a rank in position and compensation you'd be mad not to take it.

Honestly? I do the job that's in front of me. That has included everything from pre-STL C++, to 90s-era PHP and even Visual Basic for Applications. And a few things even more obscure than that.

I do sympathize with agency's situation—I have actually put Rust into production and been responsible for mentoring programmers to work on it. I like Rust! But I almost certainly wouldn't have chosen Rust for a government production system without making sure that all the stakeholders understood the tradeoffs. Although, it sounds like this was an abandoned R&D prototype that was voluntarily picked up by another team, so I don't necessarily blame anyone involved here.

Personally, the most important trait I look for when hiring programmers is desire to learn. It’s a natural proxy for both motivation and problem solving.

It’s one thing if we are talking about a Dilbert-level “we are going to rewrite our system in X” but learning something new to support an existing system that performs well? At worst it’s good resume material and at best it should be interesting enough to expand how you think about coding.

Not wanting to learn it at all would be odd.

I volunteer as tribute. Rust is on the list of stuff I’d be excited to learn and use professionally, more so than other stuff I’ve only learned by necessity.

I’m just not sure how often it’s worth the effort, compared with the runtime cost of GC and immutability or mutexes.

Kind of the same as with "here's legacy VB/php/ruby/nodejs shit to take care of", but better?

Sign me up!

> Basically the product was developed by a bunch of Rust enthusiasts in a R&D group

This is not a great starting point for any project, never mind the programming language. It could've been C++ enthusiasts, or Haskell, Scala, Lisp or any other language that appeals to enthusiastic programmers.

I've recently been involved in two projects with the same problem - initially developed by a small team of enthusiast level programmers in language X (not Rust). Other people in the team (competent programmers) have trouble being productive as the enthusiasts had gone to the deep end with language features which were not strictly necessary to complete the task at hand.

How does "a small team" end up writing 400k LOC? My guess is that the count may be inaccurate - it probably includes a whole bunch of vendored code that got added to the project because of the high-security environment. Rust and Cargo make it challenging to develop a project in a fully "secure" fashion, C/C++ has a better story there.

> Rust and Cargo make it challenging to develop a project in a fully "secure" fashion, C/C++ has a better story there.

Complete absence of dependency management and a myriad of incompatible build tools is a "better story"?

You can have this "story" in Rust by just disabling crates.io centralized registry. Which still leaves you in a better position than C++ because you can use the build tool and dependency management locally and do whatever you're used to doing in C++ land (put 3rd party code in your repo, install them via some other packaging tool etc). Or if you insist on going the whole way, you can invoke rustc via your favorite flavor of make.

On a more realistic note, if you're working with in a very safety/security conscious environment, and still depend on 3rd party code: you could set up your local package registry and have people vet the 3rd party dependencies. Yes, it costs time and money but at least you get the tools to do it from the language ecosystem.

I've been professionally involved with the C/C++ way of doing things for decades and I find the Rust build and dependency management tooling a huge improvement.

Depends on the platform, VC++ plus NuGET and nowadays vcpkg, make it pretty sweet, same applies to lesser extent on Apple world.

Maybe others should do more that just ship compiler + linker.

However, according to grandparent, it "works great".

Why not just train developers you have instead of hiring new ones?

Yeah, while there is a decent market of remote Rust developers, hiring locally can be very challenging.

Maybe training a C/C++ developer in Rust is an option for you? Of course it's not a language you get fluent in in a single weekend, but Rust also isn't extraordinarily complex.

As a C++ dev that is very Rust enthusiastic. Rust is quite easy to learn if you have a decent grasp of C++.

The biggest thing you need to unlearn is the paranoia.

Regarding paranoia, it will go well if the C++ developer is coming from "security matters", instead of "turn performance to 11" mindset.

And that most things you used to do with pointers (linked lists, graphs, etc.) need to be done with something else.

Typically those things would be enclosed in libraries providing safe and convenient APIs. Sometimes you might need to use a bit of Rc<RefCell> here and there. At worst, you are not any worse than in C++: use unsafe.

If I had $1 for every time someone told me that Rust had a "safe and convenient" API to do something that I wanted to do which didn't actually do the thing correctly or conveniently, I would have a lot of money. This line really needs to be dropped from the Rust sales pitch.

If I did it myself in another language which also has a ton of libraries (eg C++, Java, Go, etc.), there is no reason why I would want to reach for a library for that piece of code in Rust. There's usually a good reason why I didn't use a library.

in c++ often the reason is just that c++ dependency management sucks

I actually don't find that to be the case, since most of the things you need are in one of the mega-libraries from Google or Facebook and the alternatives are often easy-to-find github repos.

The convenience of npm and cargo is offset by the fact that the documentation for most libraries is nonexistent, the creators inject their idiosyncrasies, and lots of library code has not actually been tested very well. Not to mention that the dependencies can change for the worse underneath you, and if you want the old features you had, you have to give up all new developments.

You are not suppose to spamming Rc<RefCell> :p

It's called Single Ownership.

That paranoia is healthy, it gets you thinking about memory and efficiency.

You can be inefficient with Rust as well.

The good thing is that you're less likely to get a null pointer or other silly mistakes / security incidents waiting to happen.

>"Maybe training a C/C++ developer in Rust"

I think any senior level developer with C++ experience should have no problems grasping Rust on their own. Examples and docs are plentiful.

Just hire C++ developers who want to learn Rust. There are tons of Rust developers desperate for non-crypto Rust jobs.

It’s a huge learning curve but it’s worth it. I came to Rust from Ruby and after a few years of practice now I’m at a spot where I would generally prefer using Rust over Ruby.

I recommend rustlings for interactive tutorials to do alongside the rust programming language book. I also just heard a rustacean station episode featuring a pakt author who wrote “ Rust Web Programming” it sounded good.

From the individual developer point of view, learning something new while getting paid for it is the best thing. So if your organization is up for it, I would take that chance without a doubt.

From the organization POV, yeah that sucks

Are you guys C or C++ programmers? (I'm not.) Here's why I ask.

I started with Ruby. Since then, I've branched out to a bunch more, including Rust. Most are fairly easy to pick up.

There is, however, a class of languages I'm totally scared to try and pick up. They're C, C++, and PHP. It's not because they're bad languages, or I couldn't learn them - it's just that all those languages have a reputation for making security holes easy by default. There will be a learning curve where I'm an actively dangerous programmer to be around. I'm gonna just stay away.

If I started with C++, and not Ruby - my perspective would be quite different. I would assume there are dangerous footguns lurking in every other language as well. Learning any language would be a scary thing.

I would try to learn Rust. Its compiler won't prevent every bug or hole, but it's hard to screw things up as you're learning. There's really only one rule, to avoid using unsafe unless you really can be intentional about what you're doing. If it's uncertainty that keeps you from learning - most languages are far more forgiving than what you're used to. And if not, none of these points apply, I guess.

> the codebase is around 400k LOC of Rust, and we don't have any budget to hire Rust developers

That's what you get with hype-driven development.

If you look at the Rust community, it’s split between those that consider Rust appropriate for systems level programming and those that want to use Rust for everything. The back-end Rust comes from the latter part of the community and my impression is that it’s fighting an uphill battle, because the language is not a good match for such software when compared to Java or even Go or Python.

400.000 lines also sounds huge for a web project.

Contrary to other commenters I don’t advise learning Rust just for this project. In general maybe it’s worth it, but web Rust is new, has an uncertain future and likely no job market value. If it was a research project there’s no telling what horrors lie in that code base :-)

> The back-end Rust comes from the latter part of the community and my impression is that it’s fighting an uphill battle, because the language is not a good match for such software when compared to Java or even Go or Python. > > 400.000 lines also sounds huge for a web project.

I maintain a 180k+ line of code back-end web project and I use Rust. Best decision I've ever made.

I serve over half a millions of HTTPS requests per day. Everything hits the backend, no CDNs or caches of any kind. Average CPU usage on a cheap VPS? ~3%. Hugs of death? No such thing for me. It just runs itself without any supervision for months uninterrupted, so I can sleep at night and not get woken up by an outage. And refactoring is a breeze due to a strong type system, plus all other niceties that Rust has.

So for a complex project that you're going to maintain long-term? Rust is absolutely the right choice, even for backend web-dev. A throwaway CRUD e-commerce website made by a random webdev consulting company on the cheap? Okay, yeah, maybe here you're right, and I probably wouldn't pick Rust there either.

Is this a one person operation you’re describing or a commercial project developed by a team which is bringing in revenue? How long has it been in production and how long will it be developed and supported?

My concern regarding web Rust is focused on long-term viability and development speed, not performance which is a given or memory safety which is a standard in webdev.

500,000 requests/day is ~6 requests per second.

You could handle that with Ruby on a raspberry 1

If you're just sending static pages, sure. Not if you're doing significant processing like I do. It's also an issue of scaling, where I could probably serve at least ~1000x more traffic on a single machine (and I know I'll never hit that much traffic). And if you don't need high availability (although I haven't had a single outage is over two years, thanks to Rust's reliability and focus on correctness) this simplifies your architecture and your deployment significantly, because now if you're on a single machine you don't have a distributed system, you don't even need caches, you don't need load balancers, you don't need to administer multiple machines, you don't need Kubernetes, backing everything up is very easy, etc.

(But of course, I'm not saying this is how everyone should do it. I'm just saying what the benefits are for me because Rust's so fast, so it allows me in my particular case to do this, which I wouldn't be able to do with e.g. Ruby because it'd be too slow.)

> The product works great, but the codebase is around 400k LOC of Rust

At a high level, what does the codebase do that it took 400k LOC? CRUD REST endpoints? /s

How long did it take how many engineers to end up with 400k LOC codebase?

If you have 400k LOC why are you even considering rewriting it? It would take way less time to learn Rust then to rewrite something like that.

Sounds like the project didn’t have a continuity plan for how it would continue to be developed or maintained after the grants ended, regardless of the implementation language.

Rust is a hot language and there have been many big tech layoffs. Maybe some Rust or C++ developers would now be interested, even at a market discount, to use or learn Rust professionally?

How can I learn more about the project and your situation? I use Rust at work and enjoy working with it; I've also done some work for .gov in the past and like to see technology projects in the public sector be successful.

Would a full rewrite in a language the devs know better actually be faster than using that time to ramp up on rust?

Yup it's why the language shouldn't be too integrist with its theories or too particular with its syntax, because when time comes to find an intern to survive a few month and they're all swimming in Java and Javascript, you're fucked and you cant even beg a C/C++ oldie to come out of retirement.

Rust might be okay but even Python I would hesitate. I and my team all converted quickly to being efficient java+js+C# devs coming from either of each and I cant imagine working in a company when not only the business and the tools are particular, but the frigging language as well. It's overloading for new comers.

And imagine in 20 years, which is the age of the software I maintain: you d rather fight a Java or C# spaggheti or a Rust spaggheti ? It will be a spaggheti, you can't escape it and last 20 years being profitable.

> Rust might be okay but even Python I would hesitate

These languages are not even on the same spectrum.

-Emily

Reply on news.ycombinator.com