Hacker News new | past | comments | ask | show | jobs | submit login
The Great Rewriting in Rust (deprogrammaticaipsum.com)
38 points by ingve 14 days ago | hide | past | favorite | 24 comments

> Rust will invariably introduce new issues, completely unforeseen as of now. And a new, modern programming language will appear in 2050 or 2060 solving those issues, and the rewrite cycle will begin all over again. And people will wonder how come anyone could get anything done in C.

The question is not "will some new hotness come along to usurp the old hotness," the question is "will the new hotness make software any better." Unless the answer to this question is a resounding "no" (even "probably not" is acceptable), maybe people should try. Please stop complaining that people want to find ways to pioneer in their fields rather than just retreading old ground.

Interestingly, modern C++ is the closest production language there is to Rust in terms of compile time safety guarantees (though C++ is unsafe by default, and that’s a huge problem), type expressiveness, runtime behavior, and so on.

Also, many of the best Rust ideas have been backported to it.

I wonder if it’ll still be in second place after whatever new hotness replaces Rust in a decade.

I would say Ada/SPARK is much closer to compile-time safety guarantees than both C++ and Rust, along with type expressiveness, runtime behavior, and so forth. I wish more people knew about the language and about its current state.

Ada did get a surprising number of things right. And SPARK is a tremendous asset to the Ada ecosystem. It really could have been where C++ is today.

However, I can't see Ada thriving without fixing their licensing. But on the other hand I don't know how well the Ada vendors could survive without charging for their compilers/toolchains.

Many associate C++ uptake to Microsoft, however they completely miss the point that C++ is a platform language.

It was developed on the same building as UNIX (so to speak), as C pre-processor with no additional requirements on C's toolchain.

That made it quickly available across all UNIX platforms and respective toolchains.

Then it followed C as younger brother alternative in any C toolchain that mattered.

A few UNIX vendors, e.g. Sun, did offer Ada compilers, but it was naturally an additional software package to buy, and not everything was available, thus additional hurdles to write FFI bindings.

Not bundling a language with a platform is always an issue with system programming languages.

The thing is, learning Rust is Hard, with a capital H. Even experienced programmers have to work really hard to grasp it. I’ve started the process but the light has not yet switched on.

I want to be great at Rust, but I’m nowhere near there. Getting basic things done like defining functions, passing data remain challenging every single step of the way.

For this reason alone, Rust will remain the domain of dedicated and motivated programmers.

It’s never going to be crowded in this community.

Unless of course I’m a slow witted dunce, in which case, maybe Rust ain’t hard.

Like with functional programming, I'm not sure it's hard, exactly. Maybe it's not so hard if you learn it from the start. It is very different, though. Most programmers are not used to the idea of carefully tracking where, and how, their data ends up in a program. Many high-level languages do heavy lifting to abstract that away as much as possible. Is it on the stack or in the heap? Is it a copy or a reference? How many references to it are floating around? You don't need to worry about that. The implementation will juggle that for you.

Rust is targeted pretty much as a C replacement. And the thing is, you have to do the borrow checker's work when you program in C too.

You must know whether it's copy-by-value or a reference. If it's a reference and it needs to be a copy, you must do that manually. You must know how many threads are accessing something by a reference, and you must guarantee that more than one thread is not writing a non-mutex variable at the same time. You must know when your objects are created, where they go (heap? stack?) and you must track those objects over their lifetime, and then you must free them at the end. (Or tell a garbage collector about them, and remember to run the garbage collector periodically.)

Except a C program still compiles when you don't get that right. And then it segfaults. Rust's borrowing model ends up enforcing much of that as language policy, rather than just good programming style. It's a bit like how you have to cast types explicitly in many languages (including Rust, of course). Any implementation can wrap an integer used as a pointer to guarantee you're not pointing into dead memory. But when the compiler knows the type explicitly, it can often generate fast unwrapped code that is safe and will not crash. All of this comes with explicitness which is burdensome to the programmer, unfortunately.

Sometimes you need to state, explicitly, what should be obvious to allow the compiler to show something is correct and fast. In this regard, Rust is, at least, nicer than C, even when you have to fight the borrow checker. (In my opinion.) Which is probably why it's growing so fast. I don't expect it to displace more than the C niche of systems programming, though.

One forgets how hard it was to climb the mountain once one has climbed the mountain.

You're right, in fairness. It's gruelling sometimes. Five years of on-off hobby programming with Rust and I still fight the borrow checker with every other function. How to implement things in a way that makes Rust happy is often not at all obvious. But the idea does seem useful enough to keep persisting at it.

I'm really curious why some people have such a hard time picking it up. My experience has been the complete opposite, everything just clicked and it all made sense (at least, until you get to the gnarly stuff). What was the difference in our mental models that caused this?

The basic idea clicked pretty quickly with me. A restricted memory model that sort-of guarantees a number of awful things can't happen. Makes sense. But how do I express working things in it? The obvious approaches conflict with the rules.

A simple emulator in a C-style might consist of a UI thread and a compute thread. The UI thread sends messages to the compute thread. You can have some timing though not usually safety/crash issues if you do this without locks. So maybe you do or don't lock that. But the UI thread can pretty wantonly read the compute thread's memory array to render it for graphics and may just get tearing like real hardware. Simple, fast, almost-safe.

How do I express that sort of arrangement in Rust's type system and make it actually safe and fast? It's hard to get that right.

> But the UI thread can pretty wantonly read the compute thread's memory array to render it for graphics and may just get tearing like real hardware. ... How do I express that sort of arrangement in Rust's type system and make it actually safe and fast?

You can use atomic types with custom memory ordering, just like you would in C.

> It's like with how people coming from much higher level languages tend to detest C at first, because you have pointers. It seems like needless complexity. You even have to hold C's hand to step through a simple linked list. Why?! WHYYYY?!

Specially when that high level language was Ada, Modula-2, a Pascal dialect like Turbo/Quick Pascal, or a compiled BASIC, yes really "Why?! WHYYYY?!"

But if that extra complexity and difficulty helps to improve the overall quality and safety of the code people write with it, then maybe it's worth it?

Or put another way, C and C++ make some things easy when perhaps they shouldn't.

I think learning a programming language has similar logic/intuition that learning natural languages has. That is, learning a language that you actually use is much easier than learning a language you don't use. So for instance, if you just read tutorials / grammar books and never actually solve problems / communicate with people you will have a harder time. It matters less how difficult the language actually is -- you can easily spend months or even years wrestling with those tutorials without getting beyond a beginner stage. Then you get some motivation to actually use it for something and you advance in weeks more than you advanced in a year before.

Rust especially, thanks to the efficient hypemachine, will have the problem of people wanting to learn it but not having anywhere to apply it immediately. I actually have a similar problem with French.

I like the analogy to learning a language. The immersion is very important. I did exactly what you said. I didn't read many tutorials I just sat down and rewrote a project in Rust. I don't use lifetimes properly right now (I abuse cloning many times) but I am happy with the progress.

Another thing worth mentioning is that while being a great language Rust is still a tool. Designing the architecture, algorithms, logic of the system, refactoring are much more difficult than the language itself in my opinion.

This is of course why garbage collected languages exist. If you don't need the performance or efficiency gained from having full control of memory, then GC'd languages will offer less cognitive load.

IMHO, programming in Rust is no harder than C++ or C. It just forces one to be explicit about lifetimes and ownership, concepts one should be carefully thinking about in other systems programming languages.

Definitely agreed. I'm just a lowly javascript developer, but getting my head around the borrowing and ownership concepts is pretty challenging for me. Just need to keep practicing though. I still remember the day that javascript clicked for me, so hopefully the same will happen for rust.

Rust is hard, but it is easiER if you did a lot of C programming prior to that (with memory/mutex managment and all). If you did not, i expect the learning curve to be really steep.

Meanwhile I doubt CUDA, SYCL, OneAPI, Metal Shading Language, LLVM, GCC, Qt, WinUI, IO Kit/Driver Kit, will be joining the great rewriting any day now, just to put it in perspective.

..., SYCL, OneAPI,

I'm trying to understand the uptick in references to these projects. Neither are widely used at all, maybe a supercomputing lab here and there, but it's very much in the early stages.

Regardless, they are industry wide standards with heavy C++ focus, and the only real alternative to CUDA, also C++ focused, including memory model.

As for its current state,


Good article. The comparison of linkerd and Istio was a bit weak, especially given the key part of Istio is envoy, which is C++.

I really enjoyed the fonts used on this site. I’ve never seen this style/combination on a blog before. The creator has a good eye!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact