Ask HN: Will Rust ever become a mainstream systems programming language? - justinucd
======
ekidd
I work for Faraday (.io, not the car folks), and we use Rust in production. I
personally suspect that Rust will continue to grow in popularity.

We've been really happy with Rust. Our Rust programs tend to be fast and
resource efficient, and they tend to have few bugs (and most of those are
cases of misunderstanding the problem or the spec).

The learning curve tends to be pretty rough for the first week or two, but you
can reduce that by pairing with a more experienced Rust developer. And after
that, it's pretty smooth sailing. Certainly any C++ programmer should be able
to make the leap fairly quickly--it helps to have used at least one non-GCed
language.

The third party library situation is better than you might think for a young
language (the database clients, RabbitMQ clients, HTTP clients, compression,
etc., are all basically usable), but I normally expect to fill one or two
library gaps per project.

Overall, I find it difficult to articulate why I like Rust. It's pleasant to
write (now that I know how), it runs fast, the CLI tools are pretty solid, and
has enough abstractions to keep the boilerplate in check. And I can throw
cluster-sized workloads at it and trust it to work, and work fast.

~~~
dochtman
Trying to articulate why I like it: it marries the low-level control and type
safety from C++ to modern language features as found in Python/Ruby etc, and
in doing so manages to hit a pretty sweet spot in terms of having the compiler
finding actual bugs early. With enums and pattern matching and the borrow
checker, there are a bunch of features that help make the type system
expressive enough that you can generally express what you need and still allow
the compiler to perform very thorough, important checking on it, with the
effect that "it compiles -> it works" is true much more than for, for example,
C++.

~~~
46Bit
I agree and would add one more property that makes Rust likable - it's about
two years old, so still a greenfield language and standard library. It's easy
to overlook that.

------
soulbadguy
Whatever the answer is, you probably will not find it here. From an historical
perspective, the success a language seems to have very little correlation with
the vague notions of quality that we language geeks think are important. And
it seems that the HN echo chamber forgets that.

------
scythe
Rust has to stand the _true_ test of time -- the test where 5-10 years-old
codebases written in Rust are still being maintained. Someone who's literate
in programming language _theory_ can evaluate the design decisions in Rust and
say "it looks good" (or not), but in order to determine whether Rust is
actually good for building and maintaining large, complex software systems for
long periods of time, there's no metric like really doing it.

I think at some point, Rust will have enough tooling that people will try to
start using it for graphics and videogames -- the applications where C and C++
shine but their "safer" rivals Fortran and Ada can be a headache to work with.
It's in this arena -- where Go is too slow -- that Rust will really sink or
swim. And it has barely even started to make headway. Maybe GNOME 5 will be
written in Rust, or maybe the GNOME 5 developers will try Rust and conclude
it's not suitable. Whoever they are, they haven't even started yet.

~~~
eridius
> _I think at some point, Rust will have enough tooling that people will try
> to start using it for graphics and videogames_

The game developer community is actually one of the communities that jumped
onto Rust really early, well before it hit 1.0.

~~~
lossolo
You mean hobbyist ? All the AAA games are still written in C++, none of the
big studios is even considering to switch. Rust type system/restrictions would
get into the way more than it would help in AAA game dev. Memory safety is not
a problem in game development, they will just patch the bugs. Studios have
whole ecosystems written in C++ that works for them. Benefits are really low
compared to costs, that's why it's unlikely any major studio will switch any
time soon.

~~~
mmstick
Type restrictions aren't really a problem, but in fact really helps out game
development in the long run.

> Memory safety is not a problem in game development, they will just patch the
> bugs.

You must not have played any Bethesda titles. That said, there is much more to
Rust than memory safety. That's just a side effect of the safe parallelism --
it's a minor story.

~~~
Rusky
This is nonsense. I would love to use Rust in games (I currently work in
games) but it's not clear that it would work out. That opinion is shared by
game developers far more experienced and prominent than myself.

I (and I presume many others) would appreciate it if you would stop making
grand, unfounded assertions about what Rust is good for. Games _do_ make very
different tradeoffs from most software- type and memory safety aren't an
obvious, uncontested win there.

~~~
mmstick
There's already a few games written in Rust on Steam's Greenlight program.
SHAR was even greenlit. Stating that it isn't clear that it would work out is
basically stating that you are choosing to ignore that it has and is being
done successfully.

> stop making grand, unfounded assertions about what Rust is good for

You are basically stating that everything that I have done in Rust is a lie. I
will not stand for that.

~~~
Rusky
There are vast gulfs between Steam Greenlight candidates and AAA.

Nobody here, least of all me, has claimed that Rust cannot be used for any
game at all, nor have they disputed your own experiences. Grow up.

~~~
mmstick
You clearly don't read what you write.

> I would love to use Rust in games (I currently work in games) but it's not
> clear that it would work out.

There are many contradictions in your posts on here.

------
Animats
I had great hopes for Rust as the future of systems programming, but they've
decreased over time. Parts of the language are just too cute.

The borrow checker was brilliant. Any future language that doesn't use garbage
collection will have to have one. That was the big advance in Rust.

But the object system (yeah, they're called structures and traits) is too
weird. The enum approach to variant records is too weird. The error handling
is too weird. The half-functional style is too weird. The widespread use of
closures for simple stuff is too weird. There's too much unnecessary
originality. Trying to port something from another language to Rust is
difficult because Rust's ways of doing things are so different from other
languages.

I have the feeling that Rust is destined for a niche like Haskell - cool, but
not mainstream. That's sad. I really thought early on that Rust meant the end
of the decades of hell from the lack of memory safety in C and C++. But that's
not happening.

The Go crowd knew when to stop. The Rust crowd didn't.

~~~
pcwalton
> But the object system (yeah, they're called structures and traits) is too
> weird.

So you praise Go for having structures and interfaces, but you criticize Rust
for having structures and interfaces because that's "too weird".

> The enum approach to variant records is too weird.

Why? Because of the keyword? Swift uses that keyword too!

> The error handling is too weird.

What would you rather see?

> The half-functional style is too weird.

I can't think of any way that Rust differs in this regard from, say, Ruby. Or
JavaScript.

> The widespread use of closures for simple stuff is too weird.

Again, it doesn't differ from Ruby. (Actually, Rust uses closures/blocks quite
a bit less than Ruby does, because of the pull-style iterators...)

> There's too much unnecessary originality.

Such as? None of the features you've mentioned are at all original.

~~~
soulbadguy
>> The error handling is too weird.

>What would you rather see? Exceptions

~~~
pcwalton
We would lose lots of users from C and C++ if we mandated exceptions for error
handling. The code size and complexity of unwinding is too much of a price for
many to pay.

~~~
soulbadguy
Not mandate them , use have them as an options where the monadic Errors types
are not enough or are too cumbersome to use.

~~~
pcwalton
And thereby prevent people from writing code that needs to catch errors but
can't use exceptions. Won't work.

~~~
soulbadguy
I don't understand what that sentence means...

~~~
thristian
Some people don't want to use exceptions because of runtime overhead costs.

If exceptions are just "an option" that a library can choose when designing
its interface, then you'll get a split ecosystem: a bunch of libraries that
_do_ use exceptions for error-handling, and then a separate bunch of libraries
that do the same thing, but _don 't_ use exceptions for error handling, which
is wasted, redundant effort.

~~~
btschaegg
> then you'll get a split ecosystem

Agreed. Point in case: Have a look at D and the discussions about their GC.

I haven't kept up much about the last year, but my general impression runs
down to: If you want to use their standard library. There's gonna be garbage
collection. Period. If you want to avoid it, enjoy implementing its
functionality all by yourself.

With rust and exceptions you would likely not have a problem with the main
ecosystem, but the same problem is bound to pop up with _some_ big & famous
library.

Edit: Similarly, exceptions are one of the reasons C++'s SG14 exists.

------
tmccrmck
The Rust ecosystem has lost sight of the forest for the trees in my opinion. I
highly agree with Graydon's opinion in "Rust is mostly safety" [1] that it's
raison d'être is memory safety and concurrency in the systems space. But
strangely a significant amount of time is being put in to making it usable for
other tasks. I think this has to do with the different cultures between C/C++
developers versus other developers, namely that developers coming from web
development are younger and more used to jumping around to new languages and
frameworks.

With it's borrowing semantics and steep learning curve, Rust will never gain
significant market share in the world of web development. And why should it?
Time to market matters more than speed. It's much easier to ramp up new hires
on a C# or Go code base than on a Rust one. And the borrow checker will always
create friction for people new to the language. As someone with a C++
background, it still took me over a month before I stopped fighting with the
borrow checker and with lifetimes. I can't imagine how long it would take to
get a completely new programmer up to speed.

[1]
[http://graydon2.dreamwidth.org/247406.html](http://graydon2.dreamwidth.org/247406.html)

~~~
mmstick
Web developers have zero issues with using Rust for web development though.
The Rocket web framework is rather intuitive. I even built my website entirely
in Rust with it.

[http://mmstick.tk](http://mmstick.tk)

~~~
burntsushi
"zero issues" is a bridge too far. Rocket, for example, only works on nightly
Rust, and that might be a non-starter for a lot of people.

~~~
flukus
This has been my biggest issue trying to learn rust, there are too many
projects that only support the bleeding edge.

~~~
burntsushi
Rocket is one big one. Just recently though, serde and diesel started working
well on stable Rust. Other than that, unless you're doing embedded stuff or
SIMD, you should be fine on stable.

Unfortunately, Rocket does not appear to be on track to work on stable Rust
for the foreseeable future.

~~~
flukus
I was hoping with serde being on stable things would settle down. What's
keeping rocket on nightlies?

~~~
steveklabnik
Lots of things:
[https://github.com/SergioBenitez/Rocket/issues/19](https://github.com/SergioBenitez/Rocket/issues/19)

------
topspin
I want to believe. I love Rust. I feel like Rust is the language I've waited
for all my life.

Yesterday there was a story about Rust here on HN: "Programming ARM Cortex-M
Microcontrollers with Rust." Among the replies was a complaint; someone
couldn't figure out how to write a static buffer and was discouraged. Someone
else provided an example of how to do this. Finally, another person noted how
unfortunate the solution was. Here is the code, reworked by me just a little:

    
    
        use std::io::Write;
        use std::str::from_utf8_unchecked;
    
        static mut S1: [u8; 17] = [0; 17];
    
        fn main() {
            unsafe {
                write!(&mut S1[..], "Hi: {}", 5).unwrap();
                println!("string: {}", from_utf8_unchecked(&S1[..5]));
            }
        }
    

There are three distinct reasons why everything has to be "unsafe." Unless you
have a lot of experience with Rust you are NOT going to figure that out until
you've banged your head against the compiler for some time doing your level
best to minimize the lines of code you've wrapped in unsafe, and then finally
surrender.

That is a lot of friction. I know (as in I understand with precision) the
reasons for this and they're entirely legitimate. But damn... the pain is just
more than the bulk of the world is ever going to tolerate. You can do the same
task with zero friction in C/C++ and go fast/be small, or you can do it with a
"managed" language with zero friction and handwave at the bloat and cycle
eating cache killing GC, or you can don the hair shirt, focus on your
breathing to keep the panic at bay and use Rust.

It is inescapable human nature that the "mainstream" will avoid the latter.

~~~
ethbro
I think you noted one of the problems Rust is going to have with adoption: its
raison d'être is solving technical debt (specifically, security debt).

Unfortunately, the reason that's a problem is because most management doesn't
even know what it means. And that's not likely to change.

So saying "We have a language that might take a bit longer but solves X" is a
difficult conversation when the reply is "Wait, what is X?"

------
throwaway7645
It does keep rising in popularity, but is that coming from folks actually
using system languages like C, C++, Ada, and Forth? I'm guessing only a
portion. There's a difference between a web developer using Rust
enthusiastically for hobby projects and a seasoned C coder switching to Rust
for a professional job. In fact, a lot of the projects I've seen in Rust (ex:
Dropbox) are commonly being done in Go as long as the GC isn't an issue.

~~~
xiphias
Rust is the first language since C++ that can improve/not hinder runtime speed
while making development safer, so I definately see its future.

The only problem is that the compiler is very slow now, so it doesn't scale to
large code bases, which is a no-go in my company. Hopefully the Rust team
understands that this is not only a would-be-nice to have feature (I see
learning the borrow checker as a smaller problem)

~~~
biokoda
> The only problem is that the compiler is very slow now, so it doesn't scale
> to large code bases

The way of working with that is use cargo check command which is much faster
and splitting your problem into multiple crates so you don't have everything
in one giant project. Which is what tends to happen in large code bases
anyway.

Also they are putting quite a lot of work into making it faster. Before you
get to that large code base it will be better.

~~~
xiphias
While your suggestions work at some companies, it's not a good solution for
every company:

[https://www.wired.com/2015/09/google-2-billion-lines-
codeand...](https://www.wired.com/2015/09/google-2-billion-lines-codeand-one-
place/)

~~~
biokoda
A single repo can have lots of crates

------
asitdhal
Most C++ developers won't easily develop systems in Rust because of lack of
well-known libraries and a stable ecosystem(profilers, static analyzers,
concurrency tools, many skilled and mediocre developers, etc). C++11 and
subsequent versions have a good amount of memory safety(though not as safe as
Rust).

Rust is a modern language with very good concepts and features. It's quite
complicated to learn.

My answer is it will be a good language, but won't be a top language.

~~~
Nomentatus
Like... Cobol... 'cause all those reasons are vanishing and will vanish.

~~~
asitdhal
Those who need Cobol use them(Core banking applications).

Rust is better than C++, but it's not extremely better than C++.

~~~
Nomentatus
Extremely safer seems to me to be extremely better, these days.

------
jackpot51
System76 is using Rust now for automated testing and firmware flashing. I
wrote these projects in rust, and I enjoy using it, can't say much about the
other engineers.

~~~
AsyncAwait
Also, Redox OS is awesome :-)

~~~
jackpot51
Thanks ;-)

------
Corrado
My feeling is that Rust (and/or Go) will probably supplant Java (and/or C#) in
the coming age, just on the basis of the user experience alone. This past week
I wasted several hours trying, and failing, to get a simple Java app up and
running. Rust (and Go) have such a better end user experience that I can't see
them not winning. Firing up a single executable is miles better than
installing a run time, then tweaking the config to make it work, then trying
to find out where it stores log files, then tweaking it again when it fills up
memory, etc.

Give me a single, self contained, executable any day!

------
camgunz
I think it's important to consider the implications if Rust _doesn 't_ become
a mainstream programming language.

I'm not shy about my dislike of Rust. I like C, I don't think avoiding buffer
overflows and memory errors is that hard, and I chafe at the idea of a
language I dislike aesthetically taking over systems programming.

But even I have to admit the arguments for using C instead of Rust are niche.
Sure there's probably always going to be some instance where C makes sense
technically, but if we could wave a wand and convert the world's C/C++ code to
Rust, we'd immediately fix millions of memory errors and data races. It's
impossible to overstate that benefit.

Think of the things the Rust team has to deal with:

"Is Rust a good web language?"

Is C or C++? Is Ocaml?

"Is Rust a good language for an OS?"

Is Python? Is JavaScript?

"Is Rust too big?"

Is C# or Java? Rust is a pretty small language, both in terms of features and
implementation size.

"Is Rust powerful enough?"

Is Go? Go deals with this all the time ("Go ignores decades of PL research").
Rust's feature set is pretty good, but more importantly it's well thought out.

"Is Rust fast enough?"

Is Java? Is C#? Is Go?

"Does Rust compile fast enough?"

Does C++? Does Clojure?

"Will your Rust program be memory safe and free of data races?"

It sure will be. This is a monumental achievement. Your options for a memory-
safe language without GC are... Rust and Ada?

"Does Rust have a good concurrency/parallelism story?"

Rust has one of the best, actually. It doesn't use segmented stacks so it
doesn't achieve the M:N performance of Go, but it has memory and data race
safety, OS threads, and futures, so no problem.

"Is Rust too hard?"

Honestly, programming is hard, other languages just let you ignore it. There's
an example about manipulating a string as a global array in this thread
somewhere, which is not really something you should do, and the argument was
"this was wildly difficult". It is, yeah, because safely managing concurrent
access to a global, bounded section of memory is wildly difficult.

Again, I'm not a Rust fan and I sort of can't believe I'm writing this. But
look at what Rust has:

\- memory and data race safety

\- scripting language ergonomics (after you internalize the borrow checker)

\- the speed and memory usage of C

\- a low surface area

\- advanced features

\- great community outreach and documentation

\- familiar structure (as opposed to something like Erlang or Haskell)

If a language like that doesn't succeed, you have to start wondering what
will.

My personal belief is that it is succeeding, but I think success looks a lot
different than most expect: new projects that need a systems language are far
more likely to be written in Rust than in C/C++.

~~~
kixunil
> It doesn't use segmented stacks so it doesn't achieve the M:N performance of
> Go

Actually, if you use Tokio or similar approach, you achieve better performance
than Go (no need to re-allocate stacks) while code is still quite readable and
boilerplate-free.

~~~
Rusky
They seem to be aware: ", but it has memory and data race safety, OS threads,
and futures, so no problem."

However, futures are certainly not boilerplate-free. They destroy your ability
to use native control flow the way you can with threads (M:N or 1:1). You can
get some of that back with async/await, but Rust doesn't have that and it's
still not boilerplate-free.

------
logn
If "functions as a service" (AWS Lambda) takes hold, I think Rust will be a
popular server language since you'll need services with almost no
startup/warmup time.

------
Cshelton
I would say so far, yes. I would say it's pretty "mainstream" already with
many companies using it in production, including Mozilla.

As big as C++/C? Too early to tell for that.

~~~
hutzlibu
Also anyone big besides mozilla, who created it?

~~~
burntsushi
Microsoft in VS Code: [https://code.visualstudio.com/updates/v1_11#_text-
search-imp...](https://code.visualstudio.com/updates/v1_11#_text-search-
improvements)

/plug :-)

~~~
flukus
I don't think that counts. I'm not using c when I run grep.

~~~
burntsushi
They are shipping ripgrep with VS code.

~~~
flukus
But shipping a program using rust != using rust. If that was the case I've
used Erlang despite never having written a single line of it because I've
shipped rabbitmq.

~~~
burntsushi
This is a strange argument I find myself in. What do you expect me to say?
They're shipping a Rust application I wrote. That's a fact. Do with it what
you will.

~~~
lossolo
No, it's not strange. What you wrote can be interpreted as manipulation. It's
the same as replying to question "Who uses Go besides Google?" And you would
reply that almost everyone use it, because everyone is shipping their apps
with Docker. You see manipulation here? I don't know if intentionally or not
but you did exactly the same.

~~~
dbaupp
FWIW, a common argument in favour of C and C++ is how it is used by pretty
much everything that one runs on a computer, in exactly the same sense of
"use". I think you're tilting at windmills: some people mean "use" to mean
"ship" and others "write", and neither are that unreasonable.

~~~
lossolo
I wasn't the first one that made that claim. And I don't know the author of
the comment that made it and I am not involved with anything that author do -
something you can't say yourself in context of person you are defending. I've
asked couple of people about that question without suggesting the answer and
all of them agree with interpretation that it's about writing software in
language A, not using third party tools written in language A.

Example of usage outside of company like in question from arstechnica:

"Outside of Google, companies like Wrike, Workiva, Blossom and others have
also been using Dart to develop their products, so there is definitely still a
Dart user community outside of Google, too."

This is how everyone interpret that question.

------
yitchelle
Not too sure what is meant by "mainstream" but I can see Rust getting a
foothold in certain industry, such as medical, automotive or aerospace. To get
there, it will need to be mature and be stable significant enough. It will
also need a big player to take that first step and prove it in production.

Imagine if Ford mandates its suppliers to use Rust for the software in its car
and it faced little problems after a few years out on the road.

~~~
sanjeetsuhag
I'm an aviation enthusiast and a CS undergrad. I've always wondered what's
different about code written for airplanes. Anybody have any insight ? And is
there a modern replacement for ADA?

~~~
scythe
Ada is still under active development and widely used in applications
requiring extremely reliable software.

[http://www.ada2012.org/](http://www.ada2012.org/)

~~~
jcadam
I've used Ada on satellite programs, it's still very popular for that sort of
thing. Ada has managed to carve out a small niche for itself in aerospace and
I don't think it'll be replaced by rust anytime soon.

Which is fine, nothing wrong with Ada.

------
_jordan
I would say unlikely, for the simple reason that Rust is just really _hard_.

~~~
sidlls
C++ is hard, too. So is C, to write correctly. Hasn't stopped either of them
from literally powering almost every computer in use.

Rust's complexity is equivalent to, but distinct from C++'s. I prefer it over
C++, and I'm one big fan of the latter.

~~~
xiphias
I think C++ is much harder actually. Making sure that the system doesn't crash
means writing a lot more unit tests than what would be needed, and sometimes
these problems come out in production only. I would love to switch to Rust,
but it takes many years in a big company.

~~~
eridius
I agree. Learning all of C++ is much harder than learning all of Rust. C++'s
saving grace is you can easily get away with learning only a much smaller
portion of the language.

------
alimbada
Probably. But why do you care? If you like it then use it and build something.
If you don't like it, use something you do like and build something.

~~~
kazinator
Why you might care is that if you build something today, that something could
reap some benefit in the future from the language becoming "mainstream".

Possible benefits:

* users not going "gack, this is written in an obscure language that we have to install to build it".

* the implementation quality being better: the thing I write now will benefit from the language being less of a moving target and with fewer bugs, better performance.

Maybe a lot of that is just psychological, but so is "I like it" versus "I
don't".

~~~
kazagistar
For point one, it helps that Rust is one of the easiest languages I have ever
worked with to install the compiler run-time, pull dependencies, build, run,
and distribute. So at the very least, it won't get in your way if you just
want to distribute a static binary, or give your users a few commands to
compile it themselves, even if it is "some weird language".

On point two, Rust is not a moving target, in the sense that it has maintained
back compatibility since release to an amazing degree, and the build system
does a good job by automatically pinning dependencies for applications. Also,
even if it is totally abandoned, you still have a pretty solid language with
C-like performance that benefits from ongoing LLVM optimizations. But it is
certainly true that there could be unfixed bugs in an abandoned Rust.

~~~
whyever
Unfortunately Rust uses an LLVM fork IIRC, so using it is non-trivial.

~~~
steveklabnik
We can use (and have tests to ensure that it works) a stock LLVM as well.

------
peter_retief
It is

~~~
k__
Certainly more then Nim.

I'd say, before Rust becomes really mainstream, we have to wait for the
current generation of sysdevs to die.

But I guess till this is the case, there will be new languages invented that
may be better than Rust.

On the other hand, most new companies don't hire old devs, so maybe IoT will
give rise to new companies and young sysdevs all using Rust before the old
generation is gone...

~~~
daenney
> I'd say, before Rust becomes really mainstream, we have to wait for the
> current generation of sysdevs to die.

Why?

~~~
k__
Of old age I mean.

It's like with everything. Most people simply do what they always did, most
never reinvent themselves.

~~~
daenney
> Of old age I mean.

Yeah I get that. I asked why they should die. Not how or by what means.

> It's like with everything. Most people simply do what they always did, most
> never reinvent themselves.

Based on? And note that we're not talking about "most people", we're talking
about a very specific subset of people. Considering the changes in popularity
of programming languages and the recent surges in adoption of Go and Swift,
I'd say there's at least evidence to support people do change in this domain
when something comes along that excites them or opens up new possibilities.

~~~
ssokolow
It's a pattern that's been well documented in the scientific community. You
generally get a burst of innovation when enough of an older generation of
scientists dies off for their ossified cognitive habits to stop holding back
the more correct of the theories that have arisen in the mean time.

(Don't ask me to cite it though. I don't have time to go digging back through
the textbooks from my "scientific reasoning" course.)

------
stmfd
I think it has a fair chance (Go is a "systems" language and grew very
quickly). I also believe you'll see it pop up in unikernels as well. Why, you
ask? Because there's always 1 person that starts a project that gets traction.

I don't see it growing and replacing C++ though. I don't think there's much
incentive post C++11 to really consider porting anything (even small things)
over. Most of the features Rust gets praised for are either: (1) Ridiculous -
if you need segfault protection, you're a bad programmer (CLARIFICATION: if
you act like segfault protection is some majorly useful feature, you're an
imbecile who must also think writing C/C++ is like disarming a bomb -
nonsense; give me a real argument for Rust that isn't: insignificant, badly
contrived, already in C++, etc. - you can't convince a generation of systems
programmers to drop everything to move to Rust without this). Let's be honest,
you don't segfault unless you're doing something idiotic. I've not segfaulted
in the past 8 years in anything but assembly. Or, (2), things I've been using
in C++ for the past 4 years.

Rust will definitely end up in these areas I believe but I just hope that it's
not some horrible binding to a C/C++ library or something. I think backwards
compatibility and current dependencies is a big thing.

~~~
makmanalp
> if you need segfault protection, you're a bad programmer. Let's be honest,
> you don't segfault unless you're doing something idiotic. I've not
> segfaulted in the past 8 years in anything but assembly

 _sigh_ Please look at the "trophy case" here:
[http://lcamtuf.coredump.cx/afl/](http://lcamtuf.coredump.cx/afl/)

~~~
stmfd
My views are the responses you'll probably get from the people who've been
doing systems programming in C for the past 20 years. I don't doubt lots of
common applications have memory issues. Maybe not a definite segfault but it's
incredibly disingenuous to act like it's a major issue (as if writing C and
C++ are similar to disarming a bomb or something). It's nonsense and the same
reason I have been learning C++17's stuff rather than bothering with Rust.

I want a better argument for: 1) A C++ developer who's been writing C++ for a
long time and is skilled in modern C++ who is wondering why he'd pick up Rust
for user application development? I await more superfluous bindings like
"Rust-Qt". 2) Porting C/C++ to Rust code (with a rather large codebase).

Every argument I've seen for Rust is: out of context, disingenuous when they
compare it to other languages, or just incredibly biased. I don't think it's
ironic that the majority of people I've met who have started doing Rust are
bad at C and C++ and have bought into the list of features on Rust's homepage
without any knowledge of anything related to them.

~~~
makmanalp
You're being so rude and inflammatory, for no reason. What's so frustrating is
how you're convinced that everyone else is an idiot.

> it's incredibly disingenuous to act like it's a major issue

I gave you a trove of real world examples of serious security issues in widely
used software developed by competent teams. Quite a few of these would have
not existed in a language with the kind of guarantees that Rust provides. How
is this disingenuous?

Take a look at the OpenBSD bug - any user can kernel panic the whole host, a
massive security issue. Are the OpenBSD maintainers, in your opinion,
"idiotic"? Or that Xen bug - privilege escalation. Are the Xen developers, in
your opinion "imbeciles"? What about all the OpenSSL / OpenSSH ones? Perhaps
they're "bad at C"?

The truth is that as code gets more complex, writing safe code becomes harder.
The above is evidence that even smart and experienced people regularly cause
colossal bugs that have real life implications.

~~~
soulbadguy
> I gave you a trove of real world examples of serious security issues in
> widely used software developed by competent teams. Quite a few of these
> would have not existed in a language with the kind of guarantees that Rust
> provides. How is this disingenuous?

Genuine question : do we know that those bugs would have been avoided using
rust? Maybe some of those part would have had to be done unsafe mode for some
reasons.

> Take a look at the OpenBSD bug - any user can kernel panic the whole host, a
> massive security issue. Are the OpenBSD maintainers, in your opinion,
> "idiotic"? Or that Xen bug - privilege escalation. Are the Xen developers,
> in your opinion "imbeciles"? What about all the OpenSSL / OpenSSH ones?
> Perhaps they're "bad at C"?

When was this code written ? you are comparing old C code with (non
existant/hypothetic) rust code. How do you know the rust wouldn't slower ?

> The truth is that as code gets more complex, writing safe code becomes
> harder. The above is evidence that even smart and experienced people
> regularly cause colossal bugs that have real life implications.

That we completely agree on, but we learn quite a bit on how to write better
code. Some of that knowledge got embedded in compilers/compilers warnings and
tooling, some retrofitted in the languages themselves , some through libraries
design and coding guideline etc...

My main problem with your argument is that you saying that a code written in
rust today would be safer than a code written in C/C++ decades ago...That's
probably true.

I think a much more interesting question is how much safer a code written in
rust today would be vs a C/C++ code written today , reflecting our current
understanding and knowledge on how to build safe system.

~~~
pcwalton
> I think a much more interesting question is how much safer a code written in
> rust today would be vs a C/C++ code written today , reflecting our current
> understanding and knowledge on how to build safe system.

A lot safer, judging by browser exploits.

~~~
soulbadguy
> reflecting our current understanding and knowledge on how to build safe
> system...

~~~
mmstick
Despite all the flashy tools that proponents of C and C++ claim that makes C++
as safe as Rust, it's not doing any good at stopping the exponentially-
increasing amount of vulnerabilities and crashes that are being reported over
the last few years.

~~~
Rusky
You have no data at all to back this up. The vulnerabilities you speak of are,
far more often than not, written in old-style C and C++. That doesn't make
Rust a bad idea, but it does mean your claim is completely unsubstantiated.

Advocating for Rust by lying is not going to help anyone.

~~~
mmstick
This is the same line of logic and statements repeated by C and C++
programmers that shortly thereafter get showed up with a list of CVEs in their
'modern C/C++' projects. Remember the recent Curl developer PR disaster?

~~~
flukus
I think it's too early to tell if rust will prove any better in the real
world, which includes things like devs using unsafe sections to cope with time
pressures.

~~~
mmstick
Use of unsafe in Rust is not required or recommended in most, if not all
situations. That said, auditing a handful of small unsafe blocks is easier
than auditing an entire project.

