Rust 1.40

https://blog.rust-lang.org/2019/12/19/Rust-1.40.0.html

by mark-simulacrum • 7 years ago

430 150 7 years ago

blog.rust-lang.org

xiphias2• 7 years ago

let x = Bar::Variant { a: 42 }; //~ ERROR

Of course it's an error, as Bar doesn't have a field called ,,a''

mark-simulacrum• 7 years ago

Thanks for pointing this out! Unfortunately, unlike most of our docs we don't yet have testing in place for the code examples on the blog. I've just pushed up a fix though so once that propagates this should be fixed.

penagwin• 7 years ago

I don't personally use Rust (yet) but I love seeing its progress!

Congrats to everyone who has been contributing to Rust, it's definitely moving the language forward!

moksly• 7 years ago

There hasn’t been a single Rust job posting in the entire region of Denmark where I live in 2019, so it’s probably fair to say that almost no one uses it.

The progress is still cool though.

steveklabnik10• 7 years ago

Facebook, Amazon, Google, Microsoft, Dropbox, Cloudflare... it’s still early days overall but there is certainly a significant amount of usage.

jeltz• 7 years ago

I am not sure that there are any Rust job postings in Sweden either, but I know several people using it on their jobs anyway, e.g. people recruited as C++ developers who work in Rust. I think it is hard to see any trends in smaller languages from job postings since a lot of recruitment is done internally and through contacts.

nicklauri• 7 years ago

The main reason is many companies have a lot of C/C++ devs or other devs learned Rust, so they don't have to hire new Rust programmer. There are many places using Rust, you should check this out: https://www.rust-lang.org/production/users

Someone12344• 7 years ago

It is young by language standards, but it has considerable success considering it isn't even 10 years old yet.

Plus there isn't really anything else in the market that directly competes with it outside of what it tries to replace (C/C++).

For example: https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-win...

spand• 7 years ago

Not affiliated but there is at least one posting here https://concordium.com/careers/

AsyncAwait2• 7 years ago

Is Denmark on the cutting edge of these sorts of things? Many countries have enterprise companies that are heavily invested in Java/C# and maybe 3 startups using a bit of Go/Elixir in some places, but that's about it, it's not specific to Rust.

MassiveOwl• 7 years ago

Weird, I write in Go, and based on the number of posts about Rust, i'd assumed that it was gaining traction

jahaja• 7 years ago

Rust is a pretty niched language trying to replace C++ and similar that are quite slow moving, so it's gonna take time. Most jobs are after all related to web/services where Rust's strong points aren't as relevant.

vardump2• 7 years ago

There hasn’t been a single C++ job posting in the entire region of where I live in 1989, so it’s probably fair to say that almost no one uses it.

To me, Rust "feels" like one of those languages that will stealthily become very important at least in certain segments where security, performance, C ABI compatibility (dll/so/dylib) and zero runtime are required.

kibwen6• 7 years ago

I don't suppose I have any listings for Rust jobs in Denmark specifically, but for remote Rust jobs you could try checking out our regular jobs thread on /r/rust. We post a new one with each Rust release, so the current one ( https://www.reddit.com/r/rust/comments/ecxd62/official_rrust... ) will take time to accumulate postings, so for now I'd suggest perusing last cycle's thread ( https://www.reddit.com/r/rust/comments/dvxw6u/official_rrust... ).

gameswithgo• 7 years ago

There was one in late 2018, I applied but it was too difficult from them to hire an American!

bytematic• 7 years ago

I don't know about that, Microsoft security analysis is in Rust, Google wrote an OS in rust, Mozilla firefox is mid-rewrite in rust, Linux is accepting rust work

halffullbrain• 7 years ago

Are you looking for Rust employment in Denmark?

gfs• 7 years ago

Can somebody elaborate on the #[non_exhaustive] use case inside a private struct? Wouldn't a separate crate not be able to use the struct if it was in another crate?

Sharlin• 7 years ago

I think `Foo` and `Bar` are supposed to be public, otherwise the example doesn't make sense.

wtetzner2• 7 years ago

The point is that the struct is public, and the fields are public, but users of the crate cannot directly create a new instance of the struct (without going through a function call in the module). This allows users to access the struct fields, but they cannot do any operations that would break if a new field is introduced.

Waterluvian3• 7 years ago

Wonderful! Any further news on evolution of the Rust Language Server? I'm still hoping ~Santa~ Annual Gift Man will bring me a considerably crisper, more accurate IDE-like experience to my favourite non-Intellij editor.

steveklabnik10• 7 years ago

Have you seen rust-analyzer? That’s effectively it.

Waterluvian3• 7 years ago

No I don't think I was aware of this. I've been playing with VSCode -> RLS Plugin -> RLS. It looks like this is not that, so I'm pretty excited to check it out.

Thanks for sharing!

kire456• 7 years ago

The #[non_exhaustive] feature makes me unreasonably happy. It is a problem I hadn't even realized might occur, and the solution is very elegant, forcing depending code to be sufficiently general.

est314• 7 years ago

For enums at least, I'm not recommending it's use (yet), as with _Nonexhaustive you can make sure you caught all cases internally. Matching on _Nonexhaustive as a user of the library is of course a bad idea. There've been proposals to a lint like #[deny(reachable)] to make such checks possible for #[non_exhaustive] as well but it seems that nothing has happened yet: https://github.com/rust-lang/rust/issues/44109#issuecomment-...

kibwen6• 7 years ago

For enums at least, I'm not recommending it's use (yet), as with _Nonexhaustive you can make sure you caught all cases internally.

I don't think this is necessary. The attribute in question is applied to an enum variant, and that variant's constructor is then given only crate-wide visibility. This looks to be simply a compiler-enforced codification of the pattern you're describing.

glandium• 7 years ago

How about using #[cfg_attr(test, non_exhaustive]?

csande172• 7 years ago

I'm a little confused by the decision to make breaking changes to the borrow checker in Rust 2015. Wasn't the whole point of Rust 2015 to allow old code that wasn't compatible with 2018's changes to compile? If keeping strict Rust 2015 source-compatibility was too burdensome for the compiler maintainers, why not just remove Rust 2015 entirely and tell everyone to use the auto-upgrader tools?

steveklabnik10• 7 years ago

The only reason that breaking changes were allowed to be made was that they fixed soundness issues.

kibwen6• 7 years ago

To elaborate, the original borrow checker that launched with Rust 1.0 had edge cases that could only be resolved with a drastically different analysis pipeline. As a result, it wasn't able to properly reject some patterns that were disallowed by the conceptual model. Over the course of several years this new analysis pipeline was developed and the borrow checker was rewritten to use it, which now properly rejects these patterns. But three years is plenty of time for code in the wild to begin relying on edge cases, so there's been a year-long deprecation cycle to warn anyone who might not have updated their code by now.

csomar2• 7 years ago

I thought these were real errors but Rust decided to give some time before breaking your code? Maybe someone else more seasoned can comment on this?

aaron_m042• 7 years ago

This may help: https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html

NieDzejkob2• 7 years ago

Woah, todo! is going to come in handy considering the wordiness of unimplemented!. However, weirdly enough, the documentation claims it has been stabilized in 1.39. Why is that?

steveklabnik10• 7 years ago

It’s just a bug. Would you like to file one or would you like me to?

NieDzejkob2• 7 years ago

I'll send a PR, one moment.

randyrand• 7 years ago

Using #[non_exhaustive] on enums is going to be general bad practice, just as many in c++ consider ‘default’ switch cases bad practice.

When a new state is added to an enum, we want the code to not compile so that we can fix all the places that need updating.

steveklabnik10• 7 years ago

Yes, that’s the trade off. Like all trade offs, it makes sense sometimes, but you’re right that it’s not to be used in most cases.

gdxhyrd• 7 years ago

Yeah, I don't like it at all.

Yes, some enums are intended to be expanded. Still, as long as something is a compile-time error, I don't care about having to update my code when I choose to upgrade compilers.

In fact, even if the enum is intended to be expanded, I prefer to hear about new features and changes on APIs I actually use in a given project. It allows me to review mu choices and many times in complex APIs there are new options or flags that are useful to know about and otherwise get ignored. It allows me to update all callers as needed.

I have heard too many times the backwards compatibility story in the C++ world and I never valued it for things that are errors rather than behavior changes. It makes the libraries and the language way too rigid and makes evolving it a pain.

As long as you don't change the meaning of code that compiles cleanly, feel free to change things.

If you really want to keep code compilable because you are doing a chance that you believe will be a PITA, you could always offer a (truly) automated tool.

cesarb• 7 years ago

Still, as long as something is a compile-time error, I don't care about having to update my code when I choose to upgrade compilers.

It's not just your code; it could be the code of any of your dependencies (or their dependencies, recursively). Besides, the Rust team does intend to keep older code compiling unchanged on newer releases of the Rust compiler, unless the breakage is caused by fixing a soundness hole.

The best example of a non-exhaustive enum, in my opinion, would be std::io::ErrorKind (https://doc.rust-lang.org/std/io/enum.ErrorKind.html). Several Rust releases ago, I added a new variant to that enum (the last one, UnexpectedEof, used by std::io::Read::read_exact - notice how that variant comes after "Other", which used to be the last one). If that enum were not non-exhaustive (non-exhaustive enums already existed since Rust 1.0, though using a doc-hidden trick instead of formal compiler support), I would not have been able to add that new variant, since it would risk breaking anything which matched on every variant of that enum.

elihu• 7 years ago

Perhaps Rust could add a #[exhaustive] pragma at the point where the enum is being pattern matched to over-ride the libary's #[non-exhaustive] pragma, for users that really do want their code not to compile when an enum is extended.

csomar2• 7 years ago

I agree. That's what Semver is for. If you are adding new variants to your enum that can break code for your dependents, then increment your version accordingly.

IshKebab• 7 years ago

Right but some enums are designed to allow new types to be added.

For example suppose you add another image format to the `image` library:

https://docs.rs/image/0.23.0-preview.0/image/enum.ImageForma...

What's more annoying - a major version bump every time you support a new format, or not being able to exhaustively match on all 10 formats?

Guvante• 7 years ago

That is why there are two versions available. The default matches the behavior you describe and is the default because for small projects it is the right decision.

However sometimes you are a dependency and you want to give up this restriction to gain the ability to add things without having to bump your major version number.

By far the most common example is error enums which don't necessarily need all of their downstream crates to handle every error, they likely are bucketing most of them anyway and non_exhaustive ensures they support that.

thayne• 7 years ago

The `Ordering` example given in the announcement shows another use-case. User code typically won't pattern match on that enum anyway, it will usually just be passed as an argument to atomic functions. And it may be desirable to add another type of ordering as rust's memory model evolves.

kibwen6• 7 years ago

Error enums are precisely the target for this attribute. Servo's URL parser is a great example, as it currently uses a dummy variant that is hidden from the documentation in order to discourage people from trying to exhaustively match over it: https://github.com/servo/rust-url/blob/7d2c9d6ceb3307a3fad4c...

bcrosby95• 7 years ago

Since the developer of a library has no insight into my application, they have no idea how important an exhaustive match is or isn't in any given piece of code I'm writing.

This is a decision library users should be making, not library writers.

kibwen6• 7 years ago

This ties into what I believe is going to be one of the biggest themes of programming language development in the 2020s: first-class language features that allows defensive libraries to make changes that don't cause breakage in downstream users. Right now I'd say Swift is the poster child of this movement; many of its language features are head-scratchers until you realize that they exist to keep applications compiling and on a clean upgrade path even when their dependencies are actively changing.

Of course, the trade-off is obviously that by choosing to make things continue to compile when something changes, you are no longer causing things to fail to compile when something changes. I'm uncertain how this tension will be resolved in the long run.

dilap• 7 years ago

I'd be curious to hear more about these Swift features.

(Context: used to do iOS dev w/ obj-c; haven't used Swift, but keeping an eye on it, mostly out of curiosity.)

breatheoften• 7 years ago

Its not a small change ... binary compatibility has essentially meant “c compatible” for the last several decades ... will any of the new languages currently attempting to implement a binary comparability model succeed in shifting this in a meaningful way?

littlestymaar2• 7 years ago

That's pretty surprising that they put so much effort into this kind of compatibility stuff when at the same time they make no effort in maintaining compatibility at the language level: every new release of Swift so far had been full of breaking changes that needed tons of work to update a library to.

lilyball• 7 years ago

Swift has a really good solution to this, which is an attribute @unknown that you put on the default case, and this attribute produces a warning if there are any known enum variants that would match this case. This way you're future-compatible but the warnings tell you when you need to revisit the code. I'm pretty disappointed that Rust didn't copy this.

Buttons840• 7 years ago

Can't you just do that with a catch all pattern match?

steveklabnik10• 7 years ago

This is a good idea for a lint!

cryptonector• 7 years ago

You need a wildcard match which allows you to fail... at run-time. I see what you mean.

Siecje• 7 years ago

Can you cross compile for another platform?

orf• 7 years ago

Yes: https://github.com/rust-embedded/cross

mamcx2• 7 years ago

I like the IDEA but the implementation is not the good one.

Instead, this is what will be elegant:

    pub enum SearchOption {
        Left,
        Full,
    }

    pub enum SearchOptionBeta:SearchOption {
        Rigth,
    }

Yep, extending struct and enums.

This mean MATCH touch "SearchOption" as the "stable" API and the inner crate touch SearchOptionBeta. When SearchOptionBeta need magic is that it match SearchOption too. Later is just a matter of replace one for the other.

And this is even useful for more than to stabilize certain fields or arms...

swsieber• 7 years ago

I'd personally do this:

  pub enum SearchOption {
      Left,
      Full,
      Beta(SearchOptionBeta),
  }

  #[non_exhaustive]
  pub enum SearchOptionBeta {
      Right
  }

mamcx2• 7 years ago

Yeah, this is how could be done with this, but also show why is a poor abstraction.

If enums were abled to be extended:

  match e: SearchOptionBeta {
   SearchOptionBeta:: Left, Rigth, Full
  }

jeffdavis2• 7 years ago

The continuing improvements to procedural macros are great!

I do a fair amount of integration with C, and the work the rust team is doing for procedural macros has helped a lot. Being able to use them in an extern blocks will surely help more.

Like many, I have a wish list that I complain about sometimes, but I feel bad about complaining because rust has done so much to improve my use case I don't know where to begin. I should write up a blog post about all of the difficulty I had, and how each release since around 1.28 has introduced features that solved these problems one by one.

To me, Rust/C interop is the killer feature. Not only is it a low-level language that can be used instead of C, it can also be used to extend C applications. I'm sure it was not easy to do this well, but what a great strategic decision by the rust team to spend the effort on it!

joshbenford89• 7 years ago

Can you recommend any good blog or tutorial on integrating C/Python and newer releases of Rust?

jeffdavis2• 7 years ago

I didn't use much except for the official docs (book and reference). Googling around shows some promising material.

Release notes are helpful -- when you see something added related to C, it's a strong hint to read about the new feature.

Macro features are important because rust has sophisticated macros and C macros are closer to text replacement. So when trying to emulate a C header, you need to do a lot of macro magic in rust sometimes.

Sorry that I don't have more to offer from personal experience.

calibas• 7 years ago

Here's a common Rust foreign function interface for Python, with quite a few examples:

https://crates.io/crates/pyo3

Here's the one for C:

https://crates.io/crates/libc

Rust 1.40

Related Stories