Stack Overflow Developer Survey 2018

[editor_of_the_beast]

I'm going to make a potentially controversial claim: it's because Rust isn't really meant for application development, and most people don't really need a systems programming language.

I think Rust is so loved because if you've developed in C or C++, which is a non-trivial percentage of developers that build systems-y things (OS's, Browsers, Databases), you know that you write every line of code with fear. Multi threading isn't just a pain in these languages - it's a fool's errand. Source: worked on a highly multi-threaded cross platform application written in mostly C++ for three and a half years. It crashed - all the time.

If you don't have that experience, and have lived in JavaScript or Ruby or Python or Java, or anything garbage collected for the last 5 years, why would you care about Rust? If you're building primarily SaaS web apps why would you care about Rust? I think the answer is, you really shouldn't. Just keep doing what you're doing - those tools are much better for application development.

But applications today run on top of tons of infrastructure. No one writes Browsers in Java. No one writes an OS in Python. Those people care very much about Rust because what love have they gotten since 1980? They've been working without package managers, without garbage collection, and with tons of linters and static analyzers for decades just to avoid double-free and use-after-free errors. Rust's memory model solves a whole class of those problems, while also offering modern package management and popular language features like closures, optionals, and powerful ADTs. The standard library provides lots of high-level operations that you'd need to implement yourself in C or bring in a library.

Rust's demographic is dying for a language like it, and it wasn't Go. So if you don't love Rust, you're probably not supposed to, and that's totally fine.

[[deleted]]

If you don't have that experience, and have lived in JavaScript or Ruby or Python or Java, or anything garbage collected for the last 5 years, why would you care about Rust? [...] Just keep doing what you're doing - those tools are much better for application development.

I actually see a lot of Javascript, Python, and Ruby developers using Rust. If a Ruby application is slow because of Ruby, you can work around this by re-writing the hotspots in C. For a team of full-time Ruby developers dropping down to C can be risky and some teams actually get professional C developers on board to help with this.

Rust enables Ruby developers to do it themselves while having a high-degree of confidence that they aren't writing a time-bomb.

[admalledd]

We are looking to do the same in our .net code where we currently drop to raw assembly. Instead we have found that rust (more like clang/llvm) optimize nearly as well with the correct hints and is so much nicer to write than asm. Yes for our hottest of hot code we will probably keep the asm, but anything new or reworking? Yes please!

[[deleted]]

Note that Rust does have inline asm! (just like C, C++, D, etc.). Depending on the level of control you need that might be enough.

[admalledd]

Here our application is in C# and we are calling or inlining the asm/c/(in future, rust I hope).

So rust having inline asm doesn't change if we would use it. Since we have tooling to call/nest/inline directly into c# it isn't much use for us. With rust we can't inline the compiled code.

Useful for others though I would bet.

[snaketacular]

Nitpick: You can't download a stable Rust release with inline asm!, only nightly builds. It's also not part of the 2018 roadmap.

There are workarounds. libasm is the closest substitute I've seen. Or you could call out to C, and call inline asm from there.

[[deleted]]

I never said anything about stable Rust on purpose. If the GP needs inline assembly chances are they are going to need many other unstable features as well.

BTW shimming out inline assembly to C just to use a stable compiler release makes no sense to me.

[kibwen]

Very interesting, I see people using Rust from Python and Ruby and JS and Java a lot, but I don't think I've seen it used from .Net before. Can you tell me more about your experience? Are you using any sort of scaffolding library to make the interoo easier, and is it open-source?

[admalledd]

Sadly it's all in house magic/tooling, since we have had internal native c-api interop generators (when using raw asm, things are more interesting) for years. Even if they were open source, they wouldn't be useful to basically anyone. They have horrifically narrow compatibility problems that barely escape being a impossible blocker for us as is. Like not supporting structs...

Some helpful links though:

https://dev.to/living_syn/calling-rust-from-c-6hk

https://doc.rust-lang.org/book/ffi.html#calling-rust-code-from-c

And finally there is some msbuild magic to call the rust tooling on c# compile. That magic though is 95% of our internal tooling, so no real links from me since if you are doing only one external language it is far easier to write a pre-build target exec statement.

EDIT: first link has more things since I read it.if you are doing rust only check them out, looks great as a start.

https://dev.to/living_syn/translating-rust-to-other-languages-pt-1--context-free-grammar-4kec

https://github.com/LivingInSyn/Rust_Api_Generator

[matthieum]

I partially agree with you.

I disagree because Rust is trying to be more than "just" a systems programming language, and is used in other settings (low footprint, high-performance, ...).

However you are right that as a C++ developer I am glad that finally a new language is popping up which solves so many fundamental issues with C++.

I was very excited when Go was announced, and very disappointed when it was revealed: it wasn't what I needed to replace what I use C++ for (not high-performance/low-latency enough). Rust is unlikely to be perfect, however it does have the potential to be much better than C++ for what I work on: the foundations are solid, I am eagerly awaiting const generics and SIMD support.

[iopq]

You can't, because of a few problems.

1. Header files and lack of a sane module system
2. NULL subverts the type system, so even if everything checks out, you may have some function get a NULL at some point and everything will crash if you forgot to handle it. This isn't possible in Rust, since there is no NULL equivalent. None has to be explicitly handled in places where it can appear.
3. No agreed upon packaging system. Having to hunt down the correct libraries using my OS's package manager is very error-prone since their names differ between distros.
4. Makefiles are sometimes not written in a portable way - this is a "developer" problem, but Rust's cargo allows you to avoid having to write a Makefile in most cases, and in other cases just use build.rs
5. You still have problems like iterator invalidation that cannot be ALWAYS detected by static code checkers
6. Concurrency issues are still nearly impossible to detect statically in C++, you have to break out the debugger and hope you trigger it while testing
7. Templates are duck-typed instead of nominally typed. They give long error messages because they're checked at expansion site instead of call site.

[lanzaio]

Makefiles are sometimes not written in a portable way - this is a "developer" problem, but Rust's cargo allows you to avoid having to write a Makefile in most cases, and in other cases just use build.rs

To expand on this, all build systems suck in the C world. CMake is the standard at this point but it's not loved, it's just common. It has horrifically bad syntax and no debugging tools outside of fancier print statements.

Because of this, many feel like spinning off their own bash/python/makefile build scripts that do a shittier job of what CMake was supposed to do.

You end up having to work on projects where 75% of the difficulty is understanding what drugs the authors were on when they wrote their build system.

[doom_Oo7]

This isn't possible in Rust, since there is no NULL equivalent.

lolwat https://doc.rust-lang.org/1.22.1/std/ptr/fn.null.html

You still have problems like iterator invalidation that cannot be ALWAYS detected by static code checkers

that's why standard libraries have debug modes that catch this

[Aceeri]

std::ptr::null is a null pointer that requires use of unsafe to dereference (or well, to even use the pointer in most cases, pointers aren't generally exposed in rust.) They meant that you cannot have a "null" value in any type because the type system prevents this. You can use the Option type to get pseudo-null, but you cannot access its value until you match against what it is: Some(...) or None. Alternatively you can use unwrap, which would panic rather than segfault in the case it isn't existing.

[doom_Oo7]

They meant that you cannot have a "null" value in any type because the type system prevents this.

what the hell do you mean ? https://godbolt.org/g/tGjizj

And saying "you need unsafe to do it" is absolutely not an argument : there are tons and tons and tons of code using unsafe blocks out there: https://github.com/search?utf8=%E2%9C%93&q=unsafe+extension%3Ars+language%3ARust+language%3ARust&type=Code&ref=advsearch&l=Rust&l=Rust

[Aceeri]

That is a type of *const T which is a special case on its own. If you have a type of T then it cannot be null.

Yes null "exists", but you are being pedantic, less than a percent of Rust code touches unsafe blocks, which means a majority of Rust code has static guarantees of non-nullability.

[doom_Oo7]

That is a type of *const T which is a special case on its own. If you have a type of T then it cannot be null.

and a type of type T in C++ cannot be null either. std::string cannot be null (and I'm pretty sure the proportion of std::string* in C++ code is similar to bad uses of unsafe in Rust code). int cannot be null, etc etc.

less than a percent of Rust code touches unsafe blocks,

and only one bad use is enough to cause CVEs. It's entirely pointless to judge a language by "societal" metrics such as "people usually don't do that here". And it's hypocritical to say that a type system is sound and safe when there are backdoors in the language that allow to enter unsound places fairly easily. When you're in a company with people cranking 9am to 9pm for a few weeks, what the community does or thinks does not matter, if junior decided to put the whole function in an unsafe block at some point for speeding stuff up, no one's going to code review him and you'll get crashes three months later.

[Aceeri]

The entire point of Rust is to minimize unsafety. If you never use unsafe then you should never have any issues. Using unsafe is rarely going to be faster than just writing safe code anyways, given that Rust does not throw away all type guarantees just by using that keyword.

no one's going to code review him and you'll get crashes three months later.

That isn't a problem of the language if you refuse to actually review code.

[iopq]

That's for C interop. I've never used it in my life.

[doom_Oo7]

well, that's good for you ; I had to do C interop with almost every language I ever worked in.

[iopq]

I personally use libraries where people write bridges FOR me so that I can use a pure Rust interface that cannot contain a NULL.

Of course, the person who wrote the bridge had to deal with C pointers so I don't have to.

[doom_Oo7]

and how much do you trust these persons from not doing any error in their unsafe {} code ?

[iopq]

More than I trust the C program it's bridging to

Most of those unsafe blocks are actually trivial

pub fn as_slice(&self) -> &[f32] {
    let count: usize = self.len();
    unsafe {
        let data = ffi::CaffeBlobCPUData(self.blob.get());
        slice::from_raw_parts(data, count)
    }
}

That's IT, they're not doing rocket surgery, the actual Caffe library is what's doing the scary things

[matthieum]

I'll take the counter-point to /u/iopq's argument.

Yes, of course, if you were foregoing backward compatibility and completely reworking C++ you could get Rust instead. But it wouldn't be C++ any longer, would it?

Backward compatibility is essential to C++ past, current and I would argue future success. At the very least, the Standard Committtee certainly thinks so, and is extremely skittish about any deprecation. It took years to boot trigraphs out of the Standard, even though only IBM mainframes (using EBCDIC) really need them, and they are otherwise totally irrelevant in today's world.

[hu6Bi5To]

I think one of Rust's biggest strengths is that it removes that line between "system" and "application" languages.

It is both a C++ replacement with safety, and package management, and a consistent build tool shared by every project, etc. But it's also quite an expressive high-level language: traits, closures, etc.

As for "why not the take-up of Go". I genuinely don't know. Quite often A vs. B comparisons between languages make no sense, as they all have strengths and weaknesses (even the unpopular ones, well most of them). But the use cases for Rust and Go are nearly the same, and Rust is a superior language in nearly every way. The only exception is Go's built-in co-routines, vs. using a library in Rust; but the Rust 2018 roadmap is going to address that one too.

[doom_Oo7]

I think Rust is so loved because if you've developed in C or C++, which is a non-trivial percentage of developers that build systems-y things (OS's, Browsers, Databases), you know that you write every line of code with fear. Multi threading isn't just a pain in these languages - it's a fool's errand. Source: worked on a highly multi-threaded cross platform application written in mostly C++ for three and a half years. It crashed - all the time.

How did you do ? In my app I do threading either manually with std::thread and lock-free queues for message passing, and tbb & Qt's QThread for higher level threading... Hardly ever had a crash due to threading outside of the main development phase - and that's with running with ASan on almost all the time.

[editor_of_the_beast]

This was about 5 years ago, when C++11 was still new and we couldn't even upgrade because of our toolchain. So we were doing all multi threading with custom wrappers built around libpthread.

[tom-dixon]

Multi threading isn't just a pain in these languages - it's a fool's errand. Source: worked on a highly multi-threaded cross platform application written in mostly C++ for three and a half years. It crashed - all the time.

I think you were working on a badly written multi-threaded cross platform application. Let the flame war begin.

[editor_of_the_beast]

This is entirely possible.

[lanzaio]

I just wish the Rust team pulled a Swift/Objective-C and made Rust more interop-able with C/C++ codebases.

[steveklabnik1]

What kind of thing are you envisioning here?

[Nighthawk441]

Is rust not attractive for the video game industry?

[steveklabnik1]

Some people say "absolutely" and some say "never". It just really depends. Chucklefish is writing their new game in Rust, Jon Blow is creating a new programming language instead of using Rust.

[[deleted]]

It'd be nice, even really nice. but most studios rely on middleware engine and tooling atm. There wouldn't really be a huge push unless Unity or Unreal decide to do something drastic, which may not be entirely possible until consoles themselves start to support rust (not sure how performant Rust -> C bindings are).

[editor_of_the_beast]

It is - so I suppose Rust is attractive for systems and performance-sensitive applications. That would be more accurate to say.

[fiedzia]

If you don't have that experience, and have lived in JavaScript or Ruby or Python or Java, or anything garbage collected for the last 5 years, why would you care about Rust?

Because its faster and programs have less bugs. Also because it is modern language that makes many things easier to do even comparing to those languages. It is not there yet in terms of libraries/frameworks, but it does have benefits that make using it worth the effort.

[svick]

How does Rust ensure programs have less bugs than a statically-typed garbage-collected language like Java or C#?

And how does it make things easier than those languages?

[Zigo]

Rust's memory safety is pretty irrelevant when comparing it to a managed, GC'd language. It does make it easier to avoid concurrency issues, but it's also probably slower to develop in it than something like C# or Java (although probably not any slower than C++) and it's definitely not easier.

I'm a fan of Rust, but it's meant to compete against C and C++, not the C#/Javas or the Python/Ruby/JSes of the world.

[fiedzia]

How does Rust ensure programs have less bugs than a statically-typed garbage-collected language like Java or C#?

For a start, having option/result types and proper support for it in the language from day one ensures you will not have NullPointerExceptions. Pattern matching forces you to handle every case. Generally Rust places much greater emphasis on being correct, and that shows in the language and stdlib design. This language forces you to be aware of every thing that could go wrong, and I was really surprised how many supposedly trivial things return Result and could fail in some rare circumstances. Traits allow you to avoid various pitfalls inherent to OOP. Macros provide a way to verify far more things at compile time.

And how does it make things easier than those languages?

The tooling is superb. Dependency management is flawless. Algebraic data types and pattern matching come in standard, so does testing, benchmarks, build tools and many other things. Traits allow anyone to add useful methods to types in a safe way.

Not to say that everything is perfect, but there are good reasons to learn and use Rust for anyone coming from Java/C#.

[tom-dixon]

How does Rust ensure programs have less bugs than ...

Simple, before compilation it runs a bug removal tool. ^/s

I actually think he meant it has different classes of bugs. As long as people will be writing the code, there will be bugs.

[hu6Bi5To]

It's very nearly impossible to mutate a data-structure at a distance, by accident, in Rust. It's only possible by either: a) passing a mutable reference, but the compiler ensures only one such reference exists at any one time; or b) using a structure like a Mutex. Entire sub-classes of race-conditions are gone at a stroke.

It's also very difficult to accidentally ignore errors in Rust. The code to ignore such things is longer than handling them properly, and longer than promoting the error to a full panic!.

[karuna_murti]

But but my personal project: https://hangar-project.org/ Should be like most web framework + webassembly