
Rust 1.43 - steveklabnik
https://blog.rust-lang.org/2020/04/23/Rust-1.43.0.html
======
steveklabnik
Hey folks, this is the first release after I wrote
[https://words.steveklabnik.com/how-often-does-rust-
change](https://words.steveklabnik.com/how-often-does-rust-change). We haven't
changed any real policy here, but the bit saying

> This release is fairly minor. There are no new major features. We have some
> new stabilized APIs, some compiler performance improvements, and a small
> macro-related feature. See the detailed release notes to learn about other
> changes not covered by this post.

is an attempt by me to maybe address this. We've historically said similar-ish
things, but I'm trying to be a bit more blunt about the magnitude of changes.
Any feedback on this would be useful!

~~~
andrewflnr
I think the key thing people worry about with regard to "churn" is "OMG, do I
have to update my code again?". Explicitly calling out that this release
doesn't really have any changes like that is good. I also think that's why the
ecosystem change is in fact a big deal. People seem to feel pressured to keep
up. Meanwhile I'm still not really sure what the consensus is, if any, on
which error handling library we're supposed to use... Anyway, it might also be
worth calling out somewhere that no, you don't have to follow the ecosystem
and the hip idioms super closely if you just want to get some work done (and
to the extent that's not true, making it so).

~~~
ChrisSD
Just to be clear, you never HAVE to update your code. Rust 1.0 code still
works just fine.

The consensus with error handling is that the limitations of std error trait
have now been sufficiently fixed so as to be usable without anything more. But
you can use a crate (like `thiserror`) to reduce boilerplate if you really
want to.

~~~
est31
> Just to be clear, you never HAVE to update your code. Rust 1.0 code still
> works just fine.

You have to update your dependencies though because every now and then,
changes lead to breaking builds. I have a codebase from 2015, last touched in
2016, and many dependencies failed to compile, some because of changes in the
language (those changes are only done to fix bugs but they still cause churn
to users), others because the openssl wrapper doesn't support newer natively
installed versions of openssl. It took me roughly an hour to fix all the
issues and it's only a few hundred lines.

Admittedly this is much much less effort than staying up with whatever the
currently hyped error handling library is. And C++ projects often need effort
to work on newer compilers as well because they invoke UB and the optimizer
changed and led to segfaults. Seen it with my own eyes.

~~~
csdreamer7
For someone new to Rust. What past changes in the language broke the
dependencies you used? Were they using the nightly branch?

~~~
edflsafoiewq
e: this is wrong

Dependencies can set lints to deny. When lints change, they might not compile
anymore.

(I think denying lints is a bad idea, just like -Werror)

~~~
steveklabnik
Doesn't cargo's behavior of capping lints prevent this?

~~~
edflsafoiewq
Yes, you're right. I thought I had seen this in dependencies, but I must have
been compiling something directly.

------
valera_rozuvan
If you are like me, and stick to Rust lang for about a year or so, you will
have a hard time going back to low level languages such as C. When you have
your errors caught at compile time - it's simply beautiful! Forget about
explicit memory freeing - and don't worry about memory management, it is
really predictable. Code will always have the same precise meaning across all
platforms. Hell yeah!

~~~
tiles
On the bright side, I definitely write safer C code now after wrapping my head
around Rust. I'd much rather have the compiler tracking lifetimes than my own
imagination though.

------
axegon_
Minor or not, this:

> You can now use associated constants on floats and integers directly, rather
> than having to import the module. That is, you can now write u32::MAX or
> f32::NAN with no use std::u32; or use std::f32;.

is neat! Awesome! Thanks!

~~~
kibwen
That's my RFC! Yes, it's great to be able to address such a curious (albeit
minor) historical wart from Rust 1.0. :) [https://github.com/rust-
lang/rfcs/blob/master/text/2700-asso...](https://github.com/rust-
lang/rfcs/blob/master/text/2700-associated-constants-on-ints.md)

------
giancarlostoro
I always check these announcements out wondering when Rocket will compile on
stable.

[https://github.com/SergioBenitez/Rocket/issues/19](https://github.com/SergioBenitez/Rocket/issues/19)

Anyone have any background on what's holding back proc_macro_hygiene and why
that's even a requirement of Rocket?

~~~
steveklabnik
[https://news.ycombinator.com/item?id=22609943](https://news.ycombinator.com/item?id=22609943)

~~~
giancarlostoro
Very insightful thank you, is it not possible for Rocket to rewrite some of
those if it's going to take a while before they're ready for Rust? Another
thought I had is... does Rust support conditional compilation? I haven't done
enough Rust to know but maybe they could do that for Stable instead...

~~~
steveklabnik
We do, and that’s part of what I meant in the comment by “dropped”; the first
one can’t be worked around, but the others could, in theory.

That said I’m not an expert on Rocket and don’t know what Sergio’s plan is
exactly.

~~~
giancarlostoro
Fair enough, out of curiosity are there other frameworks you have used or find
interesting?

~~~
steveklabnik
If I were to make a service today, I would probably start with Actix, or maybe
Warp. I don't think that this problem has really been _solved_ yet. I've taken
a few cracks at it myself over the years and am still not 100% happy, I dunno.

The last time I wrote something I just used raw hyper. I didn't need complex
routing though, if I did, that would have been an absolute pain. It was also a
read-only service so I didn't need auth or a lot of other stuff that's needed
in every real app.

~~~
giancarlostoro
I agree, the more I do web and look into web frameworks and the ones I like
the most, it feels like the nice ones take advantage of some form of syntatic
sugar capabilities of their respective languages such as annotations in C#,
metaprogramming in Kotlin/Kotor, decorators in Python and so on.

------
digikata
The added cargo env variable pointing to the path of generated binaries is a
nice quality of life fix. I think that was one of the first annoyances I ran
into with cargo and binaries. It was minor but was like a little splinter that
stood out from cargo's otherwise nicely integrated build and test
capabilities.

~~~
weiming
I've been using [https://docs.rs/assert_cmd/](https://docs.rs/assert_cmd/) for
this. (Helps spawn the binary and assert output.)

~~~
epage
Thamks for the call out! I'm excited by the new env var and need to consider
its impact on `assert_cmd`.

------
harikb
For a non-rust person's point of view, I assume a macro is something like a
super-pre-processor that helps keep the code concise. In the example below,
what portion is written ahead of time (by the person making the macro) and
what portion is the macro usage?

    
    
      macro_rules! mac_trait {
          ($i:item) => {
              trait T { $i }
          }
      }
      
      mac_trait! {
          fn foo() {}
      }
    

Is this making it easier to implement a trait? interface?

~~~
Koshkin
The looks of this makes me want to go back to Lisp.

~~~
simias
Rust's macros are unpleasant to write and debug but very nice to use. The
language is also much more expressive than C so I don't find myself needing to
(ab)use macros quite as often.

Of course lisp macros are on a different level but the languages are massively
different so it's not necessarily a super fair comparison.

~~~
Eikon
One issue with macros is that they are currently breaking most IDE
integrations.

------
Analemma_
I wonder if recency bias combined with the unusually large volume of major
changes in 2018 was responsible for Preston Carpenter's "I can't keep up with
Rust" post
([https://news.ycombinator.com/item?id=22818150](https://news.ycombinator.com/item?id=22818150))

~~~
greatgirl
I would say there is an argument to be made on both sides. On one hand rust is
only 10 years old with much less corporate backing than Go, but on the other
hand you have to be very careful with even small changes if you want the
language to be stable in the long run.

I can see why people are worried, and it's valid, but I also trust the devs
are making correct choices

~~~
majewsky
> rust [has] much less corporate backing than Go

I don't know if that statement is really justified. Sure, Google is a much
bigger and more influential company than Mozilla. But when taking the average
over the entire company, all-of-Google supports Go much less strongly than
all-of-Mozilla supports Rust, and I think that pretty much cancels each other
out the company size, so I would consider both langs to have roughly equal
corporate backing.

I think the actual difference is that Go has a much larger immediate audience
than Rust. Go appeals primarily to developers of web service backends, who are
coming from Ruby/Python/Perl/PHP and are looking for something faster and
statically typed. Rust OTOH initially mostly appealed to systems developers
looking for a better C/C++, although that audience has been steadily expanding
since then.

~~~
steveklabnik
Rust is also supported by more than Mozilla these days.

------
otikik
All those new features sound so ... unexciting.

I like that!

------
nevi-me
The primitive type inference is helpful, especially given the number of `val
as i32` conversions that one might encounter when doing arithmetic from
different crates. It however feels "magical", so I'm not sure of how I feel
about it.

Do the primitive type inferences also work when comparing i32 vs &i32, or even
better, &i32 vs &u64?

~~~
simias
I believe that this only works for literal type inference, i.e.:

    
    
        let a: f32 = 0.0;
        let b: f64 = 0.0;
        
        let this_works: f32 = &0.0 + 0.0;
        let this_doesnt: f32 = &a + b;
    

And that's a good thing IMO, implicit promotion rules in C are one of my least
favourite features of the language. It makes it so easy to write seemingly
innocuous code that's completely broken.

~~~
ridiculous_fish
What is &0.0 + 0? Adding a reference to a float to a float - is it being
automatically dereferenced?

~~~
steveklabnik
Yes, it is being automatically de-referenced.

------
kettro
The one feature I need on stable is inline assembly. It's something that
should not be sidelined to the nightly compiler, and makes Rust a harder sell
for the embedded world.

Yes, I know that I can just use .S files for my assembly, but sometimes I just
need to access a CSR.

~~~
steveklabnik
It’s closer than it’s ever been! There’s been a lot of renewed interest, with
an RFC and an implementation. We’ll see!

------
philonoist
Considering all the excitement here, I want to learn Rust. What is a good
resource to start with _if I didn 't program ever?_

~~~
pdimitar
The official book is fairly beginner friendly but some background of computer
knowledge is unskippable if you want to progress with programming.

[https://doc.rust-lang.org/stable/book/title-page.html](https://doc.rust-
lang.org/stable/book/title-page.html)

