
Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe Systems Programming - adamnemecek
https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/#
======
dijit
A lot of 'anti-rust' sentiment here.

Personally, I think the article is somewhat correct. Well vetted and tested C
(or C++) is great, but even the guys who are looking for these things get it
wrong sometimes.

Rust isn't perfect, and I think the negative reaction is people thinking that
evangelists consider it perfect. But I certainly wouldn't call it perfect, and
I'm rather fond of Rust.

That said, I still think it's the "best chance", that doesn't mean it's the
only possible thing to make headway into more safe systems, but it means that
it has the 'best chance'..

Maybe you can make D memory safe, but when I was getting into D development I
couldn't even get a compiler working.

Maybe Ada is your favourite, but I don't know anyone writing Ada and
integrating it with a C codebase.

\--

Frankly it comes down to the fact that Rust was designed specifically for
replacing components of a large C++ codebase that it will be adopted. If you
can write a driver that works with linux that's written in rust and you don't
have as many memory safety issues or concurrency problems (and theres no
overhead) then that's reasonable.

Even if Rust never gets supported by the kernel's buildsystem officially or if
the code can not be upstreamed.

~~~
pcstl
"Anti-rust sentiment"?

I'm a Rust user, a fan of the language, and I believe it's a great step
forward for systems programming.

However, it's kind of ridiculous how on any thread about Rust, anyone who
brings up criticism, no matter how valid, gets downvoted into oblivion. Just
look at what happened to the comments critical of Rust on this post.

The Rust community really needs to take care not to become an echo chamber.

~~~
nilkn
Rust as a language is great and at this point I'd much prefer to use it over C
or C++ any day of the week if the application and context permit. However, I
don't think I'd ever want to participate in the Rust community or really even
have any contact with it. Everything I've seen of Rust's community has been
deeply toxic and hostile to anyone who falls short of worshipping the language
and aggressively promoting and defending it at every chance.

~~~
centimeter
They’re also super weirdly political. As a not-especially-political guy I’m
super turned off by all the “activism” I see coming out of the community, even
where it’s totally irrelevant. I remember seeing a whole thread about how the
rust mascot crab is canonically non-gender-binary or something. Wtf?

~~~
bcrosby95
If discussing the gender of the crab is politics, then surely assuming the
crab is one gender or another is also politics. The idea that you can avoid
politics in anything is a lie told by people whose beliefs conform to
mainstream society. What you're really asking for is everyone to agree with
the mainstream view.

It's kinda like the old military policy of "don't ask don't tell" \- the
policy wasn't actually don't ask don't tell - the actual policy was "pretend
to be straight". Guys didn't get in trouble for talking about their
girlfriend.

Beyond that, as someone that doesn't care about politics, I just skip the
thread. There are dozens I don't care to read about. It's just another one. No
big deal.

~~~
mmm_grayons
If communities want to go down that road, fine, but then they need to get out
of this weird limbo where some views are allowed and some aren't. That means
that someone must be just as free to say, "I believe the rust crab should have
a normal gender because non-gender-binary is not a thing." without getting
banned or cancelled. Right now it's reverted to a very don't-ask-don't-tell-
like environment where one can either speak in support of such things or not
say anything at all, effectively pretending to agree just as in your military
example servicemen had to pretend to be straight.

~~~
unignorant
In my experience many people (unfortunately) generally feel free to disparage
non-gender-binary concepts on internet communities

~~~
mmm_grayons
Maybe in other places on the internet, sure, but I was referring mostly to the
code-of-conduct-gated development communities that pretend not to discuss
politics while allowing specific viewpoints above others.

~~~
XMPPwocky
I can see a difference between light-hearted speculation about an imaginary
crab's gender and saying that non-gender-binary people don't exist. Can you
think of any reason why one of these might be allowed, while the other might
not be?

~~~
mmm_grayons
I guess I can't, because they're both political statements. Politics is either
allowed or not. I assume, however, you have some reason in mind, by how you
phrased the question.

~~~
XMPPwocky
Interesting - well, honestly, not sure how anything _wouldn 't_ be political
if discussing a crab is politics.

Not that that's necessarily wrong - I'm definitely sympathetic to the argument
that the personal is political. But that argument would justify _more_
technical communities taking political stances, not _fewer_.

~~~
mmm_grayons
Discussing a crab is not politics, but attributing to it a non-existent gender
is intentionally contrary to most people's social beliefs (especially outside
of the SV bubble) and is thus political. Calling it a normal boy or girl
isn't.

If, however, some community members wish to do that, they open to others the
option to speak their minds on the topic, including stating that such an
action ought not to be taken because no such gender exists. Contrast this with
how most "codes of conduct" are written: they would permit community members
to speak in favor of such a decision but not against it, as doing so would be
"hateful", "bigoted", or "exclusionary".

------
CoolGuySteve
Systems programming in any language would benefit immensely from better
hardware accelerated bounds checking.

While Intel/AMD have put incredible effort into hyperthreading,
virtualization, predictive loading, etc, page faults have more or less stayed
the same since the NX bit was introduced.

The world would be a lot safer if we had hardware features like cacheline
faults, poison words, bounded MOV instructions, hardware ASLR, and auto-
encrypted cachelines.

Per-process hardware encrypted memory would also mitigate spectre and friends
as reading another process's memory would become meaningless.

~~~
zozbot234
> Systems programming in any language would benefit immensely from better
> hardware accelerated bounds checking. ... The world would be a lot safer if
> we had hardware features like cacheline faults, poison words, bounded MOV
> instructions, hardware ASLR, and auto-encrypted cachelines.

This isn't really true. The main performance cost of these safety checks (and
largely of others such as overflow checking) is inability to optimize because
the compiler needs to preserve partial results/states in case a fault occurs.
The checks themselves are trivial.

~~~
CoolGuySteve
Partial results like, say, a hardware exception firing instead of forcing the
compiler to reason about it?

I want efence on steroids.

~~~
arcticbull
To the maximum extent, bounds checking should be elided via greater compiler
knowledge of what exactly is happening. This would leave arbitrary bounds
checks limited to user input, in which case the vast majority of the
performance penalty goes away right? "Bounds" are a higher-order programming
language concept that I suggest may not have a place in hardware.

~~~
steveklabnik
Compilers already do this. It would still be nice to have cheaper checks;
compilers are not omniscient.

~~~
arcticbull
Yeah, for sure.

I think I was having trouble envisioning what exactly a "cheaper" check could
look like in hardware. Bounds checking is basically read length, subtract your
index, and a conditional branch (potentially with a hint that it would
succeed).

To do this properly in hardware I suppose you'd need a list of memory regions
that are "live" and default the rest to "dead", though how many do you
support? What does updating the list look like? Page tables are pretty slow to
update, and those don't change too often. Array tables would be pretty gnarly,
and impose a further penalty on context switching as they'd have to be thread-
local and app-local.

I wonder if this is a case akin to spinlocks. Sure, I'd love a lock that
doesn't busy-wait, but there's not really a cleaner solution -- in hardware or
otherwise.

Maybe I'm just not seeing something obvious, though!

~~~
saagarjha
You might find an almost-practical (not shipping yet, but should very soon)
example helpful: [https://community.arm.com/developer/ip-
products/processors/b...](https://community.arm.com/developer/ip-
products/processors/b/processors-ip-blog/posts/enhancing-memory-safety)

~~~
arcticbull
That's brilliant, and I retract my statement completely. Thanks for sharing!

------
combatentropy
When people talk about Rust's advantage in safety, is it just the compile-time
checks about Ownership? Could not the C compiler be given the same thing, with
a flag like "strict mode"?

Sorry if my question is really stupid. My experience has been with scripting
languages, not systems programming. But I read the chapter in the Rust Book
about Ownership, and I think I get it. In a sense, is not the compiler simply
inserting function calls to free() in the right places (and warning you if it
can't)? Couldn't this be added to the C compiler? In fact I'm not sure what
the difference is from a linter.

The article has the phrase "C/C++ Can’t Be Fixed", so it anticipates my
question. But its answer is that programmers either won't remember or won't
bother to set their C to "strict mode", run the linter, or whatever, because
"static analysis comes with too much overhead: It needs to be wired into the
build system. . . . If it’s not on by default it won’t it won't help." But if
this is the only argument, it seems weak. I agree that it is more effort, but
isn't it much more effort to switch out your entire language and ecosystem?

~~~
staticassertion
> is it just the compile-time checks about Ownership?

Sometimes. There's a lot more to safety than memory safety, but that's the
easiest to define.

Other aspects might be safety against null values, safety against poor error
handling, etc. Those are much harder to define.

> Could not the C compiler be given the same thing, with a flag like "strict
> mode"?

Not really, no. There's a lot of research into proving C code safe, and
automation of it, and it's not really feasible for general C codebases. There
are tons of static analysis tools that try to get part of the way there, but
they can be slow, miss things, and have many false positives.

It would require, at minimum, some seriously ugly annotations. There are
papers that demonstrate such annotation based approaches with C. One that I
read ended up looking quite a lot like Rust, at which point, you wonder why
you wouldn't just write rust.

Not a stupid question at all, by the way.

> Couldn't this be added to the C compiler?

Rust is able to insert those frees because it has lots of information about
memory usage at compile time. C doesn't, therefor C can't insert those frees
in the general case.

Other issues, cultural ones that is, like "people just disable it" are fair
but not the biggest issue imo. But to further emphasize that point there are
many runtime mitigation techniques (ASLR, stack cookies), and they get
disabled _all the time_ because, and this is the extra sad part, they
legitimately find bugs and crash a program that otherwise may have appeared to
work, and the fastest "fix" is disabling it.

Re: Effort, totally, yes. But the effort isn't really split. There are tons of
people working on safer C/C++ through tools like fuzzing, static analysis, and
runtime mitigations.

~~~
jfkebwjsbx
> you wonder why you wouldn't just write rust

Because it is another language.

If the researchers behind the borrow checker had implemented it on a safe
variation of C/C++, then it would have been much easier to push for it in many
companies. Something like the Python 2/3 split is better than another
completely different language.

Don’t get me wrong, Rust brings improvement in other areas too, which is fine,
but when we are talking about many-million-LOCs, you don’t care that much.

I am still waiting for someone to bring lifetime annotations to C and C++.
Those I could use right away. Rust, not so much.

~~~
tgv
But adding rust-like lifetime annotations to a many-million-LOC code base
would result in totally bricking the code with 99.99999% certainty.

I tried to port an (Earley) parser from C to Rust. It wasn't even a port, but
more of a rewrite with similar function structure. The first part worked well,
even though I had to resort to an arena (a special type of allocator that can
guarantee lifetimes at the expense of freeing them later than strictly
possible). Then I tried to get in shared parse trees. It was a nightmare. It
could simply not be done with the same efficiency as in C. I had to resort to
using array indices instead of pointers, or use ref counting where it wasn't
needed. This had quite some impact on the calling functions.

And that was a few hundred lines of plain, non-tricky C.

~~~
jfkebwjsbx
If your C/C++ is sane, then your code was already written with lifetimes in
mind and enforcing them is not a big deal.

There will be places, no doubt, that you cannot do it, but if you can easily
cover 80% of the code, that is way better than nothing and then you can work
on redesigning the 20% (perhaps even rewriting it in another language since it
has to be changed, for instance to Rust). Same argument as Rust uses for
unsafe blocks.

There have been specialized annotations for things like mutexes for a while in
several projects which help static analyzers prove things too, so it is not
new.

------
jph
Rust is definitely great for systems programming, and the speed is fantastic
too.

Take a look at some of the system utility tools on crates.io, such as ripgrep
(like grep), bat (like cat), fd-find (like find), lolcate-rs (like locate),
procs (like ps).

~~~
CameronNemo
All of those are MBs in size, compared to KBs for their C counterparts.
Something needs to budge in Rust land for small utilities to be viable.

~~~
lawn
That's kind of unfair since operating systems ship with large libraries that C
can dynamically link to, but rust has no such advantage.

~~~
ben0x539
Rust binaries effectively statically link a lot of code via monomorphizing
generics. I may well be wrong but I don't think you could get Rust binaries
down to C sizes just by separating all the dynamically linkable parts.

------
saagarjha
> Rust excels in creating correct programs. Correctness means, roughly, that a
> program is checked by the compiler for unsafe operations, resulting in fewer
> runtime errors.

This is a fairly low bar for correctness, and not really one I would really
agree with :/

~~~
loeg
The bar here is C.

~~~
lukevp
Whenever I think about Rust vs C I think of Curl, where they've been working
on a C program for decades that is used by an incredible amount of software,
and they're still fixing memory leaks in it as recently as November 2019:
[https://curl.haxx.se/changes.html#7_67_0](https://curl.haxx.se/changes.html#7_67_0)

~~~
dagmx
Rust considers memory leaks as safe. However I do find it easier to avoid
memory leaks in Rust due to it’s stronger scope based dropping than when I
write C.

------
tyrion
The fact that Microsoft keeps saying it wants to move away from C/C++ is great
IMHO.

> Microsoft c++ continues to be written and will continue to be written for a
> while

I interpret this as saying that they cannot instantaneously convert all their
existing code to Rust, and it seems fair enough. However, it seems a little
odd to start new projects in C/C++ when you are publicly saying it's the wrong
thing to do.

Infact, just a little over a month ago they announced a new QUIC
implementation written in C/C++ (MsQuic)

Is this to be expected since Microsoft is such a big company? Or maybe that
lib is not important and is not going to be used in, say, Edge?

Moreover, isn't networking code the worst kind of code to write in C/C++ (I am
thinking of heartbleed for example)? I would really love some explanation.

~~~
adolfojp
The more I learn about Microsoft the more this joke makes sense:

[https://en.wikipedia.org/wiki/Manu_Cornet#/media/File:%22Org...](https://en.wikipedia.org/wiki/Manu_Cornet#/media/File:%22Org_charts%22_comic_by_Manu_Cornet.png)

------
VWWHFSfQ
What role (if any) does GCC play in Rust? I understand that Rust relies on
LLVM. If the industry continues to move more and more to Rust then will GCC
begin to lose relevance? Or will the GCC developers add a Rust ~~backend~~
frontend? Has there been any movement toward that anyway?

There are many gaps in my understanding of Rust with regard to LLVM and GCC.

~~~
konschubert
Wouldn’t you need to add a RUST _frontend_?

~~~
VWWHFSfQ
ah right

------
ncrmro
Just starting to get into rust, got a nice a rest boilerplate that uses sqlx
(compile time verification of sql) and some embedded stuff on a pi working
with rust (PWM, Serial)

My questions is where to find jobs with rust. I’m really enjoying it, but my
resume is heavy python/react atm

~~~
mpfundstein
start a business and do your projects in Rust. most clientd just care avout
outcome. thats what I do and i have a lotnof fun trying new stuff with every
new project.

~~~
scandox
Those clients may have trouble taking those projects in house or bringing them
to another 3rd party developer!

As an advisor on these kind of projects I usually advise clients to be very
conservative about the tech used by 3rd party developers or agencies..

~~~
mpfundstein
the strategy of course is to serve them as long as possible ;-)

no seriously. you are right. however that never had been a problem. mostly
weird langauge choices also attract pretty capable developers.

------
rvz
That's if you use 'Safe Rust', then the safety guarantees hold true. However,
the risks increase as soon as you start using unsafe{} or import a crate that
also has unsafe{} code which is why I like using cargo-geiger on my projects
to see the unsafe{} uses in my code and dependencies [0]. Use unsafe{} at your
own risk. [1]

[0] [https://github.com/rust-secure-code/cargo-
geiger](https://github.com/rust-secure-code/cargo-geiger)

[1] [https://arxiv.org/abs/2003.03296](https://arxiv.org/abs/2003.03296)

~~~
adamnemecek
Unsafe is not a problem in my experience. The same way a kernel might have
some part written in asm (for freebsd it's like 1% I believe) your rust code
will have 1% of Unsafe code. Might be more depending on what you are doing.
However the same way few bugs happen in the asm code of a kernel, your unsafe
will not have many bugs.

~~~
saagarjha
Actually, a lot of bugs happen in the assembly part of the kernel. Processors
are hard ;)

~~~
loeg
Do you have a source for that claim?

~~~
saagarjha
A couple examples off the top of my head: all the recent speculative execution
stuff, OpenBSD's buggy SMAP implementation, some recent bugs ARM's PAN.

~~~
loeg
You specifically responded to a claim that there were relatively few assembler
bugs due to it be a relatively small body of code. So in that context, I would
like you to show that the handful you've highlighted is "a lot" against the
backdrop of bugs in non-assembly code.

My semi-informed (but not quantified) opinion is that you are broadly wrong
and that there are not a lot of assembler bugs relative to C/C++ bugs.

------
bob1029
What is the exact aspect of "systems programming" that precludes the use of
higher-level languages which are safe by default? Unless we are writing device
drivers or OS kernels, why are we using these low-level languages for mission-
critical applications?

Even parts of managed languages which are typically frowned upon from a
"systems programming" perspective, such as GC, can be viewed as a positive
when trying to iterate. GC can be treated like a backstop which helps to keep
your application from exploding while you work on memory management, and then
you can incrementally address heap alloc (aka latency) concerns with an
application that actually runs (for a little while at least). Trying to
iterate on memory pressure and related concerns with a C/C++ application is
nothing short of nightmare fuel from my perspective, but I spend most of my
time in higher-level languages these days.

I think it is also very hard to make a performance argument in 2020.
Especially when you are comparing low level against something like the newest
C#/.NET Core stack. Just take a look at the most recent TechEmpower plaintext
benchmark (round 19). How many new business "systems" are being "programmed"
that aren't ultimately just web servers passing HTML/JSON around, executing
business logic, and reading/writing bits of data to some database?

~~~
estebarb
I work in embedded software for network switches and almost everything is
written in C. And most of the code is pretty new.

C++ fired back because integration was ugly (the SDKs are designed for C
usage) and a lot of C developers that doesn't understand C++ well.

Go is used a bit, but again, training people for using it correctly is hard.
And using the C SDK from Go is an obvious NO.

A lot there think that Rust would be in a similar situation that C++. Nice to
have, but too much low level dependencies (hardware SDK) and high level
(developers proficient in the language) to expect it to happen. Also, calling
the SDK would convert everything I'm unsafe, so we are like in C, but with a
language that nobody understands.

So, there are technical reasons, but also human resources and economic ones.

~~~
elcritch
Ultimately I think the switch would pay off for most companies in the medium
to long term. There are valid reason C is still the primary embedded
development language but many are going away. One is that Rust only uses
clang/llvm which doesn't support many targets. Still there are so many low
level data races and challenges with embedded development that having a Rust
environment would be a huge improvement, IMHO. The C / FreeRTOS project I’ve
been using lately has random data races in the LwIP library which reset the
device. It’s almost impossible for me to debug so I workaround by adding some
delays here and there. C++ wouldn’t help resolve data races so it's just an
extra cost. Also C++ exceptions on embedded are tricky, so the Rust error
handling has closer semantics to C error handling.

A complete Rust system would likely help solve most of these issues and
drastically reduce these bugs, increasing development speed. Unfortunately the
lack of native SDK in Rust is annoying, but some groups are making progress on
STM and no-lib Rust. It’d be great if STM makers adopted their sdk and made an
official one!

Currently since Rust doesn’t support my chip, I’m using Nim to generate C. It
doesn’t solve all the data races noted above but having generics and easy data
structures like tables and vectors is fantastic and I'm not second guessing
the code all the time. A deterministic GC covers my memory usages fine.

------
exdsq
I heard the Rust API changes between versions such that it’s a bit of a pain
upgrading systems. Is this true?

Also, I’ve read traits can be used as invariants for a pseudo-dependent type
system. Has anyone had experience with this?

I’m considering learning it instead of C++ for some systems work.

~~~
jfkebwjsbx
If your systems work do not require stable compilers or rely too much on
external C++ APIs, then you will be mostly fine.

~~~
exdsq
It’s mostly to trace process performance, network load, stuff like that.

------
Rochus
There is no reason to assume it is the "Best Chance". There are a lot of other
chances too, some even since more than two decades (e.g. Ada/Spark). Even C++
itself has not yet shot all the powder. And just as one can write secure code
in C++, it will turn out in time that even with Rust not everything is as
secure as propaganda would have you believe.

I would be interested to know if this is really the official opinion of
Microsoft, or if someone just wants to make a name for himself.

~~~
jeffdavis
Having a minimal runtime is, I believe, a requirement to make any serious
headway into a lot C/C++ use cases. The places where minimal runtime is not
important have already seen big shifts to garbage-collected languages ~20
years ago.

You mentioned Ada, which does have a minimal runtime. It might be interesting
if the community and ecosystem made a strong push into general-purpose
programming, like rust has. I would give it another try.

Rust seems to handle heap allocations more fluidly (or at least closer to what
I expect), but perhaps that wouldn't be a deal-breaker if I knew more about
progamming in Ada. Rust also has better C integration -- it can match C
structure layouts and operate on them seamlessly with rust semantics. But
basically, it seems plausible that Ada could work with the right ecosystem
around it.

Regardless, Ada has had decades to make the leap into general-purpose
programming, and it hasn't done so yet. Rust is viable today for a lot of
important use cases, and is not far off for a lot of others.

~~~
Rochus
I think the fact that Rust is very popular in the polls, but still hardly ever
used, rather indicates that people primarily want to escape from their current
dissatisfaction, but then ultimately don't take it seriously with switching to
another technology, so as with Ada or others already available. Besides, C++
is also evolving, and formal verification has been possible for many years.
There are also proven ways to avoid memory problems. Rust would have to prove
itself first. Maybe it solves one problem better, but ten others worse.

~~~
feanaro
"Hardly ever used" sounds like it might be the result of your personal filter
bubble?

~~~
Rochus
see
[https://insights.stackoverflow.com/survey/2019](https://insights.stackoverflow.com/survey/2019)

Only a small fraction of "Rust fans" are actually using it.

~~~
albntomat0
I wonder what percentage of folks (not exclusive to Rust lovers) are stuck
with a language at work or in major side projects because of momentum,
existing code bases/etc.

------
GnarfGnarf
Is Rust a good choice for applications programming? Does it support GUI
(dialogs, etc).

~~~
RMPR
[https://areweguiyet.com/](https://areweguiyet.com/)

[https://runrust.miraheze.org/wiki/GUI_Creation](https://runrust.miraheze.org/wiki/GUI_Creation)

------
pull_my_finger
If they want to use Rust, and have more faith in it than their own Verona[1],
then they should discontinue Verona dev and let those developers go back to
Pony[2]. I imagine having their core team working on Verona full-time is
considerably delaying Pony development.

[1] -
[https://github.com/microsoft/verona](https://github.com/microsoft/verona)

[2] - [https://github.com/ponylang/ponyc](https://github.com/ponylang/ponyc)

(edit: formatting)

------
rbanffy
I would go as far as saying it's Microsoft's best chance at safe systems
programming, but no further.

I love Rust, but I'd refrain from such sweeping statements until other options
evolve and get the opportunity to be time tested.

------
boromi
Has anyone worked on rust for microcontrollers? STM32 and Arduiono ?

~~~
Rust4w4y
Easy peasy:

[https://rust-embedded.github.io/book/](https://rust-embedded.github.io/book/)

[https://docs.rust-embedded.org/discovery/](https://docs.rust-
embedded.org/discovery/)

------
moonchild
Surprised this is coming from the company that helped build f*
([https://fstar-lang.org/](https://fstar-lang.org/))

~~~
phkahler
The second danger to Rust would be MS pulling Embrace, Extend, Extinguish with
it. Dont think so? What are they on now, DX12? Still trying to own the
graphics API.

------
vinay_ys
I think 'best chance' at safe programming is the advances in chip design. I
expect PMMU to become more sophisticated and solve more of the memory safety
problems in hardware than in software. Then, the programming model will evolve
and safety features will become more language agnostic and broadly available.
Then, I fully expect compiler+runtime+os to evolve to take advantage of these
hardware features for software written in any language.

------
fuddle
I'm a big fan of Rust, they only issue I have is that the compile time is
painfully slow. Hopefully it can be improved in the future.

------
kbenson
_A lot of tooling is built around C /C++. In particular, Microsoft binaries
are now almost completely built on the Microsoft Visual C++ compiler which
produces MSVC binaries, whereas Rust relies on LLVM._

Maybe providing/funding a different back-end would be a worthwhile endeavor
for Microsoft to do or fund.

------
winrid
Great. Now rewrite all the slow C# apps in Windows. :)

------
carapace
Does anyone have a link to a good Rust vs. D comparison?

------
fortran77
I'm disappointed they didn't double-down on what I feel is the best general
purpose programming language C# (and related F#).

It has a great toolset, generates good code, and with a good microkernel
architecture (which Windows 10 is, mostly) 90% of "systems" programming would
be fine in a garbage-collected language.

------
lloydatkinson
It's a shame its such an ugly language then

------
choeger
If only it had dynamic linking...

I know, I know, efficient, separate compilation and parametric polymorphism
are hard to get together, but a systems language should not follow the same
compilation model as, e.g., Haskell.

~~~
zozbot234
You can use dynamic linking, it's just restricted to the C ABI. But this has
its benefits in that if your dylibs are written properly, they'll be usable
from C and C-compatible languages as well. "Wrapping" code can be statically
linked and provide higher-level features.

------
jfkebwjsbx
When is Microsoft going to release first-class Rust support in Visual Studio
and Windows, including debugger and official Rust bindings for their most
commonly used APIs like Win32, Direct3D, etc.?

~~~
s_y_n_t_a_x
I don't think this is exactly what you want, but you might be interested in
it:

[https://github.com/microsoft/winrt-rs](https://github.com/microsoft/winrt-rs)

~~~
jfkebwjsbx
Not really, but thanks! Hopefully they will start adding more bindings...

------
fourcommas
You shouldn't trust someone who misleads with: "Now, 70% of the CVEs
originating at Microsoft are memory safety issues, Levick said. “There is no
real trend it’s just staying the exact same,” he said. “Despite massive
efforts on our part to fix this issue it still seems to be a common thing.”"

There is a trend, and the trend has been a MASSIVE reduction in memory errors.
The percentage of security issues that are memory errors says nothing of the
totals, which is what matters.

Microsoft could go through 2021 with only one CVE and we'd see articles like
this saying "100% of security vulnerabilities are caused by memory errors, we
must switch to Rust!"

~~~
dtolnay
Here is the data from Microsoft Security Response Center on this [1]. Slide 5
shows double as many CVEs as 4-5 years prior, triple as many as 6-8 years
prior. Further, slide 10 shows 70% of CVEs are memory safety and that ratio
has been constant since 2006. It follows that the absolute number of CVEs
which are memory safety is double 4-5 years prior and triple 6-8 years prior,
which is inconsistent with a massive reduction.

The magnitudes here are in the many hundreds of CVEs per year from Microsoft
(and growing), not "one CVE in 2021". 70% there is not a negligible number.

[1] [https://github.com/microsoft/MSRC-Security-
Research/blob/mas...](https://github.com/microsoft/MSRC-Security-
Research/blob/master/presentations/2019_02_BlueHatIL/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf)

~~~
fourcommas
Now divide the number of CVEs in each year by the LoC maintained. You're again
looking at completely the wrong number. Line-for-line, C/C++ written today at
MSFT/Goog has less memory errors than 10 years ago, and even less exploitation
of memory errors. Anyone who lived through the rise and fall of Internet
Explorer intuitively knows this.

~~~
dtolnay
Dividing by the LoC is a mistaken way of looking at this data. Regardless of
the amount of code in a browser or in Windows, an attacker may only need ONE
exploitable bug to cause mischief. If the amount of code in Windows grows by a
factor X from year to year, the CVEs per LoC better be shrinking by at least
factor X (this is where Rust comes in) or else the system is getting less
secure. Thus the absolute number is the relevant metric, and indeed is the
number reported by Microsoft Security Response Center.

~~~
fourcommas
> the CVEs per LoC better be shrinking by at least factor X (this is where
> Rust comes in) or else the system is getting less secure

Do you really think windows 95 was more secure than win 10? Or that IE6 was
more secure than the latest IE? The newer versions are way more secure, it's
not even close. Your data is giving you incorrect conclusions, because you're
combining and cutting the data in ways that don't make sense.

------
pizlonator
PL is still a fast moving field, so claims that any language is a “best
chance” for something are likely to have a short shelf life.

------
childintime
It's sort of ironic that today I tried to install Rust through rustup-
init.exe, on Windows, and it didn't work because of its dependency on
Microsoft Visual C++ Build Tools 2019. Rustup keeps saying "Install the C++
build tools before proceeding", though it did install from the rustup provided
link.

Developer installs continue heavily invested in dangling pointers (called
paths) and other unsafe practices, C/C++ style. I find that baffling.

~~~
steveklabnik
The context here is that this is the only way to get link.exe; if there were
any easier way to do it, we would!

~~~
jfkebwjsbx
Why do you need link.exe? Why don’t you use LLVM’s linker?

~~~
steveklabnik
It’s sort of definitional, the MSVC target uses the MSVC linker by default.
Some platforms, like wasm, do use lld by default, and you can override the
linker if you choose.

MSVC is the default because it’s the platform default, just as the Linux
targets default to glibc rather than MUSL, for example.

~~~
jfkebwjsbx
One can argue that using the default linker is a good choice, and that is a
good argument, but I don’t see how that is definitional.

Btw, wasn’t Chrome and others switching soon to LLD?

~~~
steveklabnik
I mean “The MSVC target uses the MSVC linker so that’s why you need the MSCV
linker.”

Yes, they are. Not sure how that’s relevant, though.

------
userbinator
Best chance at creating an even more dystopian future where authoritarian
governments and corporations control exactly what "your" computing devices can
do and you can't "jailbreak" out of?

Yes, I know Rust is not a panacea, but I feel like the whole paranoia around
safety/security is just leading us towards that sort of society, technology
included. It seems that there was somewhat of a balance before, which allowed
for some sort of "civil disobedience" (jailbreaking, rooting, cracking, etc.),
and now that freedom is slowly disappearing.

~~~
signal11
This is the strangest critique of writing more secure code I've seen.

Yes, more secure code does reduce the chance of jailbreaks, but insecure code
is overwhelmingly used more by criminals and state actors to try and break
into your computer.

Secure Code helps all computer users, the 'little guy' most of all.

And you can always vote with your wallet (or, you know, _vote_ ) to keep your
digital liberties. Blaming a better tool for eroding your liberties seems ...
strange.

~~~
missosoup
State actors and high tier criminal orgs will always have a way into your
digital life.

In a way, making code more secure is just creating an asymmetry where regular
joe can't break into a device but only state actors and other major players
can.

I can sort of understand GP's sentiment. If someone really wants to hack me,
they will. Or they'll find some other vector. The prevalence of memory safe
code doesn't really impact my own security as an individual. But it does
impact my ability to jailbreak and own my devices.

There was a similar discussion around the intel Trusted Computing concept. It
was not a platform that ultimately benefited the user, it was a platform for
user-hostile forces to 'trust' that the user isn't interfering with the code
they want to execute on the user's device.

Slowly but surely we're moving towards a world where user devices are merely
thin clients over corporate and government owned systems, and don't really
belong to the user at all.

------
hansdieter1337
My first thought: oh no. M$ likes Rust and will probably contribute and
demolish it. Just look at the Github system status history since M$ took over.
Or Azure, Windows 10, ...

------
stephc_int13
This is magical thinking, switching language won't solve the problem.

Complexity is the problem, hard-to-read code is the problem, over-engineering
is the problem.

~~~
muldvarp
> This is magical thinking, switching language won't solve the problem.

It won't solve the problem, but it can be an important step towards a
solution.

> Complexity is the problem, hard-to-read code is the problem, over-
> engineering is the problem.

I actually disagree. Many memory safety issues are not the result of hard-to-
read or over-engineered code, but are instead due to careless memory
management. Safe Rust code (no matter how hard-to-read or over-engineered) can
guarantee memory safety.

~~~
stephc_int13
If it was that easy to fix, this problem would have been fixed a long time
ago, by many other "safe" languages.

My bet is that Rust won't help nearly as much as people tend to think.

~~~
muldvarp
> If it was that easy to fix, this problem would have been fixed a long time
> ago, by many other "safe" languages.

There are many other memory safe languages. Those usually have a GC though.

> My bet is that Rust won't help nearly as much as people tend to think.

Why not? Memory safety issues are common and safe Rust code eliminates them.

------
crazypython
I don't see why people take "Rust has affine types" and "affine types help us
have safe systems programming" and then think "Rust is the only safe systems
programming language."

~~~
fluffything
Because people like you, who suggest that there are alternatives, fail to
mention them.

Which other languages close to C, without a run-time, and without a garbage
collector, give you proven memory and thread safety?

Not C, not C++, not D, not Nim, not Go, not Swift, not Ada, ...

~~~
jfkebwjsbx
C and Ada variations have done so for _many_ years, way before Rust was a
thing.

Ada and D are also in the process of adding memory safety to the base language
too.

The actual question is why nobody cared that much until now to put it in
mainstream languages. The answer is, as you know, browsers.

~~~
AnimalMuppet
What C variations have given safe system programming for many years? I'm not
sure I know of any.

~~~
pnako
MISRA C is a subset of C / set of rules that is used in the auto industry, and
supported by many tools.

~~~
joshuamorton
> Rule 20.4 (required): Dynamic heap memory allocation shall not be used

So anyway, what subset of C allows the use of dynamic heap memory allocation
and enforces safety?

