
2016 Rust Commercial User Survey Results - cpeterso
https://internals.rust-lang.org/t/2016-rust-commercial-user-survey-results/4317
======
Animats
From the article: _"...fourteen companies responded to our outreach"_

That's not a survey, that's a focus group.

I'm impressed with Rust. The borrow checker is the biggest advance in memory
safety since garbage collection.

But there's a lot about Rust that's unnecessarily weird.

\- The type system is unusual, and complex. It's hard to do anything without
templates.

\- The template libraries are heavily biased towards closure-oriented
functional programming. This is cool, but hard to read. Parts of expressions
are nameless and have no visible type. This is terse but hard to maintain.

\- The hacks needed to avoid the need for exceptions are uglier than
exceptions.

This creates major obstacles to adoption. Unlike the borrow checker, none of
these things are clearly improvements. They're just different.

I would have gone for Python-type exceptions rather than error enums and
macros, single-inheritance OOP rather than traits, and Python-type with
clauses rather than RAII.

~~~
papaf
_The hacks needed to avoid the need for exceptions are uglier than
exceptions._

I felt like this when I read the scary documentation: [https://doc.rust-
lang.org/book/error-handling.html](https://doc.rust-lang.org/book/error-
handling.html)

However, in the total 4 hours or so that I have been programming in rust the
way of handling errors seems very sensible.

\- Match expressions instead of "if (error) dosomething()"

\- Match expressions with destructuring gives the error message.

\- Match expressions are exhaustive which forces errors to be checked.

Its simple and elegant. I think the documentation is a little overwhelming
when it comes to error checking and introduces non-essential craziness without
warning.

~~~
Animats
Rust now has not just "panic", but "panic::recover", with unwinding. That's an
exception system. It's just one with weak syntax and semantics. Go went down
this route, too. In the beginning, Go errors were fatal. Then the Go crowd
added "recover". With unwinding. Both languages now have the heavy machinery
for exceptions without full language support for them. The discussions of this
on Rust mailing lists show much unhappiness with the situation.

If you don't put in exceptions, you seem to end up re-inventing "longjmp".

~~~
Manishearth
Panic recovery and panics can be disabled, and often are. Libraries are not
supposed to rely on their existence. Thus these are not a form of exceptions ;
they can't be used as such.

Their purpose is to recover from panics when embedding Rust in code written in
other languages, where you don't want the panic to try and cross the ffi
boundary (or to stop applications that should _never_ crash from crashing at
the toplevel, or for better reporting before a crash). Many FFI-based
applications turn panics into aborts anyway. Firefox does.

The unwind-recovery functionality in Rust is just enough to get you these
useful features _if you need them_ (zero cost if you don't; turn them into
aborts), without needing a full on exception system. The reason Rust avoids an
exception system isn't the cost of unwinding, it's because it considers
exceptions to be an inferior pattern compared to return value based / monadic
error handling.

Rust doesn't have a mailing list anymore. I haven't seen much annoyance with
panic recovery. There used to be some with panics in general because in the
past they couldn't be turned off or recovered from without a new thread, but
this has been addressed for ages with panic=abort and recovery. What the hell
are you talking about?

------
bfrog
I'm using it commercially, though wasn't asked in the survey. I've had zero
crash causing failures in production with a web interfaced analytics pipeline
service I wrote. It just sits there, with its 10's of gigabytes of data
running day in day out... handling millions of events every day, crunching
business vital numbers. Best thing ever.

~~~
olauzon
Similar story here. Been using Rust in production for only a couple of weeks
for a financial analytics pipeline processing billions of events per day and
TBs of data, but absolutely no issues so far. The predictable performance of
Rust has been wonderful to observe, compared to GC'ed languages this iteration
of the pipeline has replaced (JVM, Go). The type system makes otherwise daring
refactorings a joy.

~~~
Manishearth
-> [https://news.ycombinator.com/item?id=12877334](https://news.ycombinator.com/item?id=12877334) :)

~~~
olauzon
Will ask employer for approval :)

------
kinofcain
Can't argue with anything in that list.

I think it would also be useful to survey people who looked into using Rust
but decided against using it, as responses from people who suffered through
the warts is analogous to looking at the damage to bombers that made it back
to base. Still relevant, but not the whole picture.

I'd expect to see mobile/cross-compilation (which I know is getting better) to
rank pretty high among people who didn't stick with it, but maybe I'm
projecting.

~~~
jntrnr
There's some coverage of the "why I chose not to use Rust" in the Rust
community survey that happened earlier this year: [https://blog.rust-
lang.org/2016/06/30/State-of-Rust-Survey-2...](https://blog.rust-
lang.org/2016/06/30/State-of-Rust-Survey-2016.html)

------
squiguy7
What I would be interested in is how these companies use Rust in their stack
and what kind of problems they can solve. I suppose not every company can
divulge this information but it would be awesome to know where Rust fits in
for them.

~~~
muizelaar
[https://www.rust-lang.org/en-US/friends.html](https://www.rust-lang.org/en-
US/friends.html) has a single sentence version of this kind of thing.

~~~
kibwen
Lots of those sentences also link to posts with more extensive experience
reports.

------
gravypod
> We received a resounding response to continue investing in building strong
> IDE tools. IDE tools in a commercial setting help teams coordinate their
> efforts by making it easier to navigate unfamiliar code, on-board new users,
> and streamline the development process.

I cannot wait. I cannot wait until this happens. Rust will become my main
language.

~~~
alfalfasprout
This is one of the key things preventing us from moving to Rust. Yeah, I love
vim but on a very large codebase an IDE just helps you keep everything much
more organized and productive.

Moreover, moving to Rust would require investing in ports of some large-ish
C++ libraries we use.

I think Rust is here to stay. It's a great language without a runtime that
should be able to match C++ in performance when the compiler frontends catch
up.

We'll start using it in some new projects but I doubt we'll port critical
infrastructure for a few years.

~~~
steveklabnik
Which IDEs matter to you? We're actively working on it.

~~~
mindcrime
Not the poster you were replying to, but Eclipse here. I'd definitely want a
great Rust plugin for Eclipse if I were going to invest heavily in Rust.

~~~
steveklabnik
Cool! [http://rustdt.github.io/](http://rustdt.github.io/) exists but I've
never used it.

------
the_duke
Great to see Rust gaining a foothold in commercial areas.

While by no means a perfect language, I enjoy it much more than writing C++.

~~~
sdegutis
Why do you specifically _enjoy it_ more than C++? As far as I know, the main
goal of Rust is to be _safer_ than C++, not more enjoyable to write.

~~~
sidlls
Long time C++ programmer here.

I specifically like the immutable-by-default, borrow, and move semantics. I
can write safe code without bloating up my source with 'const &', std::move,
'&& ...' and the like.

The safety issue for me is about the least important thing. Touting it as the
big reason to use Rust is a distraction from my point of view.

~~~
santaclaus
> The safety issue for me is about the least important thing.

For real. Rust is a great language, but for the love of god, all you hear is
safety safety safety. I give about 2 out of 10 fs about safety. The worst part
of C++? Dependency management. Cargo is sick -- hype that up more!

~~~
pjmlp
> The worst part of C++?

The worst part is people using it as if it was C with a C++ compiler.

I lost count the amount of times I had to create a nice C++ wrapper for "C++"
libraries that are just a pile of C functions and data structures, due to
copy-paste compatibility.

And yes, the respective lack of safety by not making use of C++ improved type
system and standard library.

------
cm3
This wasn't one of the question of the survey, but while having the right
crowd around, I have to ask.

When will Rust get

1\. function head patterns like other languages in the ML family, although
Rust isn't really part of the family, but rather a distant cousin from another
continent, which once played with ML and family during a summer vacation

2\. support for naturally writing recursive functions

~~~
Manishearth
> Rust isn't really part of the family, but rather a distant cousin from
> another continent, which once played with ML and family during a summer
> vacation

It's actually more of a sibling in the family who ran away from home at the
age of 6 and fell in with the crowd on the wrong side of the tracks.

Initially Rust was very much like ocaml. It isn't anymore :) Many of the
normally-in-functional-languages features in Rust come from these days. Others
were lost and re-added later. It's a very complex history.

> function head patterns like other languages in the ML family

could you elaborate? I'm not familiar with this feature (only have dabbled in
sml).

> support for naturally writing recursive functions

yeah, I wish we had TCO.

~~~
cm3
> It's actually more of a sibling in the family who ran away from home at the
> age of 6 and fell in with the crowd on the wrong side of the tracks.

> Initially Rust was very much like ocaml. It isn't anymore :) Many of the
> normally-in-functional-languages features in Rust come from these days.
> Others were lost and re-added later. It's a very complex history.

Yeah, having tried Rust in those days, I kinda stopped when it broke every
week, and was then surprised with the surface of 1.0. It seemed like a
different person to talk to.

I've made my peace with the C'ification of Rust as the price to pay for
attracting a large crowd of developers who grew up with C, C++, C#, Java,
JavaScript, Ruby, Python, the list goes on. It's a reasonable sacrifice to
make, but the two mentioned basic features aren't complex things to wish for.

> could you elaborate? I'm not familiar with this feature (only have dabbled
> in sml).

Imagine being able to hoist your match clauses into function head
(signature?).

    
    
      oldEnoughToDrink :: Int -> Boolean
      oldEnoughToDrink 21 -> True
      oldEnoughToDrink _  -> False
    

Not all languages with support for that force you to repeat the function name,
and there are good arguments for/against. For example in Erlang, when you
define an anonymous function, you do not repeat it:

    
    
      OldEnough = fun(21) -> true;
                     (_)  -> false
                  end,
    

Now, this may seem like a stupid little feature, but trust me when I say it's
a natural feature to use like recursive functions after you're used to it.

~~~
Manishearth
Oh, yeah, I see what you mean by function head patterns. I'm aware of the
coding pattern from Haskell, just didn't know the name :)

I don't think Rust will get support for that. You can simulate it with macros
(and, later, syntax extensions). Of course, that isn't as clean as pure
language support. I know why it makes recursion (esp tail recursion) easier to
use though. You could always bring it up on the forums and try though.

~~~
cm3
1 and 2 go hand in hand in recursive functions, but 1 is useful without.

Say you have a function that should will tell you a file extension is likely
to be that of a text file:

    
    
      isTxt("txt") -> true;
      isTxt("org") -> true;
      isTxt(_)     -> false.
    

With a more comfortable syntax, this can be expressed more concisely, but I
just wanted to show that this isn't only useful for recursive functions.

If Rust is planned to get HKT, then I don't see why I cannot get pattern
matching in function heads when there's also guards as found in ML languages.

~~~
Manishearth
> I just wanted to show that this isn't only useful for recursive functions.

Oh, I know that it's useful; I've used it in Haskell often. And the `fn foo
(x) { match x {}}` pattern isn't uncommon in Rust.

> If Rust is planned to get HKT then I don't see why I cannot get pattern
> matching in function heads when there's also guards as found in ML
> languages.

The HKT proposal logically extends existing associated types syntax so that
you effectively have HKT. It's particularly elegant in that it's something
folks (who are unaware of what HKT is) on learning about associated types
_expect_ associated types to support. I've had folks ask countless times as to
why you can't `type Foo<T>` in an associated type.

It also opens up access to patterns that weren't possible in the past.

OTOH function heads would just be sugar for fn + match. It doesn't open up new
possibilities, it just makes some patterns easier to type. And frankly, with
blocks being expressions, it's not much easier to type. You have to provide
the function signature somehow, and it's there. The match arms are also there
in both the Rust and haskell versions. The only thing exclusive to the Rust
version is that you need to explicitly say `match`. Meh.

Languages have a "complexity budget" \-- spend too much of it and folks won't
learn your language because it's too complex. Rust has spent a lot of it on
the borrow checker. Adding random bits of syntax spends this budget, and you
need a compelling reason to do so. This is why I'm quite fond of the current
HKT proposal -- I'd always thought HKT in Rust was pie-in-the-sky, but the
current proposal ends up with a very unsurprising and natural-looking syntax
(and doesn't feel "new"), which makes me think that it has a good chance of
succeeding.

If you can come up with a good proposal for function heads, who knows, it
might happen! But it will have to be good; I don't think just proposing
function heads without tons of justification and/or a syntax that fits in
naturally will work.

------
dreta
I’d love to see a survey talking about what bugs get actually solved by using
one of these modern languages like Rust or Swift, since i personally never
once in my career had a bug that wouldn’t have happened if i used const, let
alone any of the many other annoying Rust features.

For a “systems programming language”, Rust doesn’t let you do anything i’d
expect, like let you specify whether a signed integer is 2s compliment, and
how it behaves when it wraps. Instead the programmer is at the whim of the
compiler writer, same as in C, and its “undefined behaviour” which is a source
of real, hard to track bugs. Rust doesn’t even have support for modern
features like wide registers, or any features that help you deal with raw
memory, it just marks it as “unsafe”. There aren’t even any basic meta
programming features like struct introspection.

What problems does Rust actually solve that C and its copycats have been
suffering from since the 70s.

~~~
sidlls
I'm sorry, I have plenty of gripes about the Rust team touting safety as much
as they do but your comment just misses the mark, in my opinion.

To begin with, "safety" isn't solved by just using const. It simply isn't
feasible to write safe code in C without restricted feature usage to the point
of being crippled. It's much easier in C++, but requires an incredible level
of focus and "cruft constructs" like ' 'const &' and such. Arguably until move
semantics were standardized with C++11 it was a challenge to write safe code.

I will agree that Rust's developers have perhaps come down too far on the side
of "YOU ARE DOING SOMETHING DANGEROUS BY USING A POINTER." But I think you're
exaggerating a bit about how hard it is.

~~~
dreta
My point was that i haven’t come across a Rust feature i felt would save me
from creating a bug.

~~~
Manishearth
Rust isn't a panacea, nor does it claim to be. It doesn't prevent bugs. It
prevents memory safety bugs.

~~~
sidlls
> nor does it claim to be.

"It" doesn't do anything. But some of its fans conflate "prevents memory
safety bugs" with "panacea", at least by implication, as I perceive it.

Besides, right now a lot of the "memory safety" of Rust has much more to do
with selection bias (it is used primarily by people who are explicitly
interested in using its safety features). When one uses exclusively (or almost
exclusively) the "memory safe" features of the language, of course things
implemented in it will be free of "memory safety" bugs. Rust helps make doing
unsafe things explicit. It doesn't prevent one from doing unsafe things.

Here's how I see Rust: it's far and away already superior than C++ for a
certain class of systems application programming (e.g. performant
desktop/native application code that sits at the systems boundary). Rust code
that seriously competes with C or C++ for "low level" systems programming is
going to have to make use of plenty of Rust's "unsafe" constructs. If it gains
traction "in the wild," my prediction is we'll start seeing plenty of "memory
safety" bugs in that area. The question then is how easily they're spotted and
rectified.

~~~
Manishearth
> But some of its fans conflate "prevents memory safety bugs" with "panacea",
> at least by implication, as I perceive it.

While you may be right, I have never seen this happening (and I participate a
lot in online discussions about Rust); people seem to be very careful about
saying that Rust prevents memory safety bugs, not bugs in general. People do
say that the type system _helps_ prevent general bugs, but that's only to the
extent that any similar or more powerful type system (Haskell, xML, etc) can.

> Rust helps make doing unsafe things explicit. It doesn't prevent one from
> doing unsafe things.

I mean, yeah. No language can (unless it avoids FFI entirely). See
[https://news.ycombinator.com/item?id=12877136](https://news.ycombinator.com/item?id=12877136)

Rust gives you the tools to prevent yourself from doing unsafe things (and
still be able to write software).

You can get a lot of stuff done in safe Rust. When you need to drop down to
unsafe Rust, you can design safe abstractions around the unsafe code, and
manually verify the safety of the abstraction. This has a human component, so
it's not _perfect_ , but it's pretty close :)

The unsafe feature isn't just there for explicitness, it is designed to
provide the ability to do this -- the ability to design safe abstractions.

> for "low level" systems programming is going to have to make use of plenty
> of Rust's "unsafe" constructs.

Designing an operating system low level enough? There are a bunch of
initiatives to write an OS (both serious and as a learning project) in Rust.
As far as I've seen, all of them avoid unsafe code like the plague and design
safe abstractions around everything so that they only need a smattering of
unsafe code. os.phil-opp.com has a bunch of blog posts on OS design in Rust,
some of which explicitly demonstrate this pattern (e.g. the page table one).

When you say "When one uses exclusively (or almost exclusively) the "memory
safe" features of the language", you're talking about basically the entire
target audience of Rust, and this _includes_ low level users. Rust isn't
supposed to be used with lots of unsafe everywhere; and folks have tried hard
to make it so that this isn't necessary even for low level applications (the
Zinc project, while no longer maintained, is an example of this for embedded
software). Of course there are areas where you'll be using more unsafe code
than others, but you're still supposed to be "almost exclusively" using safe
Rust code. If you need unsafe everywhere for your low level application then
that's something you should bring up with the Rust community. (To be clear,
the Rust ecosystem and language _right now_ has some issues that crop up in
low level development, but these are being worked on)

In fact, there is only one place where I've seen unsafe code being sprinkled
around liberally, and that's when binding to a C/++ library. Currently my job
involves a lot of this, and I'm trying to make it safer (largely succeeding!),
but it's still has a higher density of unsafe code than, say, Phil's Rust OS
(or I think Redox, but I haven't looked at that in a while). In this case,
though, you're already talking to C/++ and there's inherent unsafety there
(plus an impedance mismatch), so you can't always blame Rust for it :)

\------

I guess you're right that "Rust prevents memory safety issues" isn't 100%
accurate because `unsafe` exists. "Rust gives you the tools to prevent memory
safety issues" might be more accurate, but still misses nuance. I think for a
soundbyte on Rust it's accurate enough to say (because it prevents these
issues more or less as much as possible without being useless for writing
software), but it's a caveat that we should probably mention more.

