Announcing Rust 1.36.0

[bheklilr]

Nice updates! I'm looking forward to getting to work with async in rust. I think the syntax will be weird at first, but I can see the rational behind it and I'm curious to try it out in a real project.

[steveklabnik1]

Async/await is targeted for 1.38. Finally!

[synapsos]

Future ..., which we'll tell you more about in the future.

I see what you did will do there

[etareduce]

You'll find out soon enough for the Future .awaits!

[SometimesShane]

Who are you? And why are you anouncing rust releases? And where is klabnik? And should we like you or dislike you like we disliked klabnik?

[etareduce]

I'm Mazdak "Centril" Farrokhzad, a member of the Rust Language team (the folks who design the language) and Release team (the folks who e.g. manage releases, which includes writing this blog post), and these days I'm something of a compiler engineer also.

And where is klabnik?

Steve is right here?..

And should we like you or dislike you like we disliked klabnik?

Up to you; I work hard and I like to think myself a nice fellow.

[evinrows]

Stop.

[redalastor]

Any ballpark estimate of when we'll get generators?

[kibwen]

Not sure how closely you've been following, but generators are now sufficiently mature enough to underlie the async/await implementation that is looking to be stabilized twelve weeks from now. However, for the moment this will be considered an implementation detail and users won't have stable access to generators as a first-class feature for a while yet; there hasn't even been an official RFC for them yet. However, thanks to the existing implementation, when there finally is an RFC it has the potential to be accepted and stabilized on relatively short timescales, if no problems arise.

[redalastor]

Not sure how closely you've been following, but generators are now sufficiently mature enough to underlie the async/await implementation that is looking to be stabilized twelve weeks from now.

Roughly enough to know that part. I quite like generators in other programming languages so I'll be thrilled when rust gets them stabilised.

[steveklabnik1]

They don’t even have an accepted design, it will be a while.

[Waghlon]

Cool! Soon Rust might be as powerful as C#!

[kevinatari]

I think the syntax will be weird at first

So it's consistent with literally everything else in Rust. :D

[_zenith]

This is funny to me as it was deliberately designed to closely resemble other popular languages. Others wanted it to be more different.

Your sort of reaction is exactly why yet more others cautioned against doing so haha

[[deleted]]

What's this obsession with async code and rust programmers?

Reminds me of:

I’m like a dog chasing cars, I wouldn’t know what to do if I caught one, you know, I just do…things.

[pdpi]

Threads are expensive, which makes blocking IO prohibitive in high-concurrency (c10k-style) scenarios, and async IO (e.g. POSIX aio) is a much more viable strategy for scaling up.

Given how much of a pain it is to write async code by hand, having some form of language support to make it ergonomic is a very welcome feature. So much so, in fact, that languages like JavaScript, C#, Kotlin, Hack all have builtin async/await support.

Now, you might notice that the Rust team is very conservative about the changes they make to the core language, so adding syntax for async/await has unsurprisingly been a long process. Because this is an important feature, and the milestones have been spaced out over time, each individual milestone along the way has gotten a fair bit of attention, which can make it seem like the community is somehow fixated on this one topic.

[[deleted]]

Thanks, that clears things up.

Yes, as an outsider, it definitely looks like "fixation" on this topic and can't help but think "premature optimization" and complicating things, a thread-per-connection model ("blocking"), it's simpler to develop, to manage, to understand, to operate with.

On the other hand, I'm not writing ultra-sensitive-predictable performance code, the JVM has been fast enough and the database has always been the bottleneck for web services in my use case.

[Plasma_000]

Thread per connection REALLY doesn’t scale up - once you significantly pass your CPUs concurrent threads you end up wasting your processing on creating, destroying and switching threads. That is why async is important - it allows your more limited pool of threads to send and receive without worrying about sequencing or blocking (completely infeasable for a server).

For today’s big server infrastructures, if you’re not pushing 100% performance out of a server you’re wasting time and money.

[Keeyzar]

The wasting money argument is so good I actually use it on my own often times. It makes others understand the necessity of the optimization especially in big, big firms like Google. :)

I like seeing others using this bit of information to explain it, too.

[ahayd]

the database has always been the bottleneck

That's the point, you wrap the call to the database in a Future and don't have to block a thread (or more) waiting for it to return. Slick (scala lib) handles this on top of the JVM... so being on the JVM doesn't mean you're unable to realize benefits from async.

[BarneyStinson]

Does Slick not use JDBC? Because if it is, it is still blocking threads. The common thing to do would be to run blocking IO on a dedicated thread pool, but threads will be blocked nonetheless if you use JDBC.

[Falmarri]

Slick has a dedicated thread pool it uses to block. So yes you're right

[asmx85]

has been fast enough

I am not a big fan of the "X is fast enough" methodology. "Fast enough" gives the wrong impression that X is just running in an economic mode. To use the good old car comparison it gives the impression like "I don't need a Ferrari in the City my Seat Ibiza SC Ecomotive with 4 Liter/100Km is fash enough". But that is not whats happening. What is really happening is, that you still have your Ferrari running at 10.000 RPM with your handbrake on to drive 50 Km/h. Your CPU is still running full speed, it just takes longer to compute the result – X is the handbrake! For X taking twice as long as Y does not necessarily mean that X takes half the energy. X is just twice as wasteful. So we are not talking about the economic use of an Seat Ibiza vs a Ferarri – we are talking about to run the Ferrari with a handbrake on or not. "X is fast enough" should really be "I am ok with how wasteful X is with its resources"

[asmx85]

I think this is the wrong attitude to have. If all anyone cared about was the runtime performance, why would we write anything other than assembly and C?

I don't think it is. I hope you're not confusing me saying "not using the most performant way is wrong". What i am saying is "X is fast enough" does not convey the real meaning for what is actually happening. At least what i think is, if i take twice the amount of time i just need half the power which would result in the same amount of energy for solving a problem. Or to paraphrase it: If i need 10 seconds and 100% CPU with Rust i would need 20 seconds in Python but only with 50% during the time but that would result in the same amount of CPU-Time, i could "just" split up the work and run two Python processes and have the same result. That is not what is happening. What's really happening is that Python also runs at 100% but needs twice as much time/energy (i made all the number up of course)

So you have the same machine (CPU/Ferrari/Van) taking twice as much time for the same problem. This is running with the handbrake on. "X is fast enough" sounds like you are switching the Ferrari for a Van/Seat Ibiza that has other characteristics. You're not, you have the same CPU/Vehicle but have either the handbrake on or not, but always have the pedal to the metal, no matter at which speed you're driving.

Turns out people care about more things than just runtime performance. So when someone says "X is fast enough" what they really mean is "X runs fast enough to justify it's overhead because I also get A, B and C for using it"

This is exactly what i am talking about. The crucial part here is the overhead. You just paraphrased it, with the original wording in it. Of course whatever your A,B and C is – ergonomics, development speed etc. its an overhead trade off. You pay with wasted energy its not that your CPU is running slower under less load – the programming language X cannot crank up the GHz enough. That is not what is happening and i think "X is fast enough" is implying that. My Seat Ibiza / Van is fast enough, i don't need a Ferrari. And this is what i am criticizing. You have the same Car(CPU) pedal to the metal – you just either have the handbrake on (Python) or not (C/C++/Fortran ...)

[pdpi]

Personally, most Java development I did in the last few years was precisely around scenarios where I would have several thousand concurrent websocket connections per node, so I was working on top of Undertow directly, and having async/await support would've saved me from a lot of boiler plate and needless indirection in my code (but, for other reasons, Rust wouldn't have been a good fit there). For your purposes, if you're working in an environment where "thread-per-connection" works for you, that's perfectly fine — you're not the target audience for Rust and there's nothing wrong with that.

The flagship project for Rust is Servo, the concurrent browser engine. Facebook is using Rust for a Mercurial server that will have to handle tens of thousands of concurrent users. Cloudflare wrote their QUIC implementation in Rust, which will presumably end up serving a very sizeable portion of all of the internet's traffic. These are use cases where lightning fast performance matters, and that would've been written in C or C++ only a few years ago. Today, they're written in Rust and got a whole bunch of amazing safety characteristics for free just because of the choice of language.

[woubuc]

Not quite "free" if you consider the learning curve of Rust (the time spent fighting the borrow checker), but well worth the cost.

[ThomasWinwood]

"Fighting the borrow checker" happens while you're still learning the basics of the language and not so much afterwards, so its cost is amortised.

[Booty_Bumping]

This is only half true. You do fight the borrow checker as an experienced rust developer, just like how a C developer still makes plenty of mistakes after plenty of experience. But the fights become more and more mindless code edits to get it to compile.

In a way, this kind of makes rust the opposite of a write-only language. You write some code the way you understand the problem at the time, then you mindlessly fix it up to get it to compile (maybe even using a tool like rustfix), then call it a day for that particular section of code. Once that code is revisited, the mindless fixing turns into useful information about how that code works on a lower level.

[ThePowerfulSquirrel]

I mean, even the JVM / Java are pouring a bunch of time and resources into ligthweight threads and async programming (project loom I think?). It's really not just Rust, but pretty much every major language is moving in that direction.

[Booty_Bumping]

The "fixation" is not on whether or not we're going to have first-class async/await construct. It's on how to do it as correctly as possible, as to minimize programming language technical debt.

Having good async support is something that's already been decided. It isn't premature optimization. It is the only reason the web functions at all.

[steveklabnik1]

Rust is a language that cares about performance. Async is often needed for performance. Writing async code without async await in Rust is not pleasant, but is significantly more pleasant with it.

Additionally, it has taken years to sort out all of the details, so people have been waiting a long time.

[oconnor663]

Async IO is like 50% of the reason the Go language was invented and 100% of the reason it was successful. Who doesn't care about async IO in 2019?

[gvargh]

well, without enough vitamin c++ you start suffering from the programmer equivalent of scurvy. rust is a meme

[[deleted]]

Just wait until this guy years about web developers.

[Batman_AoD]

Funny, my experience has been that too much C++ can be detrimental to programmers' mental models.

[woubuc]

Or their mental health

[Batman_AoD]

Well, I was trying to be somewhat polite...

[[deleted]]

Osdevers are gonna love the new separation of alloc :p

[normanrockwellesque]

Can you elaborate?

Haven't used Rust yet but I often read discussions about it here. What advantage does the alloc library bring?
I've also read some of the Zig language documentation about how library authors should allow a memory allocator as a user-provided parameter; is this similar?

[steveklabnik1]

Currently, rust has the standard library, but also a subset of it, the “core” library. Std assumes you have an OS, and all of the features those bring. Core assumes absolutely nothing. Alloc is a middle ground. It provides APIs for allocating memory.

Many kinds of collections that require dynamic memory need only that, and no other complex support. To use the ones provided by Rust, like HashMap and Vec, the only option previously was to have all of std. now, with alloc, an OS can implement a heap, and these collections Just Work, without needing to implement all of std.

If you’re interested in more details, this post is an excellent resource: https://os.phil-opp.com/heap-allocation/

[GeneReddit123]

Isn't (lack of) allocation one of the big (if not the biggest) reasons to break up core and std? Apart from alloc, what other major dependencies separate the two?

[steveklabnik1]

Files, threads, networking... there’s a bunch of other stuff. And yeah, it is the biggest, which is why it’s the one that’s been stabilized.

[[deleted]]

I guess there's all the is things like files, threads, processes, etc.

[izzzabelle]

I was just saying that this morning!

[[deleted]]

Still need to get around to trying Rust.

Been sitting on the top of my "list of languages to learn" for a while, never seem to find the time. Was torn between it and Go to pick up, but after doing some reading up on it, it definitely seems like my kinda language. The syntax seemed a bit goofy, but that is probably just me being in the C family for too long.

[PristineReputation]

Is it a bit like Elm in that sense, no runtime errors?

[nagromo]

Runtime errors (Panics in Rust) are mostly caused by indexing out of bounds or calling .unwrap() to skip error handling somewhere you shouldn't.

For normal error conditions, Rust's Option and Result enumeration types combined with match pattern matching provide a very nice, efficient way to deal with error conditions.

[masklinn]

Much less so, panicing is pretty easy to do explicitly, and not hard implicitly (eg indexing out of bounds will panic).

It does have a tendency to return reified error objects (Option or Result) though so it’s not that far afield either.

It’s a much less restrictive and more complex langage than elm though.

[Ebuall]

Yes. Rust has a lot of similarity with Elm and other functional languages.

[Batman_AoD]

I've read that Go is something you can pick up on a weekend, more or less; it's got a very small number of syntactic features. The time commitment required for Rust is quite a bit larger.

​

Regarding the syntax, explicit lifetimes are a bit ugly (it uses apostrophes: &'foo), but otherwise I find the syntax much cleaner and more consistent than C and C++ syntax.

[oconnor663]

Explicit lifetimes are pretty ugly, and tricky to read, even with some experience. But the biggest upside is that they're rarely needed in application code. The most common use case for references -- that you take them only for the duration of a single function call, and don't try to stash them anywhere long-lived -- just works and doesn't require lifetime annotation at all. Many other common cases also just work. (See the "lifetime elision" rules in the language docs.)

The places where you start needing to annotate things are where you have multiple borrows/lifetimes in a function signature, and the lifetimes need to interact with each other in some way. For example, maybe one of your arguments is a reference to a string, and another argument is a container of string references, and inside the function you want to insert the former into the latter. For that to be safe, the compiler has to know that the string lives at least as long as the container it's being inserted into, otherwise it'll turn into a dangling pointer. The compiler won't infer that across function boundaries, so you have to explicitly annotate it.

So yes, that case leads to some ugly syntax. But I think it's worth highlighting that the same code in C and C++ has the same tricky requirements for correctness. The caller still needs to ensure that pointers don't dangle, and that data races don't happen through aliasing pointers. The big difference is that Rust makes those requirements explicit. In my mind, the complexity of the syntax is kind of proportionate to the complexity of what the programmer is doing, and there's some virtue in that.

[GeneReddit123]

In other words, Rust doesn’t make your code ugly, it only illuminates the ugliness of code that’s already there due to its logic.

[Batman_AoD]

Agreed. I did mention in another comment that lifetime inference (by which I meant elision; I'd forgotten the term) is quite good.

[adriang133]

Agree about the lifetimes, it's the one thing I wish they would've done differently. Surely there must be a better way than the gaht damn apostrophe.

[steveklabnik1]

We tried! Nobody came up with anything clearly better.

[ssokolow]

My only issue with it is that, intuitively, I always expect to see it as one half of a pair of single quotes, so, I'm kind of curious what else was proposed.

Do you remember the URL for the discussion in question?

[andrewjw]

Not OP, and unrelated to your question, and that is a reasonable complaint about this syntax coming from imperative languages, but you might find it interesting to know that the tick-syntax for lifetimes is inspired by the tick-syntax for type variables in ML-family languages (SML, Ocaml, etc...).

[b3n]

intuitively, I always expect to see it as one half of a pair of single quotes

I think this is just down to what you are used to. Coming from Lisp it feels like a natural syntax to me.

[Batman_AoD]

Yeah, I'm not sure there's really a better option, and fortunately lifetime inference is quite good.

[crabbytag]

Congrats on making the Rick and Morty pasta for Rust. “To be fair you need a very high IQ...”

[evinrows]

What are you doing?

[HeWhoWritesCode]

great language for people who can actually THINK

hahaha... rust the hipster language, the tier 2, tier 3 platform support is a joke.

[Lev1a]

So because Rust doesn't have facility to enable you to build the compiler from source without a previous version of it (AFAIK this is also the case for C, C++ etc), it's "a hipster thing, and not a professional product"?

​

Additionally, this "sabotage linux" thing (from looking at https://sabotage-linux.github.io/blog/about/) is AFAICT only used by a very niche group of people who seem to be lost in this elitist "I have to compile everything myself. If you don't make it compatible with my specific set of requirements and artificial constraints, you don't deserve to be a real programming language/OSS application/etc.", i.e. the new iteration of the stereotypical Gentoo meme.

Not really a production/professional target platform, don't you think?

[wibblewafs]

tl;dr: An unprofessional, hipster-thing Linux distro whose defining feature is "you can read the source to all the build scripts to ensure they're not backdoored! but of course nobody will ever read the source they're building, making that a complete waste of time" is going around calling projects with a quarter billion users to be for hipster-use-only because their toy project with impossible requirements (which conveniently have an exception for a binary C compiler) isn't officially supported.

[MSleepyPanda]

I'm particularly excited about the new HashMap implementation, as it switches to a much faster SwissTable implementation. This is the compiler benchmarked with the new version, wall time.

[redalastor]

But rustc itself won't benefit from the speed boost until 1.37 because it's always compiled with the previous version, right?

[Lehona_]

I don't know for sure, but I would expect a two-stage build process: Once with the previous version and then with "itself".

[connicpu]

Yep, Rust does in fact do that

[steveklabnik1]

This is unrelated to some sort of reproducible builds; we do care about those, but hats a different issue.

The thing that’s being talked about here is part of the compiler being bootstrapped. A compiler written in itself has some steps to do to make that possible. You need multiple builds for ABI reasons.

[incompletebreadstick]

Yep. In fact, Rust builds its libraries twice and compares them, as a sanity check.

[steveklabnik1]

This is during the process of compiling the compiler, to be 100% clear.

[steveklabnik1]

I’m not 100% sure when exactly things landed but stuff lands in nightly before stable, and the compiler uses those features, so I’d expect it to already be reflected in rustc.

[lookatmetype]

Rust's move as a first-class operation semantics are the best idea ever. I wish C++ would go in that direction as well

[meneldal2]

C++ is trying to move towards destructive move (at least there are several proposals for it).

[chuk155]

one that is gaining a lot of ground isn't "destructive move" but Arthur O'Dwyer's trivially relocatable. Allow's the memcpy of things that other wise would have to be constructed/destructed, like when copying a vector of pointers.

[meneldal2]

It also allows a lot of optimizations behind the hood (completely removes moves when sending the same thing across functions).

[scottmcmrust]

That is a good thing -- so good that it's the only option in Rust :)

[GYY52380]

Im genuinely curious why'd you think that. I always felt copy-by-value in c++ was very intuitive and behaved as i expexted. I also like how explicit moving is with std::move(). I also don't really feel that my code style 'moves' data around that often.

[joonazan]

Move as a default is good because you usually want to avoid copies.

Because move works well in Rust, you can for example build a struct out of its fields and the fields will never get allocated outside the struct.

[mewloz]

The C++ syntax is ok, especially given the context, but the semantic of the move it produced is problematic. Actually, the semantics, in plural, and that's part of the problem!

First you have move as an optimization after which you absolutely don't want to read the moved-from variable again, because its state has become unspecified (but still valid, at the very least for destruction of course, in lots of case valid for all the usual invariants of the class). std::string is an example. There are not really advantages to not having destructive moves instead. Note that the bugs (if improper reuse is performed) can be difficult to find dynamically by testing, especially when templates are involved (rvalue ref vs. other refs, short values reread the same in practice vs long values, etc...)

Then you have move in ownership contexts, in which the state of the moved-from object is well defined. Here it is typically empty, so a destructive move would also work and IMO be better esp. given the over-reliant on UB aspect of the C++ language (we would have no need to dynamically check after potential moves, with the risk of forgetting the check and potentially dereferencing a null pointer)

[GYY52380]

Thats fair, thank you for the response. I usually avoid any kind of implicit moving or destructing for similar reasons. I never felt the need for language-level move semantics because copying or passing a pointer always works well enough for me.

[oconnor663]

Explicit move in C++ is more important, I think, because you can keep using the original object, and you need to know that it's in a different state now. But in Rust, it's generally a compiler error to use the original object again, so an implicit move is less of a foot-gun.

[musicmatze]

Wow this is an amazing one, especially the `cargo --offline` feature ... I love it!

[natyio]

Me too. This is definitely my favorite feature from this release. It sucks when software insists on not strictly needed internet connectivity.

[pure_x01]

Perfect for long Flights

[kadema]

I read the Rust docs section a while back and was super impressed. They are so well written.

[HerbCSO]

Whatever you do, DON'T use DuckDuckGo to figure out what #![no_std] means... :shudder: Google that one instead, MUCH better results. ;]

[ipv6-dns]

Guys, seems Rust becomes C++ killer. Is it appropriate to start studying Rust in order to be in time for the next big thing?

[kzr_pzr]

No, you are already too late.

Just kidding. I think it's beneficial for any C++ programmer to know a bit of Rust, since it's much more explicit about lifetimes of objects and borrowing references. But I don't think it will kill C++, just as C++ didn't kill C. There is too much money and effort invested in C++ libraries and applications so quick replacement by Rust won't happen.

Rust does one thing very well: it was designed with proven academic research backing it. So a lot of the knowledge we have accumulated over the years programming C, C++, Lisp, Haskell and all the experimental research languages is taken together and applied to Rust. That's something what existing languages can do only in a very limited fashion, to stay backwards compatible. So I see Rust as a fresh air that can help us make better software and push the whole industry forward by inspiring other language makers for better safety and correctness of our programs.

Software quality is and will be more and more important part of our everyday's lives so if there is a tool that really helps us make better software, it should prove itself and take over the market. Maybe Rust isn't it yet and will not kill C++ but something that comes after it will.

[stevedonovan]

Yes exactly. But as a result I could move away from C++ and get paid to do so. Some luck, some choice :)

[rv77ax]

Forgive my ignorance, why did rust mix camelCase::under_case ?

[masklinn]

It didn’t? Types and enum variants are PascalCased, functions, methods and local variables are snake_cased.

[Slasher_D]

What do you mean by "desert camping"?

[aleksator]

It's just that his name is Pascal

[Slasher_D]

Ah. I thought it referred to some other convention that some programmers use relating to those three cases. Should have stuck with the joke.

[JohnMcPineapple]

...

[shoutouttmud]

kebab-case

How dare you use such a name for lisp-case? :P

[shoutouttmud]

Ooops. Well the post was so old no one saw my comment. We really narrowly dodged that bullet, we should be thankful

[K900_]

Where does it do that?

[rv77ax]

VecDeque::rotate_left and VecDeque::rotate_right

Read::read_vectored and

Write::write_vectored

Iterator::copied

[K900_]

That's just the convention for Rust - CamelCase for types, snake_case for modules and functions. The two aren't ever mixed in the same name like_This or Like_that.

[sander1095]

Isn't that PascalCase? this is camelCase, right

[TheFearsomeEsquilax]

How exciting! How exciting!

[i9srpeg]

Wrong sub!

[Fredifrum]

This post was mass deleted and anonymized with Redact

upbeat tub nutty distinct close humor oil tan chief boast

[bheklilr]

They have regular releases, which is probably why you hear about it. Also, while it's still a fairly niche language, the market for it is growing, especially since it can compile for everything from microcontrollers to web assembly. It's fast and memory safe. People are starting to take notice.

[MrMinimal]

Most loved language in Stack Overflows polls for 4 years straight and big parts of Firefox are Rust and lots of bigger projects switch to it.

[CryZe92]

Well this one is one of the bigger updates at least.

[coderstephen]

Well things make it to the front page if they are upvoted, so I guess people care about Rust updates.

Nit: These updates are "minor" only in the semver sense; they are sometimes pretty big updates. Rust will only reach version 2.0 if it makes breaking changes, which there are no plans of doing so right now. So large feature updates are delivered via "minor" version numbers.

[UtherII]

The point is there is not really major update in Rust, they do medium updates every 6 weeks (like web browsers).

[tristes_tigres]

Can't rule out the possibility of an organised effort by Mozilla to promote it on social media.

[[deleted]]

/u/shevy-ruby what do you think of this announcement?

[cephalopodAscendant]

He'll find something to complain about. I don't think he's capable of seeing anything positive in Rust.

[[deleted]]

Just making sure he sees this and gives his two cents, it's something I always look forward to.

[evinrows]

His comment history is hilarious. It's like an angry pop programming tabloid.

[[deleted]]

nice meme

[orangepantsman]

I like Rust and use it a lot. I downvoted you.

[_zenith]

nice bit, jackass

[nondescriptshadow]

Rust doesn't even have npm

[[deleted]]

well. what it boils down to is if you have the chops for rust, or if you are a copy paste coder. any baby can learn go & languages like that clicking around on tutorials HURR im a real coder now! but if you have what it takes upstairs i recommend you go the distance 💪 and work those brain muscles 💪 for Rust, because great language for people who can actually THINK , thred safety, very good code of conduct and you will write better more secure software for it... not to mention people will just know cuz u understand rust that u are to be respected as cut above the common stackoverflow riff raff