Rust 1.47

[oconnor663]

The "you can't print arrays larger than 32" thing was a common papercut for beginners. You could usually work around it with slices, but until now that's been yet another thing to memorize on day 1 or week 1. It only takes a couple of papercuts to go from "this is challenging but fun" to "this is pointlessly frustrating", so I'm always very happy when one of the big ones gets fixed.

[brundolf]

Fortunately under normal circumstances it's almost always better to use a Vec anyway, and this is encouraged by the Book. Having done projects in Rust for the past ~2 years I didn't even know this limitation existed, because I hardly ever use plain arrays.

[vvanders]

It gets really annoying on no_std, which makes me happy to see this making progress in the language.

[kaoD]

Does Rust monomorphize const generics too? E.g. if I use 255 arrays with length 1-255.

[glandium]

OTOH, it's footgun-y because for each size you get a new different monomorphism of the formatting function, and you may end up with a lot of them.

[The_rationalist]

What about printing vectors? (array dynamically sized) What other kind of traits are useful for arrays?

[kibwen]

Great to see that const generics has become mature enough to be exposed by the stdlib, even if it's not ready for full stabilization just yet.

People wanting to use const generics themselves will want to follow this issue, which is about stabilizing a minimally-useful subset of const generics: https://github.com/rust-lang/rust/issues/74878 . It seems to be coming along well: "Regarding the remaining steps: there are only a handful of issues I think are blocking min_const_generics at this stage (several of which already have open pull requests). We also want to add many more tests, which is something anyone can easily help with. If you want to tackle one of the issues, feel free to ask @lcnr or myself how to get started; I'm going to dedicate time to fixing whichever remain."

[adamch]

It's a little thing, but one of my favourite parts of any Rust release is seeing which stdlib functions become `const`. The ergonomics of build-time evaluation are slowly improving, and I'm very excited to slowly do less at runtime!

[scudd]

Can increase in use of `const fn`'s create a noticeable decrease in compile times? As someone whose never worked on compilers, I'm not really sure what the magnitude of that processing time is in relation to everything else.

[pjmlp]

The problem with "const of all things" is that you will get enough free time to prepare a big meal.

[k__]

What does "becoming const" mean?

[zamalek]

This release seems like it focuses on ergonomics, which is fantastic.

> Shorter backtraces

This is a very welcome change! Having to find the "root" of a full stack trace can easily take 30 seconds, which really starts adding up.

[dfranke]

I hope we eventually get Presburger arithmetic support so that one could write

    fn concat<T,M,N>([T; M], [T; N]) -> [T; M+N]

[_dwt]

The future is here now, for the last ~week or so, on nightly Rust:

    #![feature(const_generics, const_evaluatable_checked)]

    fn append<T: Copy + Default, const N: usize, const M: usize>(
      xs: &[T; N], ys: &[T; M]) -> [T; N + M] {
        let mut result = [T::default(); N + M];
        result[..N].copy_from_slice(&xs[..]);
        result[N..].copy_from_slice(&ys[..]);
        result
    }

    fn main() {
        let arr = append(&[1i32; 3], &[2i32; 4]);
        dbg!(arr);
    }

[baq]

and also proper units of measurement support while we're at it...

[Deukhoofd]

Is it really a good idea to target a release candidate of LLVM in the Stable branch by default? I can understand wanting to benefit from new features, but I wouldn't want production code to be running on something that LLVM does not yet consider ready for release.

[pornel]

Rust tends to exercise code paths in LLVM that clang doesn't, so from Rust's perspective LLVM was never particularly stable (e.g. pointer aliasing has been broken in LLVM for years). In that case it's better to get fixes for known bugs in LLVM ASAP.

[maxfurman]

Is there a good post out there explaining "const generics"? I'm very curious about this phrase and not sure what it means.

[offtop5]

Stupid question, but will Rust ever have a non strict mode. I'm used to writing C# , Python and JS.

Rust seems to be overally punishing

[andrewzah]

I think looking at it as "punishing" is the wrong mentality.

Rust has very strict checks, and we -want- those. That's why we're using Rust in the first place.

I -could- use a more convenient / lenient language like ruby or golang but I generally wouldn't prefer it unless the use case made sense. You end up "paying" in different ways later down the line as your codebase grows in complexity.

In my experience, the rust compiler is extremely helpful and most issues I had went away after reading the rust book. [0]

[0]: https://doc.rust-lang.org/book/

[mamcx]

I have used that langs and much more. Rust was the hardest lang I have learned by a long shot. The first 2 months was kind of miserable (more because I try to build a interpreter that hit some of the hardest stuff on rust, and not knowing how deal with them).

In retrospective, I make the life harder:

* Thinking like in the other langs I have learned (with exception of my first 2) is enough to just read fast some tutorial and start coding... I relent and pick a book to learn it right.

* Start worrying so much about performance, when never before I bothered much (what! this can ALLOCATE!). Now I clone like madman!

* Try to fit the OO mentality to Rust. Even in F# I don't fully commit to POCO objects and functions as I do in Rust now. Also, the lacks of polymorphism is what hurt me sometimes (ie: is harder in rust)

But now? Rust feel ABSURDLY productive. The thing I notice is how much I refactor stuff now, (even more than in F# that also was a up in this regard).

The "punishment" parts is only in my toy interpreter and very small now. For my main project ( a ERP/ecommerce app rewrite from F#) Is great!.

[root_axis]

The eagerness of the compiler to point out your mistakes is the quintessential feature of rust, if this is something you don't want to deal with then almost certainly rust isn't the language for you.

With that stated, I would encourage you to understand why rust was designed this way and why the strictness of the compiler is actually a major advantage compared to languages like Python and JS where a lack of a type system actually makes the software much more prone to bugs.

[pornel]

It probably won't. Rust's unique selling point is in a combination of safety, performance, and minimal runtime (no garbage collection). The most difficult aspects of Rust are a direct consequence of safe minimal-overhead memory management, and we don't know how to do much better without adding a GC/runtime or compromising safety.

Rust has many quality-of-life improvements that could be transplanted to a more relaxed GC-based language, but that won't be Rust any more. Here are some musings how such language could look like:

https://without.boats/blog/revisiting-a-smaller-rust/

(OT: why OP got downvoted so hard? It's a reasonable question to ask)

[elliebike]

No, because that's not really the point of Rust.

You make the sacrifice of a "punishing" compiler, and spending more time writing code, but you gain software that's more likely to be "correct", safe, and not leak memory.

Really, as in all things computers, it depends what your set of requirements are as to what trade offs you make

[ben-schaaf]

For "non strict mode" meaning bypassing the borrow checker, rust already has that and it's called "unsafe". And if by "non struct mode" you mean not having manual garbage collection then you've already got that either as `::leak` letting you leak memory or various GC implementations like https://github.com/Manishearth/rust-gc/.

[creata]

The main way to make the compiler more forgiving is to use Rc<RefCell<T>> (and Arc<Mutex<T>> when you need thread-safety) to move borrow checking from compile time to run time. Please avoid doing that, though --- it's ugly, it can be slow, and the borrow checker is usually yelling at you for a good reason.

There are also some immature crates for tracing garbage collection in Rust, like rust-gc, which typically has higher throughput than reference counting.

[higerordermap]

Rust doesn't overlap with the application areas of those languages. It is a complement as systems language to those web / backend / script languages.

I too don't like rust evangelism around here. But any developer should know at least one system language, understand algorithm complexity, understand basics about memory management and caches, etc.. And probably it is easier to learn rust than C++ to those with web background.

[munchbunny]

For the types of stuff Rust is often used for, the strictness is a feature.

[rkangel]

One thing you can do is wrap everything in Rc<>. This makes the held object reference counted and you can copy references around as you feel like. This gets you ownership much more like what you would get in a GC language (e.g. C#, Python, JS), but in an opt-in fashion.

[GolDDranks]

You might enjoy trying OCaml! Most of the "necessary and hard" strictness of Rust comes from not needing a garbage collector. Once you have that, it's a lot easier to provide something rigorous but more ergonomic.

[scudd]

In my experience, I did eventually start to appreciate the compiler forcing me to address things up-front.

But as an aside, if you're just trying to prototype quickly, some useful "shortcuts" can be:

- Using `Box<dyn std::error::Error>` for functions which need to handle a result

- Using `unwrap` or `expect` to easily access Option internal values

- Using `unimplemented!()` if I'm trying to mock an API design. This one is nice because it will let you build out the signature including specifying a return type without having to build out the function logic.

Obviously these are shortcuts and not production suitable, but can be good to just get some code on the page that compiles

[outworlder]

> Rust seems to be overally punishing

There's nothing preventing you from using multiple languages on your app. Say, Rust for foundations and Lua/Python/Scheme/Tcl/Whatever for glue.

[momothereal]

You might be more interested in something like Go, which has a less punishing compiler.

[cute_boi]

Sorry but no please. I am already irritated by library in typescript that uses any everywhere :/

[FullyFunctional]

This marks the first Rust release than can be directly installed with plain old rustup.sh on RISC-V Linux distributions (like Ubuntu, Fedora, and others). A very awesome milestone and my thanks to all who contributed.

All the core tools I tested works 100% and almost all the crates work. A few, like libc and Nix, still needs explicit riscv64 support.

[li4ick]

Just how prevalent is Rust in the industry? I remember trying it out back in 2014 and saw nothing of interest, as a Haskell user. A lot of the main "selling points" of Rust are getting introduced in C++. Also, what is it about Rust that gets automatic top view on HN?

[eloff]

Programming languages can be a very personal thing. But I will offer my perspective having used C++ extensively (both modern and awful), Go, Rust, a little Haskell and some 20 other languages in my two decades career.

Rust is one of the nicest languages out there. Very well thought out, elegant, full low-level control for real systems programming (sorry Go!) AWS uses it a lot, Microsoft is starting to use it.

Go, or even Python is better if you just want to make a backend API for a (web) app. You'll be more productive with it over Rust because you have a GC and can ignore the whole ownership issue for the most part. Python for very small teams likely to stay small for a long time, Go otherwise.

C++ has come a long way, but it's still hairy and loaded with footguns and baggage. I would only use it these days if I needed to use a big C++ library (like a game engine).

I am no longer willing to use Haskell, PHP, Perl, Java or JVM languages, .NET or anything else that's not Go, Rust or Python. With the same caveat as C++ above. I pass over job postings that require them. That's not saying those languages are bad, just that in my personal opinion there are better tools out there, and if I'm going to work with it day in and day out, it had better be in something at the top of my list - because life is short.

[oconnor663]

> I remember trying it out back in 2014 and saw nothing of interest

The 1.0 release was in 2015, and there wasn't much industry adoption before that. Today most of the big tech companies are using it for something. Microsoft published a series of articles this year about using Rust internally.

> A lot of the main "selling points" of Rust are getting introduced in C++.

In the C++ world, Rust's biggest selling point by far is memory safety. The safety story is based on notions of ownership, borrowing, and lifetimes that are built into language itself. Most of the standard library, and many foundational crates like Serde and Rayon, have designed their APIs around these concepts. These things tend to go "all the way down": Every single function or datatype that deals with references defines its lifetime requirements for those references, and every single callsite of one of those functions or variable of one of those types is statically checked to meet those requirements.

I wouldn't go so far as to call this an "all or nothing" thing. Languages like TypeScript make it clear that you can get good value out of a strict type system even when much of the ecosystem isn't strict. But there's a lot of value in being on the "all" side of the fence here -- especially for languages with pointers and destructors -- and I think it's unrealistic to expect an established language like C++ to make that many changes.

> Also, what is it about Rust that gets automatic top view on HN?

Having a new, serious contender in the C/C++ world is exciting! And maybe Rust being more challenging to learn makes people more excited about being "in the club" when they do learn it. On the other hand, all the talk about memory safety seems to make some people kind of...self-righteous?...about the language, which we would all prefer to see less of :p

[gameswithgo]

>Just how prevalent is Rust in the industry?

It has been picking up a lot lately, Apple, Amazon, and Microsoft are all showing some adoption, for instance.

> I remember trying it out back in 2014 and saw nothing of interest, as a Haskell user

The interest for a Haskell user would be that you have some of the functional programming features you like (such as discriminated unions!) with C/C++ levels of runtime performance/efficiency. For someone who has no need for that level of low level control/performance, Rust is generally not a language you want to use, for sure.

> A lot of the main "selling points" of Rust are getting introduced in C++

It is true that you could, with sufficient coding standards and linters, get something approximately like Rust by using C++, where the linter disallows any non safe pointers, any use of null or nullable types without wrapping it in a variant, disallowing all cases of undefined behavior, and so on. However you would have something a lot less pleasant to use than using Rust in the first place, build times would probably end up worse with those thing enforced as a build step, and setting up such an environment would be non trivial and you basically are just building rust out of C++, twine and gum, so why not just use Rust?

[simias]

I'm currently rewriting the "industry" application I started 4 years ago in Python into Rust. At the time I wasn't sure if Rust was mature enough to use it for a critical application, and I needed to get started quickly so Python seemed like the right choice.

Now that the application has grown to be quite huge I really struggle to maintain the python code, I miss static typing. Big code changes are a pain to validate and regressions always manage to slip in the cracks. Meanwhile I've used Rust for some smaller, less critical components and it Just Works. C-tier perfs and zero crashes in 4 years.

I'm definitely optimistic for the future of the language at this point. The community is thriving and the language keeps improving, while not breaking backward compatibility and forcing me to update my code to make use of the latest features.

[steveklabnik]

Rust in 2014 and Rust today are very different; specifically, 2014 to 2015 was a very tumultuous time. 2015 saw the release of Rust 1.0, and so a lot of stuff happened to get things ready for that, including some very large changes to the entire standard library, a removal of most of the runtime... all sorts of stuff.

[jug]

I think contributing to the popularity here is that Rust is interesting to discuss out of an academic perspective due to the niche it has carved out, with the compiler able to see already at compile time whether your code is thread safe with no race conditions, and without memory leaks and buffer overruns. This without support like a garbage collector or a virtual machine overseeing things. OK, it's not bullet proof, but large swathes of issues are prevented that often aren't in other big languages, and you kind of have to go out of your way to shoot yourself in the foot.

As for use in the industry, I see it mentioned every now and then and I keep being surprised because I have low expectations of its adoption, but then suddenly there are big things like Dropbox rewriting their synchronization core (Nucleus) in Rust, and Microsoft releasing Rust bindings for their next-gen Windows API (WinRT).

So I guess it's still rare in the very large realm of software development, but probably more popular than one may expect for a bit of a fringe language. One that I first thought would remain a proof of concept and point of discussion in computer science circles. I'm happy to be wrong because I think it does solve some long standing problems in certain projects.

[mwcampbell]

> Control Flow Guard on Windows

I gather from the description that this is not enabled by default. Is that correct? If so, why isn't it enabled by default? It would seem to fit with Rust's focus on safety.

[rkangel]

Are there any particular features from LLVM 11 that are interesting to Rust users?

[steveklabnik]

Other than "it looks like maybe it made up some of the compile time loss from LLVM 10," I'm not aware of anything specific.

In general, we update regularly to gain access to bug fixes and because upgrading regularly makes each upgrade easier, so we don't need something specific to trigger an update.

[fulafel]

What does the complexity trajectory look like for Rust? In 10 years, is it going have many more language level features and interactions thereof?

[02020202]

ah, rust...the quasimodo of programming languages.