Here at Hackaday, we are big proponents of using the best tool for the job (or making your own tool if required). But when all you know how to use is Java, everything looks object-oriented. Bad jokes aside, it is important to have many tools at your disposal to allow you to choose wisely. Why not spend a few minutes with [No Boilerplate] and understand the basics of Rust?
The focus of the video is to go through as much Rust as possible and teach you how to read it. The idea is that rather than work your way from basic concepts, [No Boilerplate] will go over the vast majority of what you’ll see in a Rust-based program. Whether you’re coming from an object-oriented, functional, or just plain C-based background; you’ll feel comfortable since he makes an effort to compare to what you already know. Some of Rust’s more unique features are covered such as mutability, scope, matching, and strings. However, lifetimes, closures, and traits were left out to keep the video short. These topics are covered in an excellent blog post by [Faster than lime] which this video was based on.
What isn’t discussed is running Rust in a no-std environment like a PIC32. Rust has seen exciting development over the past few years with the Linux kernel getting rusty and the compiler getting continually better. Video after the break.
Is there somewhere some summary what real problem Rust tries to solve (and really solves)?
What I mean is; considering how small part actual coding is of the software projects, is it really worth learning and switching technology because the benefits are so big? Learning, adapting and getting to same level as “previous” language is not cheap.
I also assume Rust brings another new set of problems and pitfalls.
Let me try:
First let’s start by prefixing “really solves” with a grain of salt. Nothing is truly really solved, but the complexity is reduced. With that bar in mind, let’s examine an old familiar language – Java. It’s most prominent feature was the introduction of garbage collection as memory management. Promising to solve memory leaks and such. Now memory leaks are not really solved in Java, if one tries one can leak memory, however the complexity of managing “dynamic” memory is arguably reduced – as in while programming in Java you don’t spend much time thinking about who owns this object and when does it need to be “freed”. The system does the right thing most of the time and if you really have a memory problem there are some tools to help you out.
In similar effort Rust tries to solve several “problems” – like object ownership, managing “error” conditions throughout the program etc. These are not truly “solved” as it can never happens, but the language provides features where most of the time you don’t think about these things and the “automatic” solution works well.
As with all “magic” solutions they work well until they don’t. For example the Java GC can get you in a bind, because it can block the whole process for some time and if quick responses are needed you are out of luck. Debugging and troubleshooting these can be tedious as the system tents to obscure what is going on and one has to dig deep into the runtime.
At the end of the day it is a tradeoff, do you want to solve problems all the time or really hard problems from time to time. Rust and Java creators are betting on the latter. Clearly Rust is becoming popular so others must agree.
Thanks for the long answer.
I usually find out just listing of problems “fixed” rather than looking at big picture. Programmers fall in love in such things easily. “Ah! Finally a programming language that does X!”. But what problems it induces to the system?
Rust syntax seems so different that learning the quirks of it takes time. I don’t understand why the dialect must be changed from some known ones – just use Java/Python/C syntax as much as possible and make changes little as possible. That reduces learning time. Java did great choice by borrowing C++ and C# did the same. I’m not saying that those languages are better than others, but just to give an example.
Not to speak of the completely new infrastructure. I don’t think it comes without a cost. How long does transient from Java/C programmer to same level programmer in Rust takes?
I cannot prove it but I’m afraid the Rust hype is partly because it is new and people are fell in love easily with all the new rather than thinking of the other side, the ugly one.
As it is very new language there might be quite little real life experience of how it has reduced the labor of writing programs and most imporant – troubleshooting. That of course vary from project to another but before jumping ship, that needs to be put down reliably.
It is the human hours that cost. And we need to get the investments back. How long does it take with Rust? And do we actually get back the lost time of learning and building Rust infrastructure?
I’m not sure if my other (longer) reply went through, but one more point to add:
You ask how much time it takes for a Java developer to gain equivalent skill in Rust. I would argue that, if this takes a long time, then the developer will come out of it a much better *Java* developer too.
Why?
Rust doesn’t do any magic garbage collection for you. It just forces you to prove to the compiler that your code is memory safe. It doesn’t enforce any particular design pattern, but developers naturally find themselves structuring their code in ways that makes memory management easy. If you write a well laid-out program, the compiler can clearly see that your code is safe and you don’t need to do any extra convincing. This knowledge translates directly back to C, and conversely good C developers will have a relatively smooth time learning Rust.
As a side effect, people also end up just writing better code in general, with a lot of principles that apply to GC languages like Java.
A couple of points:
Rust syntax IS similar to C wherever it can be. Any departures are there for good reasons. When I learned Rust, the syntax was very easy to grasp. Often, when Rust changes something it ends up being more intuitive.
When people say Rust is hard to learn, they’re largely talking about the borrow checker. I, too, spent most of my time here when learning. This does, as you say, introduce lost time. In places where the existing language is sufficient, switching to Rust is probably not worth it.
However, there are places where the existing language is NOT sufficient. I would argue that this category includes pretty much any project written in C or C++. History has shown time and time again that humans (as a whole) just aren’t capable of writing memory safe C. Ridiculous amounts of money are lost to memory safety bugs every year (security exploits, crashes, etc).
This is such a big problem that many languages have been created to solve it – Java, C#, etc. However, none of them are systems-level languages like C/C++. This is why Rust really is a huge deal – it’s the first serious language that is both capable of replacing C/C++ pretty much everywhere, and solves memory safety like all the GC languages do. This is so big that many companies are now willing to pay with their employees’ time to switch to Rust (at least for new code – although many big projects are being rewritten, too). The fact that Linus Torvalds, the conservative old guard of FOSS developers, is willing to accept Rust into the Linux kernel says a lot. This is a man who hates hype and loves C, often to the point of being unreasonable.
Lastly, something to remember –
For every person who has that irrational “Whoa, cool! This must be great because it’s new!” reaction, another will think “Ew, this must be awful because it’s new!”. You said yourself – “I cannot prove it, but…”
That’s the “Yuck, new stuff!” gut feeling kicking in. I encourage you to learn some Rust yourself, try to understand *why* it’s getting all of this attention. After using it for a number of projects (some, high-performance embedded projects which I’ve also written in C), it’s really looking like it’s time for C to go the way of the Fortran.
I hope I’ve given you an idea of what fundamental problem Rust solves, and why it’s a problem worth solving.
> just use Java/Python/C syntax as much as possible and make changes little as possible
I just want to point that out Rust’s syntax is not at all novel and is not at all exceptional. You’ll find there huge similarities to Go, Kotlin, perhaps Ruby and some similarities to Python, some say even to C#.
I’ve started with C, C++, Java, (and Bash) around 2009 and only from 2016 onward I really started exploring other languages. And now in 2022 I really have to say – and bear in mind that it’s a personal opinion – that the C-like world is really secluded in syntax but not just in syntax. Whole ecosystems and tools for C, C++ and from very big part even for Java are *massively* dissimilar to the rest of the programing world.
If your use-case needs or can benefit from zero-cost abstractions, if you want something so low level that you can almost predict in your head what instructions would be generated and yet optionally do very very very complex things, if you want in a standard way without compiler specific pragmas and __attributes__ control calling convention of some functions, create naked functions for interrupt table for MCUs, etc.. then Rust is a language for you from *the* mention rest of programming world.
I’d like to give my two cents.
Rust is a fast language, so as far as I know it’s mostly a competitor to C and C++. That’s because Python, JavaScript and Java are not adequate tools to write an operational system or an embedded software; rust is.
Then let’s go back to C or C++.
Those languages were created decades ago, when concepts like unit testing, modules, smart pointers were not much used. Sure, the languages incorporated these concepts, but they are *additions* to the languages and, as such, sometimes, the syntax is far from clean.
A simple example: in C and C++ we must create a .c and a .h file (or a .cpp and a .hh). Even worse, the .h file need guard clauses!!! I can understand that limitation in 1970, but not today. To me, that’s weird and tedious. (It seems C++20 solved this problem, but… It’s another addition).
So rust is like a fresh start.
As another example, Rust incorporates a package manager, similar to Python’s pip. Who knows, C++32 will incorporate that too :-P
Managing memory leaks is a “nice to have” from garbage collection. The important thing it does is eliminate an entire class of bugs. No more using unallocated memory, no more buffer overflow vulnerabilities.
That is the theory. I do however remember the days where we had daily exploits for the JVM in the browser, to the point that it is no longer a thing.
A few months ago the whole “internet” had to upgrade servers because of a log4j bug. So you win some, you loose some.
On average if I have to write server code, I’m much more productive in Java, than C++ mostly because of the reduced complexity around memory management.
In an embedded device – depends on the type of work. There are the very constrained devices, where you need to know exactly what the code does and C is “king”. You just don’t do any dynamic memory management. Test and “hope for the best” when it comes to pointers.
In a more complex device where you add network connectivity, I can see where Rust can provide more streamlined and secure coding environment.
This isn’t a new thing. Ada has been doing it for years. Why use rust when you can use a proven commodity that has been successfully used in thousands of real time safety critical applications.
Easy. Performance of C/C++, but designed with concurrency in mind and memory-safe unless you force it not to be (without GC!), which should only be in low-level drivers. The time spent learning it can easily be made up by not having to solve just a couple of memory leaks.
Now, I’m not a Rust evangelist, and learning it definitely won’t be worth it for most hobbyists, especially as writing what Rust considers memory-unsafe can be very useful in baremetal embedded. I still have yet to use Rust in a project. I see it as a language for larger platforms that still need to really care about performance.
Rust solves mostly the problem of memory safety issue in C/C++, while being a language that does not have a GC and match the performance of C/C++.
Besides, rust solves multiple issues that can happen a lot. In Rust, if you want to have a value that can be null you must declare it explicitly. Same with error, if a function can result in error, it must define it explicitly and the caller is required to handle all possible error either explicitly propagate the error upwards or do something else. This enforces good code as whether a function can result in error is obvious from the function signature.
Another problem rust solves is concurrency. You can only do thread safe stuff as it is restricted by the type system itself. A data structure not thread safe cannot be passed through the thread boundary and must be wrapped inside something like a mutex for the code to compile. This can prevent a whole class of error related to data race.
Rust is a language with proper macros. This alone makes it interesting and useful.
The biggest problem I have with Rust is that there is no formal specification, much like PHP. Like PHP it has evolved significantly over time. As a result, there is only one compiler… just like PHP and Rust is exactly what the official compiler does and anything else is wrong.
Any language without a formal specification is subject to the whims of it’s compiler authors.
On the upside, they use 32-bit unicode characters for strings.
I would have to agree with that. A ‘1.0’ specification needs to generated. That would give it some ‘maturity’ so to speak also. Especially now that a Rust front end has been approved by the GCC steering committee. Otherwise one is just chasing the tail of the dog so to speak.
This is being worked on. See https://ferrous-systems.com/ferrocene/.
The only reason for some to use Rust is that they have never heard of Ada. Ada is THE language for safety critical, real time, embedded applications.
Rust have proper macros, Ada does not. You cannot even compare meta-languages with limited languages, they are in a different league.
Remember that Rust is NOT a object oriented language.
It is data oriented.
Rust is not a high level language, it’s low level.
So in rust, you look at your objective as a series of data to be constructed, rather than a series of objects to be created.
For example you create a enumeration and structure for a table, it contains data like number of legs, material, color, and weight. It’s still not a object, as you have to see it from a computer’s point of view, it cares not about a human’s opinion on things.
Whereas in the object oriented process you start by looking at a object you want to create and then stitch the pieces to it to make it function like your ideal object.
It’s like comparing “inside out” to “outside in”…? As humans we try to tie everything to a analogy in our heads so we understand it better, but the process of doing so can warp our perception of new methods or techniques to be possible.