How Rust can facilitate new contributors while decreasing vulnerabilities [pdf]
cypherpunks.ca
cypherpunks.ca
This is how to set a GPIO bit, from the official "Embedded Rust" book:
MY_GPIO.borrow(cs).borrow().as_ref().unwrap().odr.modify(|_, w| w.odr1().set_bit());
Though to be honest I am sure someone will pop up with a much easier and cleaner way to do this.
Which, as others have already pointed out, brings us to the very topic of this post. Rust prevents novices from messing up partly by forcing them to acknowledge ways in which the code might break, and it does that via the type system.
https://docs.rust-embedded.org/book/concurrency/index.html?h...
You would definitely hide it behind a function if you need it, but that's not very useful in a guide that wants to teach you what it looks like without the function
So what you really want to do is unlock the mutex and unwrap all the layers to get just the io pin object, and give ownership of it to the task. Then the task can write to the pin, sleep, and not worry that any other task can write to the pin before it wakes back up. When it comes time to spawn that other task, you can unlock and unwrap another io pin and pass along ownership of it to the new task. Meanwhile the compiler prevents either task from accessing pins not assigned to them, unless they contain the code to unlock the global mutex.
But then you have to talk about how to spawn multiple tasks, and I bet that’s in a different chapter! By the end of the book when all the pieces are in place, there probably is no global variable for the IO pins, no task tries to unlock a global mutex, and instead all tasks take ownership of the pins they need.
Now, something like setting up a DMA on one of the 2 available DMA engines you may have, and blocking til completion via interrupt, that is complex enough it has a much better justification for the abstraction salad.
> MY_GPIO.borrow(cs).borrow().as_ref().unwrap()
This code looks like it's some kind of global Mutex<RefCell<Option<LedPin>>>.
Looking at some other examples, setting an LED pin to high is just `.set_high()` https://github.com/stm32-rs/stm32f4xx-hal/blob/master/exampl...
Though yeah, this example which passes a pin to an interrupt handler has similar dense `.borrow` calls https://github.com/stm32-rs/stm32f4xx-hal/blob/master/exampl...
I think for sharing resources across functions, I've enjoyed using rtic; e.g. a similar example there: https://github.com/rtic-rs/rtic-examples/blob/master/rtic_v1...
*MY_GPIO |= 1;
In C you would have to write all that out. And still have a good chance of getting something wrong first try.
I mean, I find this simpler
procedure x_component .. end
procedure y_component .. end
procedure assembly x_component y_component .. end
In python, rust, C++, java, lisp people seem to form very long procedures with lambdas and some ninja fu to save lines of code and it may look elegant to some people, but I can't read it.
Your trivial one-liner is an example of terribly seductive simplicity enabled by a broken design. It works until MY_GPIO is concurrently modified. Which can happen if the memory mapped peripheral changes the register content on its own or if other code can preempt read/modify/write sequence. To make it worse unless MY_GPIO is heavily contested it will work most of the time.
I'm not familiar with embedded Rust, but it looks like APIs are designed to make the programmer explicitly lay claim hardware peripheral (or fail trying) instead of corrupting the system state. Most of the unwrap() and unsafe code is executed once during setup. Once the hardware resources are divided up and configured the normal runtime code should be a lot less verbose (from a quick look at the API documentation).
It might look better if you split it in lines:
let mutex = MY_GPIO.borrow(cs).borrow().as_ref().unwrap(); mutex.odr.modify(|_, w| w.odr1().set_bit());
* its annoying to write, good tooling helps (e.g. using the rust-analyzer in an lsp enabled editor)
* it's a godsend when revisiting code months/years later, and in reading unfamiliar code.
Some languages have verbosity for it's own sake, but I don't really see rust as one of those - most of it actually inform the reader about what's going on without a need to go track down all sorts of info elsewhere to understand what effects any given line will have.
MY_GPIO.borrow(cs).borrow().as_ref().unwrap().odr.modify(|_, w| w.odr1().set_bit());
let mutex = MY_GPIO.borrow(cs).borrow().as_ref().unwrap(); mutex.odr.modify(|_, w| w.odr1().set_bit());
Probably not clear, but all of those functions are doing something that is helpful in additional checks. As others pointed out, you can set a pointer if you like in a simple line, but that isn't safe.
The verbosity is providing the features, at least it is on one line, instead of 20 or 100 lines.
If you rewrite the code above in a proper C, you will have a page of code at least.
You and other Rust enthusiasts are missing the point.
In C or any C-based language or even Python, you can just call either a function passing the reference to the GPIO pointer, or just GPIO |= 1.
You can't do that in Rust, or no one has shown a much better way to set a bit in Rust without writing verbose code that has dozens of borrowings done.
Your reply amounts to “I don’t wanna tho”.
OP picked upon a sophisticated example that's multithreaded; the example shows off some fancy Rust techniques which deals with this complex case.
It's 'fair' to say that OP's code snippet looks complex. But, it's not 'fair' to treat OP's snippet as if it's how one must write a simple blinky program.
And it's good to explain that the code is complex because it's dealing with a complex case.
I'd somewhat acknowledge the frustration, though. If you're trying to learn something and you take a wrong step or look in the wrong place, you don't have the intuition to figure out "here's what you want to be doing instead".
This specific example is from the concurrency chapter so it's already handling multiple threads and that's why all those checks are needed.
This is a random example I found to blink a led on a rp2040:
> let mut led_pin = pins.gpio25.into_push_pull_output();
>
> loop {
> led_pin.set_high().unwrap();
> delay.delay_ms(500);
> led_pin.set_low().unwrap();
> delay.delay_ms(500);
> }
And this is how to do it using embassy, which is an async framework for embedded in rust:
https://github.com/embassy-rs/embassy/blob/main/examples/rp/...
How can we make code be portable (e.g node.js like) between embedded and other platforms if they differ so much?
By embedded here we are talking about running bare metal on single core microcontrollers with kilobytes of memory and megabytes of storage which are more interested in driving or reading gpio/adc pins than serving a rest api or rendering a webpage
To answer your question, you can't because the difference in code comes from huge differences in the use case and requirements. And trying to force using the same runtime for anything from webservers with dozens of processors and hundreds of gigabytes of ram to the kind of device that barely draws any power at all is going to make no one happy
I only have a passing knowledge of embedded programming but it already seems to me that being able to effectively use this kind of abstractions in this domain is already halfway through a miracle, and probably only possible because the rust team decided to decouple the async model from a specific runtime
*GPIO |= 1;
There's almost certainly some Rust code doing just that somewhere down the call stack in your code above. You just don't get a lot of the safety benefits that come with Rust if you do it like that (although you do get some), so a lot of the library ecosystem has invested in higher level wrappers.
The motivation for doing so is good, but IMO it's been taken a little too far and led to things being over-abstracted. I suspect this will even itself out as embedded Rust matures.
// Set the SDA and SCL pins to input, and enable the internal pullups.
DDRC::clear_bits(DDRC::DDRC4 | DDRC::DDRC5);
PORTC::set_bits(PORTC::PORTC4 | PORTC::PORTC5);
// Initiliazing the prescaler to 1, and bit rate for a 400KHz transmission rate.
TWSR::clear_bits(TWSR::TWPS0 | TWSR::TWPS1);
TWBR::set_raw_value(TWI_BIT_RATE);
// Enable the TWI module, and the ACK.
TWCR::set_value(TWCR::TWEN | TWCR::TWEA);
I could have implemented the *Assign operators for the register structs, but I'm not a huge fan of those. I feel it's a bit too opaque and error-prone, and preferred the clear function names.
One thing that complicates matters is that you need to do volatile read and writes, not just standard pointer access. So using raw pointers, while possible, actually becomes kinda verbose.
As you mentioned and made clear, the implementations in other languages barely have any checks for memory safety.
In Rust, you can do that but you have to write a verbose code.
Why not just abstract this on the SDK level and provide a way so that if you call *GPIO |= 1; it will already do that for you? Or as others mentioned, make a macro?
I believe this is the point the author was trying to make. It's not about the niceties Rust have that make it complicated, it's the fact that you do have to write a whole lot more code for a simple task.
Please, there's no need to make this "us vs them" :) I explained what's happening without saying it's the best approach possible.
> In C or any C-based language or even Python, you can just call either a function passing the reference to the GPIO pointer, or just GPIO |= 1.
You can do this in Rust just fine by using raw pointers (references). The point is, in complex programs (not the example from the embedded rust book necessarily) it's possible to make memory safety mistakes. While in Rust it is not unless you choose so.
This is not about which approach is better, it's a matter of fact. Whether you prefer the one or the other is your personal choice.
Some people have written the equivalent C code for this (`*GPIO |= 1;`). Are the existing C embedded programmers typically not using refcounts / mutexes in their code since they know that they are upholding the invariants in their hardware and therefore do not have to employ these runtime checks, or are they just writing this one-liner out of laziness?
1.Superloop, for simpler stuff. No worries about atomic register writes, at most you have a few interrupts. You don't need mutexes here. The overhead will always be low but it gets very hairy quickly with the more things you try to do concurrently.
2. Rtos-based. Think microkernel but with just a thread scheduler. You might have a dedicated IO thread that handles messages from your worker thread, which may listen to a GUI thread. In this case, you will need a way to prevent multiple threads from trying to use the same resource, whether that is a pin, a configuration register, an interrupt flag that is in the same register as an exception flag and must be cleared atomically via a special shadow register, etc...
If you do all hardware touching through 1 thread you don't really need them, but otherwise, you absolutely need mutexes. And there can be a substantial performance cost to using them too much.
As an example, say you had a UART receive thread that fired from an ISR handler each time a byte was received. You could naively grab the UART mutex and read the new data, clear the flag, and deal with any error conditions, then release it again. Even a 100mhz MCU could have trouble keeping up with a trivial 100kbaud serial stream due to the overhead of using the mutex too much.
RTOSes do have other means for locking resources, but you would want to understand exactly what you're doing and minimize overhead as much as possible. I am not at all experienced in Rust but it seems that touching the hardware directly could end up being a large pain point.
> I tried. I really tried.
You gave up too soon.
That's not particularly gnarly rust. It's just chained method calls like in many other languages.
Admittedly the `borrow().borrow.as_ref().unwrap()` thing looks a bit excessive - does the book not explain it?
Overall the complexity here isn't the language - it's due to the implementation of the access to the GPIO bits.
That was my thought as well, as someone who is not Rust heavy (though I do small projects with it now and then), I get some of what's going on, and I've done a little bit of embedded, I could be misremembering but I don't remember it feeling this confusing or intimidating and that was using C, which to newcomers can be both.
I'm really confused by this method chaining, I would argue its too confusing and breaking it up with comments might be best for newcomers.
‘course, you don’t have monads.
Not that that's necessary, seeing as Rust is already procedural. You can just use regular old procedural syntax.
Its pretty clear to me even now knowing rust embedded what is happening hear.
Globals should be avoided in Rust, unless you have some kind of synchronization strategy because otherwise modifying them is unsafe.
>oh but you could just use a macro!
Or I could just use C and be productive, thanks.
You can almost certainly do the same in Rust in an unsafe block.
You will be happier and more productive unless you get bitten by the lack of locking, reference counting and mandatory initialisation. Which is actually quite likely.
Don’t need any of this crap for a garage door opener. Most firmware is incredibly simple.
pthread_mutex_lock(&mutex);
setBit(&gpioCtx, bitPosition, 1);
pthread_mutex_unlock(&mutex);
But this is never done, because the language attracts people who overengineer. The original commenter was following a beginner’s tutorial in Embedded Rust. They didn’t just unluckily stumble upon something esoteric with too many layers of safety for the functionality they were aiming to achieve. This is how people in the Rust Foundation actually use their language, and it’s how they teach people to use it.
pthread_mutex_lock(&mutex);
setBit(&gpioCtx, bitPosition, 1);
pthread_mutex_unlock(&mutex);
POSIX threads are far more battle-proven than any threading API in Rust. All of the underlying multi-threading on the system you made your comment from is using pthreads. It works fine in reality, despite all the pearl clutching.
>Rust makes it so that you can't forget.
And the tradeoff is an unreadable, puke-inducing one-liner. You can do a (readable) scoped lock with a macro in C (GCC defines the __attribute__ cleanup) or RAII-style with destructors in C++.
You should probably see a doctor about your hyperemesis.
I'm not taking anything out of context. That code is hideous. It's terse. It uses controls and defenses that aren't needed for most embedded applications. It turned a beginner away from the language. When I provided much simpler C code as an alternative, Rust aficionados started to cry about unneeded mutexes, unneeded ref counting, the inability of programmers to remember to call free or mutex_unlock, etc. etc.
> But [writing it more simply] is never done
You're not saying anything interesting, you're just making grandiose false claims to start a flame war. Approach it from a good-faith perspective, please.
I will never miss writing header files and oh so many constructors.
https://github.com/nrf-rs/nrf-hal/blob/master/examples/blink...
loop {
if button.is_high().unwrap() {
led.set_high().unwrap();
} else {
led.set_low().unwrap();
}
}
Also, woudn't the loop need a sleep to make the blinking be observable? this looks like it will be a roughly 50% pwm.
It is a busy loop though, and in a real scenario you'd want to use interrupts instead of a loop like this.
Thanks for explaining it!
`let mut gpioa = dp.GPIOA.split();` to get the GPIO A port from the Device Peripherals list `dp`.
`let pa5 = gpioa.pa5.into_push_pull_output();` to declare which pin in that GPIO port you're using, and set it into a push/pull output (input pull up, input pull down, input floating, and output open drain are of course also defined) and then
`pa5.set_high();` to set it high (`pa5.set_low()` for low).
There are HAL modules for most common MCUs, and a few uncommon MCUs. Use the HAL.
The official embedded Rust book also includes how to write such a HAL, which seems to be the bit you stumbled on. Ignore it if you're not writing a new HAL crate.
[ducks for cover]
(only half-joking...)
As much as the "rust for everything" folks are annoying, wrong programs not compiling is the entire point of having a powerful type system correctly leveraged. This is the kind of task where rust truly shines.
ease of programming != ease of making undetected mistakes
I remember another study which showed that actually, most computer programmjng languages today are objectively terrible in terms of legibility and usability, the alternative was some idealized language that allowed effective communication to occur.
A safe program is not necessarily one that won't compile, if the lack of functionality incurs some danger on its own.
I suspect that a majority of the peanut gallery is rather lazy, or unwilling, or economically unmotivated to put forth the proper effort (and it is the last category that deserves the harshest punishment, where a wasteful and harmful situation is actively encouraged).
Disagree. GCed languages prevent the majority of errors the higher complexity of Rust unloads on the programmer to solve by wrestling with its syntax.
So this is only a plus for Rust, if the small performance advantage over, say, Go, actually matters in an application, which is rarely ever the case in most software written.
Rust has been my favorite language by far to refactor in.
Forcing Rust into a domain where a GC'd language is more than enough offers absolutely zero advantages (yes, you'll have no memory safety issues, but neither you would have had you used Python or Java or Go or whatever), and it's the kind of obnoxious overzealousness that I'm denouncing.
If you're using Rust to write web services you're just wasting your time, I agree with that.
But if the alternative would be C or C++, Rust is at least worth consideration. Ironically, those are domains where you'll have to use a lot of unsafe and/or limit yourself to a subset of Rust, but it's still a nice incremental improvement.
It is refreshing to see that other people share this point of view. I guess we are not disagreeing after all.
There are lots of programs where Rust isn’t necessary, but it still has a bunch nice-to-haves besides memory management.
The other value that Rust adds, that you're ignoring, is control over mutable/immutable access. In Rust, to share data between threads of execution, you have to grab a lock or such. In many other languages, like Go, the lock is advisory not mandatory, and nothing prevents two threads from writing to the same struct field concurrently.
I personally think I'd really enjoy a "GC'ed Rust" for many uses. I wish GC was a Rust feature crates could opt in to, and then the embedded & high performance crowd could avoid that like no_std works today.
[ducks for cover]
[pulled off stage with a cain]
The reason is that actual common memory safety mitigation strategies in real life involve using some kind of smart pointers (same with Rust and C++), or using indices with bound checking (same with Rust and C++, it’s just that C++ STL has this off in Release mode by default…). For both languages, trying to avoid these runtime mitigation strategies (which affects performance) will require doing some level of unsafe stuff which the compiler doesn’t help with you (the unsafe semantics of the two languages are actually similar since Rust relies on LLVM which relies on C semantics). So ultimately, the borrow checker doesn’t seem worth it if you actually think about the cognitive overhead and headaches it brings. The only reason Rust has an edge over C++ is that it has sane defaults and a better standard library (ah only if C++ had a sane way of initializing values…)
You quite literally also have to "borrow check" C/C++ in order to have a well formed program, just without any compiler assistance.
For structs that I do not want to heap-allocate, they're usually POD types and in arrays (which you can bound check), so there's not much to think about borrowing. The more concerning issue I usually have is about about initializing the values correctly (which usually Rust doesn't help, when reasoning about performance-sensitive code).
Both situations which also apply to Rust. Whenever the borrow checker complains you can do exactly the same thing.
> The more concerning issue I usually have is about about initializing the values correctly (which usually Rust doesn't help, when reasoning about performance-sensitive code).
You can use a type-state machine, where the only way to construct the final value is by calling all of the appropriate methods that change the type parameters on the Self type. When that gets compiled it ends up as either a single memcopy of values, or you can make the Self type hold a MaybeUninit value to make the partial construction with no copy at the end possible. I actually implemented that for fun and as it turns out already existing crates that held every field in an Option and then built the final value from those ended up being faster. C'est la vie.
> We also found that the rate of new contributors increased overall after switching to Rust, implying that this decrease in vulnerabilities from new contributors does not result from a smaller pool of more skilled developers, and that Rust can in fact facilitate new contributors.
Which seems to imply the opposite of what you're suggesting, i.e. it implies that Rust makes contributing easier and safer than C++.
I also want to point out that your comment isn't accurate about how Rust's unsafe works:
> [T]rying to avoid these runtime mitigation strategies [...] will require doing some level of unsafe stuff which the compiler doesn’t help with you
(Emphasis my own.) This is inaccurate — the borrow checker is not turned off inside of unsafe blocks, but instead you are given a handful of extra APIs to use. Those extra APIs can be used to do things that the borrow checker would not normally allow (e.g. by converting checked pointers into raw pointers, and then inside the unsafe block, dereferencing those raw pointers), but the borrow checker is still active, and still catches all the same errors as before.
Yup I know that the borrow checker does also work inside unsafe blocks. But when what you primarily do as a systems programmer is establishing invariants in your systems so that you can exploit (or circumvent) the UB-ness of the underlying system (OS/driver/hardware/etc.), and when the borrow checker doesn't really help you with verifying these invariants... The Rustonomicon states that whenever you open up an unsafe block, it doesn't pollute only the scope, but the whole module (https://doc.rust-lang.org/nomicon/working-with-unsafe.html). So there can be a correctness issue outside the unsafe block because it disobeys the invariants implicitly set up by the developer inside the unsafe block. And you can't do anything about this other than carefully reasoning about all the various ways your implicit invariants can break inside the whole module. So unsafe is ultimately more of a convention (or a promise) that you have designed and verified your invariants correctly, so that you will not produce undefined behavior no matter how you use the module as an outside user. If you want to verify your invariants any further than that, you need to check UB at runtime using the Miri interpreter (which is really slow and still incomplete), or just use Ada SPARK.
mod name_of_module {
// code goes here
}
This leads to a really nice gentle onboarding flow where inexperienced users can start out contributing to the safe parts of the project, and (optionally) move on to gnarly unsafe bits later when they are already familiar with the project's codebase. It also dramatically reduces review workload for maintainers as they can rely on the compiler enforcing invariants outside of unsafe modules.
This works less well for really low-level code like embedded code or kernel code. But it's still a lot better than nothing.
Maybe there's a reason why game developers have primarily used scripting languages - give out a safe managed GC-backed runtime for the majority of developers, and let only a select few who understand the system to develop the core C++ engine. Maybe Safe Rust can be used this way (as a "fast" scripting language), to separate between these two worlds... but the problems is even Safe Rust is just really difficult to grok for newcomers, and the hoops they go through to circumvent the borrow checker either falls into using Copy/Clone all over the place (slow) or smart pointers (slow) or array indices with bound checking (maybe less slow but more cumbersome, and also prone to logical invalidation errors if you're not careful)
Are smart pointers like Box, Rc and even Arc any slower than any scripting system you'd "hand out" to most developers from your tightly written C++ core engine?
One thing that I see is that 90% of code is simple enough that you don't need to have any ceremony around ownership beyond writing a & in front of a value or type, 5% is harder than that but doable, and 5% requires extensive expertise to avoid allocations, or using Arc. I'd wager that the distribution of code that a GC can optimize during runtime is comparable, if not worse, at higher memory consumption.
I've compared some simple networked applications written in Java and Rust for that purpose, and performance ended up being comparable, but with 100x memory consumption, even when using GraalVM.
It's been a while since I last did something in Rust, but I remember that the shift to Rust 2018 was a huge step forward in this regard.
It's easier to program if I don't have to worry about ownership/lifetimes. -- Garbage Collection allows not needing to worry about lifetimes; and preventing the same value from being mutated from multiple places in the code generally isn't such a significant problem.
With high level programming (in JavaScript), you don't have to pay those costs.
I like to believe that Rust's strict discipline about ownership/lifetimes encourages code that's fast/lightweight, though.
Imagine a person who just started learning about programming. A person who may still be tripped up by the fact that `=` and `==` are completely different things here.
Imagine that person.
And now imagine explaining to that person a language, that even many experienced and skilled software developers say is significantly harder to learn than the average programming language.
Sorry, but when I think about a good teaching language, Rust isn't the first thing that comes to my mind.
Python, go or (a bit less so) typescript are nice beginner languages.
Because C in and of itself, is an incredibly simple language. It is made complex in libs, usually by abusing macros, or by trying to shoehorn it into OOP, FP, or whatever other paradigm is currently being idolized.
> Python, go
Go yes, Python no, and I am saying that as someone who does alot of work in Python and loves both languages.
Because Python isn't simple. It looks simple in trivial code, but hides an enormeous amount of complexity and magic not-so-far beneath the surface. In addition, it completely fails at teaching core concepts of memory, and dances around the topic of types.
Python's hiding of memory is a feature when teaching beginners programming IMHO unless you want to start teaching close to the metal. I prefer to start from the algorithmic CS-y side.
No it really doesn't. Initialize all variables, always check boundaries and free memory when you're done with it. That about covers 90% of it.
Yes, this becomes more difficult the less trivial the codebase becomes. But beginners don't have non-trivial codebases, and teaching these concepts isn't hard.
> Python's hiding of memory is a feature when teaching beginners programming IMHO unless you want to start teaching close to the metal. I prefer to start from the algorithmic CS-y side.
And I prefer to start from the systems-programming, practical side. And in the practical world, memory isn't some abstract thing that may or may not exist, function calls cause overhead, strict typing is a friend, and networks fail.
So yes, teaching a bit closer to the metal has its advantages.
Rust is hard for older programmers because it's hard to FORGET old habits from other languages, which allowed too much.
No, it isn't, by any metric. I personally know people who learned C in a week. I learned all basics of the language in 2 weeks as a teenager, with nothing but K&R as learning materials.
If you disagree, point out by which metrics you consider Rust to be easier to learn than C, and we can have a discussion.
> Rust is hard for older programmers because it's hard to FORGET old habits from other languages, which allowed too much.
No it isn't. First, both newcomers and experienced programmers consider Rust a more complicated language than most of its contemporaries, and if anything a solif experience in multiple programming languages makes it easier to learn the advanced concepts Rust relies on.
Better by what metric?
> more syntax sugar
More features and syntactic concepts don't make a language easier to learn.
Rust is only appropriate for programs that are too expensive to run when they are written in a garbage–collected language. That means operating systems, because small inefficiencies there will add costs for billions of people. It means big server–side services, where small inefficiencies cost you millions in compute time or ram usage or whatever.
Even if you think you’re going to hit that scale one day, writing your prototype in a garbage–collected language can net you a huge advantage in time saved. You can rewrite it in Rust later, after you know exactly what features will be needed and exactly what they cost to run, and exactly how much you’ll save by rewriting it in Rust.
But still I'm learning and using Rust for a project.
Its about the willingness to break that wall down you have in your head not about how intelligent you think you are.
The most intelligent devs at least from there own opinion have written the most shity code I have seen.
Pointers are unsafe, so use "unsafe" keyword when dereferencing them.
Kind of disagree here. Don't really think it's that much harder than C++, just hard in a very "annoying" way. Which, given its purpose, is a good thing. Making the borrow checker happy is mostly an exercise of going up and down method call chains to see where you screwed up. Or verbosely wrapping stuff in Arc<Mutex<T>> to make it a shareable resource.
Rust isn't about being more intelligent, Rust is about being willing to jump through more hoops to get a guarantee that small subset of errors may not be in the executable.
I don't have sufficient experience with Rust to determine whether or not only a small proportion of programmers will master it. However, if that is indeed correct, it also means that it wouldn't be worth the investment for most of the software industry to switch to Rust. Because mass adoption is, by its very nature, about what average programmers can master.
If the assertion is that Rust is unsuitable for the average programmer, then the consequence would be that C and C++ are unsuitable for the average programmer... and yet average programmers have been writing C and C++ for decades.
I'm closer to an idiot than I am to a genius, and yet I write Rust all the time. You'll be fine.
That seems like a dubious line of reasoning. People learning the shiny new thing are going to be itching to use those skills in a (non-local, non-hobby) project, and that seems a much more likely explanation for why contributors increase during the stage where Rust is still shiny and new. An old codebase in an old language doesn't have nearly the same appeal, where contributions are going to come mainly because people want to scratch their own itches. It's a false comparison that doesn't contraindicate the self-selection effect at all.
Rust, even as a learning exercise, makes you think about a lot of concepts you'd normally not notice. It is a fun language, fun to experiment with, and due to its learning curve, it'd be far less stressful to learn the basics ahead of time if you ever needed it.
I used Rust-python bindings on a small project where we didn't want to use big python math libraries for portability, but a few of our calculations ran really slow on python primitives. Re-wrote a couple functions in Rust for a 40x speedup and its fully switchable to return to the original python implementations.
Yup; in that case, I am sorry, there is nothing science can do for you (｡•́︿•̀｡)
Nobody is saying this, despite what some people with overactive persecution complexes want to make you believe. As for prescribing what people should do, I will say that curiosity is an essential part of improving in any field, including software development. Learning anything at all broadens your horizons and threatens to make you better. If you don't know Rust, go ahead and learn it (or anything else that interests you); if you already know Rust, go learn something new. It would be quite silly for someone to assume that no advances to the state-of-the-art have happened since they first learned to program.
Modest c++ knowledge means knowing that you should better not try using that knowledge, which is quite terrible as an on-ramp.
You're suggesting that you can actually decide this for other people? Hahahah! :)
That being said, you "should" never to deign to decide for someone else what they should do. It's a responsibility violation because you decide "should" for you, I decide "should" for me. No other way. Get it? :) hahaahah
The idea above comes across as condescending, hope you can remember that next time you are loading a "should" into the chamber! Haha :)
Regarding the utility only existing for C++ devs, I get if that's the way it looks for you, tho that's not how it is.
It's important to keep an open mind regarding the value of learning and what can be helpful and appreciate that there are a variety of approaches that work for different folks! :)
If you want to give Rust a go through Jupyter Notebooks, check out https://datacrayon.com/data-analysis-with-rust-notebooks/set...
While you're learning, take shortcuts; e.g. use .clone() and/or .to_string() liberally to avoid values going out of scope. When you want to speed up code you can do the opposite.
Egui is a great well-rounded immediate mode GUI library that you can use to get up and running fast.
The Rust implementation of SDL2 is pretty good too. There are plenty of examples online you can borrow from.
Rust: You spend 45% of development time fighting with borrow checker/Rust syntax.
GC-based languages: You spend those 45% for anything else you like...
If it doesn't compile, you have to fix it, probably right after you finished typing it. You still have the overall idea of what you were doing fresh in your mind.
If it compiles and then something weird happens a week later, you may spend days trying to reproduce it, then you'll have to pull out valgrind/ASAN, look at the dumps of that, figure what the hell does it mean that something goes wrong in the bowels of the STL/some other library, then backtrack from there to where that interacts with your code, figure if it's indeed a you problem or a library problem, remember again what this weird code is supposed to be doing, then finally fix, and do testing.
Only a beginner. I spend practically no time fighting the borrow checker because I figured out how to structure my code to not have issues.
Assuming the paper is actually relevant given anyone can post any PDF to hacker news and make it semitruth.
Rust with GC is somewhat like ocaml with ...; instead of let ... in.
Completely unrelated: there are at least two dedicated anti c++ communities.
Because it's false, that's why. Modern C++ still has many/most of C++ problems. It solves a bunch of them, but far from all.
And telling the opposite to newcomers is a lie that's hurting them because they can end up making even more mistakes than the previous generation, since they were told they didn't have to pay attention thanks to “modern C++”.
I'm not a C++ user but I thought that all of these things are still in "modern" C++, that the new editions only add things, not remove? Are there tools that can automatically rewrite existing code to use the "modern" features?
Both are problems with siding, one is far more serious than the other. I'm not a fan of Java, but cpp people being disingenuous is a pet peeve. "Modern" cpp still sucks, it just sucks less - it's not useful to pretend otherwise.
Our cloud service at Sococo, back in the day, their principle bug-tracing activity was Java null pointers. The second? leaks. Both problems with pointer management.
However you slice it, it takes discipline to get memory allocation right. No magic bullet.
But they do lead to service downtime, loss of opportunity, broken contracts.
Not really the same, but important as well.
Writing inefficient safe code is easy(-ish). Writing efficient safe code is hard regardless of using Rust or not.