pslam

* can I get a good job programming in this? Without moving to another country or continent.

Yes, there are many large companies which are either actively deploying Rust, or planning to. Easily found if you search.

* is my industry showing interest in it?

Yes: security, high reliability, availability and safety oriented industries. Any industry looking to get themselves out of the entrenchment of C/C++ but still needs at least one of the major reasons why it persists.

* is any industry showing interest?

I haven't found any industry, primarily focused on software development, which isn't interested. I've been actively poking around to see which way the wind is blowing. I honestly haven't come across any industry which would actively say "No we're good with C", other than those were software is an annoyance which they grudgingly have to be involved in.

The problem is it takes more than just implementing the "kernel" (as in low-level access aka HAL) work under L4. You need to apply that compartmentalization all the way through the stack, and even subdivide applications into smaller chunks of responsibility.

What you typically get is a neat subdivision of all the HAL bits, but everyone stops once they're plugging in applications. This is partly because there's normally a large amount of shared/legacy code which needs importing, and partly because people don't recognize the benefits of partitioning an app.

It's not all bad - at least you can be reasonably confident that one compromised app, or part of the HAL, can't be trivially used to compromise the rest of the system. But, as you say elsewhere here, if there's just one thing you're doing, then all that effort didn't really improve things.

If you scan through the source (on github), the most notable thing is the lack of the "unsafe" keyword. I've seen too many people basically transliterate from C to Rust, along with all the unsafe operations. This one is pretty much unoptimized, but still seems to be performant enough, and doesn't do anything "unsafe".

That's not to say you could just throw this into the back-end of a public-facing website. It's still going to panic (abort) if someone unexpected happens, and it's still going to chew indeterminate amounts of CPU, memory or storage unless sandboxed (maybe even just ulimit). And there's still the danger one of the Rust standard library functions has a flaw in it. But this is the kind of starting point you wouldn't get with the plain C equivalent.

> Though such cases have been few and far between, soundness bugs have shown up in Rust, and some oddities in the way RAII works have lead to the notion of Prepooping your pants[1] to avoid use-after-free bugs.

There's a huge difference between checking your program for memory model violations, and checking the compiler for correctness.

Given a program written 99.9% in safe Rust, and a minimum set of unsafe stubs (trivial enough to prove) to access outside world (syscalls), you can assume you're safe against RCE. The holes are more likely in the supporting logic outside your program - kernel, dynamic loaders, network stacks, debug/trace interfaces, row hammer, etc.

> Rust is a phenomenal language, and one I'm placing a lot of faith in, but it provides only very specific guarantees and it's unwise to assume it will protect you from more than it actually does

I do agree with this point, though. It guarantees you will not escape the envelope of a specific memory model and defined behavior, up to the boundary of "unsafe" blocks, and assuming the runtime environment is not interfered with externally. You still need all those externalities to be secure, and it does nothing for leakage through side-channels.

I think it's fair to have a high level of confidence in freedom from arbitrary code execution, buffer overruns, double frees, etc.

It does not, however, follow that it will be free from leaks of secrets. There are plenty of ways to leak secrets which don't involve the program leaving its envelope of defined behavior. No language is free from that.

I know it's not the point, but having this publicly available in such a usable form - even with this bare minimum UI - is a huge milestone. A big barrier to adoption I hear from many potential users is, "Are there any big users of Rust yet? No? Why would we?" This answers that.

Half jokingly, all you need now is an emscripten target, so it can be run inside a browser, and anyone can try it out without needing to install an app :)

Looking at the coding patterns used in the C source, I am utterly horrified this is running live on a public facing website.

I can see at least one buffer overrun dependent on database contents, and I wouldn't be surprised if there's public-facing vulnerabilities in this thing, but I don't want to spend another 5 minutes looking.

> If your goal is purely to make Rust as safe as possible, then you should advocate the view in your comment.

> If your goal is to increase Rust adoption, and/or decrease the use of less safe languages for development in the future (in whichever prioritization of the two you like), then IMO the route described in ekidd's comment seems the quickest route there, IMO.

My view is this is a false dilemma.

The "performance" case is not performance, because the benchmark is broken code. It does not work, because it is not secure/safe/reliable. It is incorrect to compare the performance of code compiled without overflow checking against code which is compiled with it enabled. They simply aren't the same program.

A correct performance comparison would be a program with manually inserted overflow checks everywhere, against a program with the overflow checks done automatically (by compiler).

Or, a performance comparison where code is selectively opted-out, where a critical path bottleneck is identified.

The same can be said of the performance comparison of "array index bounds checking". One program works, the other does not, so it isn't a fair comparison.

> if the performance cost can be made low enough

I think that's the wrong way to look at it. How about instead:

"Checks can be disabled if the safety cost is worth the performance increase"

The "performance case" is a false baseline. You never had that performance in the first place, because your code didn't work.

> 2. Run-time panics. This includes "index out of bound" errors, integer overflow errors (in debug builds only), and assertions inserted by the programmer. This is Rust's second line of defense, so to speak.

I still argue, to every Rust user I meet, that they should turn on overflow checking in Release builds too.

I strongly disagree with the idea that it's a Debug feature only. If it's not always on, then it's not actually a language feature. The performance hit, if you selectively opt-out for profiled critical paths (and thoroughly review them), is usually very small.

In my opinion the default should switch to "opt-out" instead of "opt-in" for Release builds.

> The joys of IT. Back in the day, to wipe years of records you had to burn or shred tons of paper in multiple locations. Now you just crash one little system. [...] most organizations will still have a single backup system for any given data repository -- if they have one at all.

No, back in the day, you could still wipe years of records because most people only used a single filing cabinet with no duplication or off-site copies. "Destroyed in a fire" was the canonical way to destroy all records, easily. This story has nothing to do with the introduction of IT. Incompetence is still incompetence.

The short version is: as small or large as you want to trade-off convenience vs performance vs size.

I've made useful firmware for a micro-controller (yes in Rust) which is just 5KB. You can, as the article shows how, dynamically link and then it's about the same as the equivalent C/C++.

The point is, there's nothing inherent about Rust - the language - which results in binaries appreciably different in size to what you can achieve in C/C++.

I very much believe overflow checking should be on for release builds, and not just debug. Overflow is defined by the language as an illegal operation, but if it's only enabled by debug builds, then it's effectively defined as "somewhat" illegal. I think this gives the community the wrong impression, and a firmer stance should be taken. This is a killer feature, in my opinion.

In practice, for anything which isn't a micro-benchmark, it's a negligible performance hit. For things resembling a micro-benchmark, you can specifically use wrapped-arithmetic operations, or disable it for that module.

I see a strong correlation between people complaining about overflow checking overhead, and people who don't actually care about the safety features.

> Up to now, their customers have demanded performance. It's not their fault for listening to them.

I disagree - it is almost entirely their fault for listening to them. Customers usually don't know what they really want. "Faster horses". The whole point of having an oversight committee is to steer the language, and they failed at the task.

Rather than steering towards sanity - which C/C++ badly need - it was steered towards performance at pretty much all costs. The result is a broken language: it is extraordinarily difficult to write correct programs, and assure that a program will continue to compile as intended many years in the future. Sanity, correctness and fragility are exactly the kind of things which oversight should have tackled, but instead we got the opposite.

I say this as a decades-long user and fan of C/C++. But I've come to realize recently that it's a lost cause, because those in the position to fix the language are powerless against the wishes of their customers.

There are roughly 4x as many iOS, Android (and runners-up) sales and growing. The graphs continue to trend in that direction. IDC is infamous for continuing to make useless comparisons which show PC sales to be better than they are. Possibly (if cynically) it's because that's who still pays for the research.

PC sales, even as narrowly defined by IDC, are now a small minority of total personal computing volume and profit. This shouldn't be surprising to anyone

> 10/20 years later x86 is everywhere from the Macs to high end servers to lowliest tablets. The latest Atoms are actually very good.

10/20 years later, ARM represents the vast majority of both volume and profit in home personal computing. x86 is only "winning" if you define a very small category to compare against ARM.

> ARM meanwhile dominates the lowest end, but no one really makes money out of it. I think Intel was wise to avoid.

Edit: Meanwhile the "PC" category became largely irrelevant. That's what Intel missed.

> “The thing you have to remember is that this was before the iPhone was introduced and no one knew what the iPhone would do…At the end of the day, there was a chip that they were interested in that they wanted to pay a certain price for and not a nickel more and that price was below our forecasted cost. I couldn’t see it. It wasn’t one of these things you can make up on volume. And in hindsight, the forecasted cost was wrong and the volume was 100x what anyone thought.”

This was an interesting time for embedded microprocessors. I was a big fan of DEC/Intel StrongARM and XScale, and the team I worked with preferred using them in designs.

I disagree that it was simply an economic choice, and I think anyone who worked in the ARM embedded industry around that time would also disagree. The move to sell off XScale was after years of neglect. The most obvious defects were the PXA250, which could only cache write-thru due to a bug (Wikipedia does not mention this), and the lack of USB2.0 high speed, despite it being a key feature of every competing SoC.

It was obvious to everyone in my industry that ARM was going to take off in a big way, and exponentially -- "microcontrollers" had grown up, and reasonable compute power could be put everywhere at home, and even carried around with you.

Intel, on the other hand, was seen by everyone I knew, to be more concerned with cannibalization of its low-end x86 market. Stealey and Atom were coming down the pipeline (Silicon Valley secrecy wasn't what it is today), and Intel was looking to make a play in the market. Except, Intel's designs were off the mark by orders of magnitude in power consumption, and could never fill that niche. Still, the word in the street was Intel had bad internal politics at play, and its ARM offerings had to go.

So yes, it's a great shame Intel missed that incredible opportunity at a pivotal moment. But no, it was not an economic decision.

On the non-x86 side, ARM has had this for a VERY long time. Certainly at last since ARMv7-A onward, and I think even before that.

Pretty much any core in "Cortex-A" series (e.g popular Cortex-A8, A15, A57) has support for fast, flush-less address space switching using ASIDs. Address space / context switch overhead has NOT been a good reason to avoid this kind of compartmentalization, for at least the last decade or so.

Nerd bashing, at scale.

Funnily enough, one of the uses of these monster FPGAs is for simulating and prototyping ASIC designs.

This is exactly what I'm saying.

"DMA" as the parent puts it implies a core in the same SoC, rather than external. It would be hair brained to let this have unfiltered access to the fabric. However, that's exactly how older SoCs used to do it - in fact it used to be in charge and the AP shoved behind the IOMMU.

These days nobody I know of is stupid enough to have that arrangement. So it's not really a choice of "DMA" vs USB. External isn't buying much, unless you distrust the fabric filter (IOMMU), which isn't necessarily paranoid... but a level beyond this kind of system decision.

I picked a terrible example which doesn't demonstrate what I intended to.

Any USB link requires the host to maintain some persistent state in data structures mirroring what it thinks the state of the device is. There's no "DMA" in the sense that the device has direct access to the host - but that doesn't preclude something as mundane as a buffer overflow, use-after-free and so on.

"DMA", with appropriate IOMMU, is just fancy shared memory communication. You're just as likely to mess that up as a serial link. It's happened. A lot.

> On the Neo900, the modem is connected via USB (bus; there is no physical connector) which means it doesn't have DMA.

You'll find the modem on most smartphones is connected via USB - or rather its chip-to-chip version, HSIC. For SoCs where it's on-die - on the same bus/fabric - they will (if it's not an idiotic design) use an IOMMU of some sort, to prevent DMA from having access outside of its sandbox.

Even if it's a modem on the other end of USB - which will almost certainly be using DMA, but at least host-programmed DMA - that's no guarantee. Google "Evil USB". USB is a overly complex stack which has and will continue to result in countless vulnerabilities, regardless of what you do with it.

I never stopped caring. It just turns out it never really mattered for a large fraction of cases.

There's still plenty of cases where you absolutely do care: low level firmware, kernels, absolute performance, and high reliability. It's more a case of not worrying about it when there's much bigger risks in a project than having loose guarantees about allocation performance or fragmentation.

The only possible ways you can believe you can write issue-free large scale projects in C, which don't suffer from all the usual pitfalls of C, are:

* You've never deployed one.

* You've never had to maintain one.

* You wrote the last line of code and handed it over to the maintenance team, who then never gave you feedback.

* You have no customers.

* You have done a never-before-seen formal analysis of a large scale project down to the individual source line level, and made no mistakes with the formal specification.

The author is correct: use C only if you must. There are still an enormous number of reasons why you must use C, but it should be a constraint imposed on you, and not a language you actively want to start a project in.

Is this parody?

You've written a list of coding practices which assure job security for folks like me, who have to undo these gross portability problems, bugs, and security vulnerabilities these result in.

  for (int i = 0; i < 100000; ++i)  // most optimal int size used

Is bullshit, always.

I had to explain the same thing to an engineering team the other day. There was a push to switch from a "fast but ok" compression algorithm to a "faster and better" compression algorithm. This seemed like win-win, but I explained that:

* The faster compression made a difference of about 100 milliseconds to a user experience lasting minutes.

* The better compression made a different of about 1 second to most users.

* The change of compression algorithm would take time away from engineering teams, and ultimately introduce bugs.

So in the end it was sidelined until other fundamental changes (file format etc) made it able to be coat-tailed into production.

Same story as yours: don't fix what ain't broke. Tallest working radio antenna in the world -> longest lying broken antenna in the world.

The point is atomicity doesn't work like this on x86, ARM and most architectures. It's the right conclusion from the wrong analysis. The difference in speed will be the time consumed by managing a packed bitmap, not due to the atomicity being any faster.

This sounds wrong to me, too. For the single core case, there's no such thing as an atomic byte store - the underlying mechanism reads a cache line and modifies it. The same goes for a bit operation (possibly needing more instructions).

For the multi-core case, there's always going to be cache line thrashing regardless of size. Cache lines will evict/transfer between cores as each accesses them.

Probably best to go with single bit, unless it can be shown that the overhead of generating a bit mask and the r/m/w is far more expensive.

No, but the software impact of choosing a particular piece of hardware should absolutely be part of the system design process. If it is not, then you are part of a project with bad leadership, or very, very old-fashioned architects.

It's not just ARM - there's plenty of other CPU architectures with modern Clang, GCC, or other toolchains with C++ support. Given that this is a large code base (justifying this amount of work), this cannot be a "tiny" microcontroller, as in 8 bit, and needing to run on microamps. I cannot believe that there were not C++-capable microcontrollers available which would have done the job, without breaking the bank.