Rust Survey 2019 Results

VC++ analyser + Intellicode (AI driven intelisense)

C# Roslyn analysers or StyleCop, also on VS.

CheckStyle or PMD for Java, alongside Netbeans, Eclipse or InteliJ.

XCode analysers.

CLion Inspections.

One of the issues preventing the type inference from working in the presence of associated types was fixed this week, so the next release should be even better.

I find C much simpler to learn and to write simple things in.

If you learn C, you'll find that most used languages are compatible with C way of thinking. You can pick up C#, Java, Javascript, Python, PHP with ease as you kind of think in the same way.

While Rust, the language might not be terribly complicated, you have a totally different paradigm, the restriction on variables and the borrowing system makes it totally different than the languages people are used to, to the point that for beginners is totally unintuitive.

You can't just declare a variable, initialize it, pass it to a function and get a result back.

You can't have self references in a structure.

No, siree, as a beginner learning Rust you have to do a lot of complicated dancing around the borrow checker.

Comming from C like languages I find even functional languages like F# easier to pick up. Because they feel more intuitive. Unlike Rust you kind of feel what kind of code you need to write to get a workable result.

Right now I feel that the only advantage of Rust over other safe by default languages is speed. You can use low level constructs and unsafe features like raw pointers in C#, but the garbage collector for the safe code slows it down.

I don't think garbage collected languages can ever be as fast as Rust.

Reference counting like in Swift is another way to provide simplicity, but I see Swift is even slower than garbage collected languages.

So if your use case needs both performance and safety, Rust is your best bet.

It seems that from simplicity, performance, safety you can only pick two at once.

Microsoft Research is working on a language inspired by Rust. I'm curious if they can come up with something as safe but easier to use. I wouldn't bet on it. They aren't convinced of the outcome since they recommended to write or rewrite parts of their software in Rust instead of waiting for the new magical language.

A good thing from Microsoft evaluating Rust to use in their huge code base is they learned about a few weak points and are making recommendation to Rust team.

One side effect of Microsoft embracing Rust might be that other corporations like Google and Oracle might avoid it to distance themselves from Microsoft.

To better illustrate this, compare with Brainfuck. It is also a very small, simple language.

Its simplicity is at the same time its own worst enemy, in that it pushes down all the difficulties, complexities and verbosity for you to manage yourself. Perhaps an extreme comparison but just to show that simpler language doesn't always yield a simpler program.

C is easy, programming, hard.

https://stackoverflow.com/questions/21177436/is-there-a-publ... 6 years ago.

I was going to compare how many pages the rust standard has, and compare it to the C standard (plus 20% for the "correctly manage memory" that you pointed out as something extremely complicated). http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

Anyway.. C is a rather simple language. No matter what the opinion of rust programmers is.

Please don't respond to this post. At least not with the bog standard "undefined" "unsafe/memory" and other shallow conceptions.

On that “use HashMap” line of thinking... http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa...

It's far easier to use Dictionary in C# than HashMap in Rust.

However we aren't comparing languages here but standard libraries.

If we introduce modules in C instead of header files and add some simple data structures and algorithms to stdlib, I can see C being simpler.

C++ has data structures in its standard library and will have modules starting with C++20.

If you don’t need to understand/inspect the details of a HashMap implementation then you are not doing ‘systems programming’. The attitude that ‘someone has done it for me’ and therefore I don’t care about it is not a characteristic of ‘systems programming’. It may be simpler to just use some standard implementation of a data structure, but if that is the case, then you can get by with most of the commonly accepted language paradigms. I’m not saying everyone need to implement a unique hashing algorithm tailored to use case, but that is what systems programming is.

System Programming is the custom tailoring of data conditioning to a particular set of circumstances and then taking responsibility for the benefits and consequences of that those choices that differentiates systems programming from the other broad categories of program construction.

Rust is a fine language if it fits your use case, and you feel as though the purported benefits of the ‘borrow checker’ assist you in writing quality code, but if you just want a programming language that provides a large library of pre-written solutions, then the difference between language is dependent only on use case and usage requirements. Saying Rust is simpler than C because you can use a pre-written HashMap implementation is ridiculous, because you can do the same thing in C (I mean use someone else’s HashMap). But if ‘systems programming’ is the area of interest, being able to inspect/implement the actual HashMap is a key concern, and just dismissing that aspect is not an acceptable proposition.

> Rust seems to be popular only in the web sphere, where Javascript and Python programmers are tweeting that they now know a "systems language".

I see that is the best thing Rust brings to the table, as the scope of learning and using Rust is pretty much “scoped “. Once you are comfortable with the compiler, you can use Rust reliably and deloy code to production. Whereas C/C++ is very “open” to learn, you can learn the syntax and basic in a couple of weeks, but to use it correctly and reliably (to a certain degree) WITHOUT SUPERVISION from another advanced programmers takes years of experience under your belt.

>Rust seems to be popular only in the web sphere, where Javascript and Python programmers are tweeting that they now know a "systems language".

This is great because now we are starting to get faster, more performant libraries and code. People switching from Node to Rust see huge speedups. Perhaps we'll also switch from JS to rust with WASM. Rust is nice because it's high level enough to write code with algebraic data types, like in TypeScript, so that maintenance is easier. Personally I'd love to see as many people as possible move from JS and Python to Rust.

Does clion/intellij use its own analyzer or embed an open source one?

Yes, I'm a frontend dev. I know my todo list examples, haha.

I looked into D once or twice. Found learning materials severely lacking. Having to read up on the differences between 2 (3?) compilers and choose between them wasn’t a great intro.

For the work I do GC is also a non-starter. I know it’s got some level of no-gc now but the last time I looked it wasn’t well-supported.

In short it seemed interesting but on-boarding felt hard. And with that the value proposition wasn’t there or well-advertised: It’s supposedly “better” in some ways such as faster compile times and better meta-programming and frankly that didn’t seem worth the effort.

Rust by contrast does an excellent job of onboarding and making it easy to learn the language (at least at an introductory level). It also comes with a very straightforward value proposition: just as fast as c++ but whole classes of bugs simply aren’t possible. Add in a little bit of ergonomics and functional flavour and I was hooked.

I love D's community and what they were trying to achieve, but it appears that the language has lost its opportunity to adoption or sense of direction.

What I liked on it over Java and .NET languages, is no longer relevant after GraalVM, and the low level features in C# 7/8 adopted from Midori, came to be.

Also C++20 now makes much D less relevant.

Unfortunately the recent @safe and @live discussions don't inspire confidence in which direction they want to drive the language design.

Rust already has synchronous TCP and UDP in the standard library (https://doc.rust-lang.org/std/net/index.html). But most people want to use async versions, at which point there very much isn't one way to implement it.

Once you get to higher level protocols like HTTP, you also have questions like "should HTTP header be strings or encoded as types. There very much isn't just one way to implement it.

Do you do it with callbacks or polling?

That's pretty fundamental and completely changes your API.

And, before you reply, you might want to know that while the majority of things do it with callbacks, both the lowest embedded AND highest custom networking systems implement networking with polling (for different reasons).

Node and Go are both purpose-built for the web. Rust's target market is much broader than that; some people even use it on embedded devices. One of its headlining features is its slim standard library. That trait shouldn't be thrown away without good reason.

> First of all, we tend to work on what users are asking for. This survey shows a lot of interest for web and rust.

If (if!) Rust's mission was to replace C++, that would be a mistake.

That's pretty obvious, right? You decide to replace C++. You make a language which isn't a great C++ replacement. You attract users who aren't C++ programmers. They aren't interested in the things C++ programmers are interested in. You build features which don't appeal to C++ programmers. Lather, rinse, repeat.

I think at this point, in practice, Rust's goal isn't to replace C++. It's to become a better Rust.

> C++20 async/await isn't relying to competing external libraries.

Standard library is a liability. It's only a matter of time before any non-trivial stuff will turn out to be worse than a 3rd party solution, and won't be able to catch up due to std's constraints (C++ regex being extreme example).

Rust has already learned that lesson with channels. So instead of having to say "don't use std's, use the other faster nicer thing", Rust skips over the tech debt part, and recommends the other faster nicer thing immediately.

And a clean separation of await from its runtime is actually pretty cool. I'm writing a GTK+ app right now, and I can await button clicks on its event loop.

Please don't post flamebait to HN. Generational flamebait is among the dumbest and most wretched sort we see here.

https://news.ycombinator.com/newsguidelines.html

> maximum age where you can learn new things

When is that? Knuth is 82.

People used to say the same about C++ vs. Java. (But hey, C++ devs were young back then, and many of them did switch to Java; didn’t hurt C++ though - it was the best who stayed.)

Web development projects in a new language is a good starting point because you can do something with pretty UI quickly and with minimum configuration. But it has no staying power. A web developer will be gone after a couple of months (fun to learn!), leaving behind nothing, and suddenly Rust will have lost its footing (systemdevelopment).

I’m always happy if people use Rust. But why call out an unrelated field with a use case nearly opposite of Rust’s design requirements as “the lifeblood” of adoption?

There’s one specific substantial benefit in comparison with typical Java-like languages: concurrency is much easier in Rust. Having “is this thing thread safe?” answered at compile time is something I missed in Kotlin a lot. Of course, it does not necessary outweigh the need to think about references vs owned values, etc.

I think Rust was relevant in bringing affine types into mainstream, after the ATS and Cyclone attempts.

Thing is, with ongoing efforts on managed languages to integrated similar capabilities into their type systems, we can get most of it, even if we don't get access to the full package.

What languages are you thinking of that are like Rust but GCed? Most GCed languages don't compile to native binaries.

> Servlets are not in standard library (and it's not even library, it's a specification). Standard Java has HTTPURLConnection which is sometimes used and com.sun.net.httpserver which is not used by anyone. Spring is not in standard library either.

You're arguing against a strawman. These things are not in the standard library, but the ecosystem builds around them, and there are published JSRs that define the interfaces for foundational libraries (including both servlets and DI - of which Spring is just one of many compatible implementations).

No-one's arguing that Rust should have a web framework in the language standard library (I hope). But there should be one or more established options that the rest of the ecosystem knows about and interoperates with.

Popularity among whom? The hobbyists? I program professionally with Rust and that entails a lot of web development. Actix-web remains the most comprehensive, vetted solution.

You can't compare a general use networking server such as hyper with actix-web. Hyper is used for a much broader range of scenarios than just web development.

I truly hope that programmers continue to broaden the ecosystem, but progress has been slow.

Haskell's an old language, pushing 30 years now... Rust is still a relatively young technology. There are lots of improvements that could be built but only a handful of people to build them.

I am very curious about what you think about Rust in Action https://www.manning.com/books/rust-in-action?a_aid=rust&a_bi.... It wont describe higher level patterns, but does walk you through dozens of example programs. Projects include:

  - a CPU emulator
  - a fully functional NTP client
  - a skeleton grep implementation
  - how decimal numbers are represented in Rust
  - developing your own format for representing numbers
  - a memory scanner so you can learn how game cheaters cheat
  - handling UNIX signals
  - inspecting binary files for hidden patterns
  - an OS kernel + bootloader
  - an L-Systems implementation

Sometimes performance matters. At my previous company we settled on a Rust solution for one component (ingesting analytics data) after cycling through python and node prototypes that were just too slow (we had 100+ GB of data to process, and the node.js app was taking 15 minutes to process one 500mb file).

And once the data processing code was in Rust, it made sense to have the endpoint that collected the data in Rust too. It would probably have been possible to optimise the node/python versions. But it was easier to write it in Rust that is designed for these high-performance scenarios.

An unexpected bonus was just how reliable our Rust code turned out to be. I'd definitely consider Rust for non-performance critical code on that basis.

It’s not always about performance. Memory usage matters too. And reliability. We’ve heard all of these things from folks switching.

Performance is the tip of the value proposition iceberg for Rust.

I still think web applications massively out-scale mobile apps. The majority of software written is not general purpose consumer level "shink wrap" apps and never was.

Still, a very large portion of mobile apps are connecting to some back end service. I think I have exactly one app that stores it's data locally without a server connection (not counting games).

On the contrary, a number of people are shipping Rust libraries in their apps today.

Mobile apps might use APIs too - it means Rust on the server-side.

It doesn't mean the job is not important. It just means it's a different job from the other job titles which have existed for hundreds of years in the physical domain.

Programming is more like being a lawyer than engineering. But let's stop making analogies to other professions and just call it what it is: programming.

Whether they have the chops or not, the Architect role has little to no skin in the game. The half-life for their knowledge of the system is on the order of a year, and it's a role you want some longevity in.

I've had better luck splitting architecture up between three or five leads (not four).

I agree that the snippet you gave is ugly, but I also think that it's not really the most straightforward way to right it. Any time the type that you're collecting into isn't inferred, you're free to define a binding and just type annotate it. Also, the lambda you gave is not defined in the straightforward way I think most people would define it. Putting those together, you get something like this:

``` let vec: Vec<_> = v.iter().map(|pair| pair.0).collect(); ```

I don't think that's really _that_ ugly. Yes, the pithy Python example you gave is simpler, but by the same token, the assembly you would write to achieve this makes the Rust look really simple. If you're going to try to write efficient code in a systems language like Rust, you're going to need to express things more precisely than you would in a scripting language like Python.

Readability is very often nothing else but habit - code which looks like code you've seen often enough looks well. Case in point: The first example is just gibberish to me and I needed the second one to decipher it.

Also, I would write the second example different:

  let r: Vec<_> = v.iter().map(|(x,_)| x).collect();

In my opinion that's superior in readability to both of your examples, but probably also only because I'm used to it.

These all seem like small personal preferences to me, which are entirely valid; I don't think it's possible for a language to have a syntax that pleases everyone. But the comment I was responding to described Rust as having an "awful readability problem", and I don't really see that being described here. In particular, the comment I was responding to described Java as having "stellar readability", so mentioning the generic syntax of Rust really surprises me. Is `Foo<? extends Bar>` really so much better than `Foo<T: Bar>`?

PL/I has done it, famously, and just as famously the language has turned out horribly misdesigned and complex, and it also has missed out on most new ideas. (Still in use though.)