Rust 1.26 released

https://blog.rust-lang.org/2018/05/10/Rust-1.26.html

by dikiaap • 8 years ago

495 172 8 years ago

blog.rust-lang.org

steveklabnik33• 8 years ago

So, so, so much stuff in this release! The next few are shaping up to be similar. Very exciting times!

As always, happy to answer questions, provide context, etc.

zer2• 8 years ago

impl Trait and the second edition of the book; very nice! Congrats on the release!

Question: Is there any way to preview what the book's typesetting looks like, since there's praise in the release note?

steveklabnik33• 8 years ago

I am not sure to be honest, I think NoStarch has a preview chapter on the page for the book, which would show it off.

squiguy7• 8 years ago

In this example:

  fn foo(x: i32) -> Box<Iterator<Item = i32>> {
      let iter = vec![1, 2, 3]
          .into_iter()
          .map(|x| x + 1);

      if x % 2 == 0 {
          Box::new(iter.filter(|x| x % 2 == 0))
      } else {
          Box::new(iter)
      }
  }

Why is it that I can't return `impl Iterator<Item = i32>`? Doesn't the `Filter` type implement `Iterator` for the same associated type?

wcrichton• 8 years ago

The guarantee of `impl Trait` is that if I want to call a trait method on the returned object, e.g. for iterators if I want to call `foo(0).next()`, then the function pointer will always be in the same place on the object in memory (static dispatch).

By contrast, if I returned a boxed trait, then calling the trait method requires a dynamic lookup to find the method on the boxed object, and then jumping to that function (dynamic dispatch). In this example, `iter.map(..)` and `iter.filter(..)` return two different implementations of the Iterator trait, so dynamic dispatch is required.

In general, if your function returns multiple possible implementations of a given trait, then the compiler cannot know where the trait methods will be statically, so it is impossible to do static dispatch. Since impl Trait wants to guarantee static dispatch, it requires that only one possible implementation of the trait be returned.

tylerhou• 8 years ago

I think because returning two different types requires dynamic dispatch when using the returned objects, which requires Box; if the function only returns one type then that type can be determined at runtime and further function calls can be implemented with static dispatch instead.

steveklabnik33• 8 years ago

The mismatch isn’t about the associated type, it’s about the actual, underlying type. One is a Map and one is a Filter. It’s not possible to determine which is returned, so you inherently need dynamic dispatch.

There is some discussion about it possibly being sugar for an anonymous enum in the future, but that’s not what it is right now.

Soft• 8 years ago

My understanding is that impl Iterator<Item = i32> in return position means that there is some single concrete type that implements the Iterator trait that we are simply not going to name. This way, the compiler can do dispatching statically. If different paths returned values with different types there wouldn't be just a single type that is known at compilation time. That is why the extra indirection via trait objects is required in the example.

bluejekyll2• 8 years ago

I'll take a stab at explaining this in the way that I finally started grokking the issue (coming from the land of Java).

In Rust (most languages), by default the compiler needs to set aside space on the stack for each return value. So it needs a constantly known size (and shape) to create the slot on the stack. You need to flip to dynamic dispatch, ie a pointer to an object (Java's default), that will be placed on the stack as a reference to the unknown size/shape of the thing at the end of the pointer when the size/shape is unknown. A pointer always has a constant size on the stack.

In this example, `impl Trait` is just saying I want the compiler to figure out the size/shape of the thing being returned for me, and allocate that to the stack at the call site of the function. What this means is that even with `impl Trait` you must return a thing that has the same size/shape.

Steve's answer mentions a common pattern used to create constant size/shape by using an enum for the wrapper type to return two different types on the stack from the function. The only other option is to put something with unknown size behind a pointer, ie Box<Trait> or &Trait, and thus pay the expense of dynamic dispatch.

neptvn• 8 years ago

Congrats to the Rust team and all contributors! Awesome work!

Is the non-lexical lifetime improvements work locked to a particular release yet?

Also, now that the async/await RFC has been merged, is its implementation in nightly or stable going to be squeezed in for the 2018 roadmap plans?

Manishearth• 8 years ago

Yeah, the plan is for async/await to be part of the 2018 edition, but it's going to take some time.

kibwen5• 8 years ago

async/await has been on the 2018 roadmap from the start: https://blog.rust-lang.org/2018/03/12/roadmap.html

As for non-lexical lifetimes, there's lots that's been implemented but much of it is still experimental; follow Niko Matsakis' blog series at http://smallcultfollowing.com/babysteps/blog/2018/04/27/an-a... to stay up to date with what's happening.

DC-3• 8 years ago

This more than makes up for a couple of slightly sparse releases. Congratulations to the whole team, and to you especially for the completion of the new book:

ucarion• 8 years ago

Amazing work on this release! I've needed so many of these features in stable Rust, and I'm so excited to get to use these.

I mean, just yesterday I had to do some weird stuff to a for loop in order to iterate over all u8s in a cleanish way.

Lovely, lovely work. I'm especially excited to see how clever the ref/ref-mut `match` inferring is. If it's reliable, that's gonna remove quite a bit of friction for newcomers. So cool!

steveklabnik33• 8 years ago

pests• 8 years ago

Congrats on the release, I've been following Rust for a long time.

While I'm sure it won't mess anyone up, the range for the i128 is hard to interpret. It looks like -xxxxx - xxxxxx but with the extreme number of digits it looks like two negative numbers or a subtraction problem.

[edit: u128 -> i128]

steveklabnik33• 8 years ago

Heh, thanks. I mostly put it in there because it looks ridiculous, so that's sort of a feature, not a bug. I hear you though.

curun1r2• 8 years ago

With the release of impl Trait (easily the feature I've been most looking forward to), has there been any talk of/proposals to allow anonymous trait implementations? (see: https://github.com/rust-lang/rfcs/pull/2406#issuecomment-384... for an example of what it might look like)

Being able to return anonymous trait impls from inside functions could eliminate a lot of what seems like boilerplate structs/impls from Rust code. As an example, the code in futures-util that adds combinators to a Future defines a type (Then, Fuse, Map, etc) for each combinator function. With those functions now able to use 'impl Future<...>' as the return type, being able to actually type 'return impl Future<...>' could make code like that a lot less cluttered.

steveklabnik33• 8 years ago

I’m not aware of any real proposal.

kaoD• 8 years ago

I feet Rust was getting pretty boring... and that's amazing! As a hobbyist I'm pretty happy to see the language maturing. I remember release 1.0 and thinking it was maybe too rushed. How wrong I was!

Is there anywhere I can get a quick recap of major features Rust is planning to eventually maybe implement, and their state? I mean major features like NLL, impl trait, etc.

IIRC: NLL are nightly already, const generics in planning stage, and what happened to CTFE? For us not in the know, a sneak peek on what's coming/being discussed is very exciting, but browsing the issue/RFC tracker is sometimes a PITA and it's hard to keep up to date, especially after getting used to the workarounds.

steveklabnik33• 8 years ago

Yes and no! We’re gearing up for a big release, and so a lot of stuff is landing. I don’t have that text ready at the moment but rest assured that in the next couple of months you’ll see something. “2018 Edition” :)

GolDDranks4• 8 years ago

There's so much long-awaited features that are finally stabilised.

impl Trait is HUGE. And there's tons of other stuff too. This must be the biggest single release since 1.0.

dikaiosune2• 8 years ago

I recently found myself inserting &/*/ref/ref mut into match expressions before I'd even seen a compiler error. My first thought was "aha, look at how experienced I am with Rust now!" Followed immediately by "I can't wait until this isn't something you have to learn to be productive with the language." And now that day has come! Really exciting for me.

I also need to go and find all of my impl Trait TODO comments and get to work on cleaning those up! What a good day.

I should also say that while I haven't read the second edition of the book yet I am excited to have some new Rust-related content to read. The first edition of the book was a really eye-opening learning experience for me (both about computers and Rust and also about how to build a community and prioritize teaching) and I can only imagine what an improvement on that is like.

eyko• 8 years ago

Nicer `match` bindings was easily my favourite feature of this announcement. I can't recall the number of times I've been trying to show some rust code to someone and then pattern matching comes in and I get a cold drip of sweat expecting their reaction/questions as to why do we need to be so verbose. Happy day for me as well indeed!

kibwen5• 8 years ago

So yeah, 1.26 is the most substantial release since 1.0, but there's lots more goodies coming in the pipeline. :) It just so happened that all the initiatives from last year are preparing to land at approximately the same time. For example, coming up next in 1.27 is stable SIMD: https://github.com/rust-lang/rust/pull/49664 (though only for x86/x86_64 at first; more platforms and high-level crossplatform APIs are on the way).

pimeys2• 8 years ago

The features I'm highly expecting are pinned references and async/await, that will make most of my paid Rust to be so much more readable and maintainable. I know these are coming this year, but any chance they might be already in 1.27?

1.26 has impl Trait, which is one of those things that really makes your life easier as a Rust developer. I've been using beta already with the new API I'm building just to get that feature, now on stable right before I'm actually thinking of deploying the API. Nice.

steveklabnik33• 8 years ago

Pin is in nightly, but async/await is not. Both will certainly miss 1.27, and my guess is MAYBE 1.28, probably 1.29.

kibwen5• 8 years ago

The RFC for async/await was actually just accepted two days ago! https://github.com/rust-lang/rfcs/pull/2394#issuecomment-387... :) It's a priority for this year, but it'll be a few months yet; unless something goes unexpectedly wrong, I'd expect it no later than 1.30, releasing on October 25th.

Scarbutt• 8 years ago

So yeah, 1.26 is the most substantial release since 1.0, but there's lots more goodies coming in the pipeline

Will rust users get a break someday?

steveklabnik33• 8 years ago

It's been three years since 1.0, or at least, it will be in five days :) I'd say one mega-release every three years is pretty... slow, honestly.

That being said, we'll be adding new language features as they fix pain points for users and fit in with the rest of the language; when that's not true, we won't move so quickly. Rust is still fairly young, there's a lot to do!

sushisource• 8 years ago

Super excited to see how much better my code will look with impl Trait and the "no need for &/ref in pattern matches" stuff.

Keep it up Rust team. The language is incredible! Really my only daily complaint is IDE support is still abysmally slow, in both IntelliJ and VSCode.

shmerl• 8 years ago

Congrats on impl Trait release!

By the way, how is the progress of supporting XDG base directory spec for rustc and cargo?

steveklabnik33• 8 years ago

Moving forward still. It’s non-trivial.

runevault• 8 years ago

Everyone keeps talking about impl Trait (which is great) but I'm super pumped for ? working in main now. Was recently writing some code as I finally got back to rust and forgot about that edge and had to write a match block when ? would have been good enough (felt silly to make a method just to handle that).

kibwen5• 8 years ago

Agreed, being able to get rid of spurious unwraps in trivial code and small code examples and replace them with idiomatic error handling is lovely. :)

bvinc• 8 years ago

The first thing I always do is immediately make a function "main2" and make main an error handling function. It'll be nice to not have to do that.

cjcole• 8 years ago

"Speaking of print, you can pre-order a dead tree version of the book from NoStarch Press. The contents are identical, but you get a nice physical book to put on a shelf, or a beautifully typeset PDF. Proceeds are going to charity."

Which charity/charities?

steveklabnik33• 8 years ago

Black Girls Code is the intention today, but originally it was going to be a different tech charity that is no longer around, OpenHatch.

cozicoolmail• 8 years ago

Black Girls Code, in my opinion, is a great organization with a well executed mission and good reach (several major cities throughout the US). Glad Rust picked them.

Source: I've volunteered for them in the past as an instructor.

vvanders• 8 years ago

So freaking excited about impl trait.

This and not being able to do paramterized array sizes for things like SoA, AoSoA where the two things that I feel like were missing from Rust. Really happy to see the first landing(and I understand work is going on for the second).

steveklabnik33• 8 years ago

There was some sort of SoA derive going around, I thought. Regardless, you’re right; we’re hoping const generics lands in nightly this year and stabilizes early next year.

ben0x5392• 8 years ago

Hooray, congrats to the rust contributors, once again. :)

Personally, not a fan of the match change. But then I was already not a fan of autoderef in method calls.

bluejekyll2• 8 years ago

The biggest negative I've seen is this:

    let example: (String, String, String) = ("ref".to_string(), "to".to_string(), "ref".to_string());
   
    let example: (&str, &str, &str) = match &example {
       (ref1, to, ref2) => (ref1, to, ref2),
    };

Which might look confusing to people, it's converting from &(1,2) to (&1,&2)... but it's still type safe. Besides something like this, is there another reason to be worried about it?

https://play.rust-lang.org/?gist=e37f9b31cc5e5c7b9d19c6b0a4c...

ben0x5392• 8 years ago

Reading (or even writing!) rust code, you can get increasingly far without knowing what level of indirection you're operating on. I don't enjoy that. I don't personally feel like the notational burden for explicitness is enormous.

For field access/method calls, autoderef is a bigger convenience because we don't have the C++ -> operator, but I think I'd have preferred a syntax change here over the current behavior.

bpicolo2• 8 years ago

Inclusive ranges are especially useful if you want to iterate over every possible value in a range

Out of curiosity, why was the (or an alternative) choice not to make the compiler understand that the 0..256 was not inclusive, and somehow correct the literal value to do what's intended? Would that have been unusually complicated or?

Edit: Overall, still an amazing release, this was just the bit I'm curious about :) Great work by the whole Rust team/community

steveklabnik33• 8 years ago

Every language I’m aware of has different syntax for inclusive vs exclusive range; making it situational would be quite confusing, I’d imagine.

bpicolo2• 8 years ago

Definitely agree that having the inclusive syntax makes sense either way (..= was mildly jarring at first but makes complete sense syntactically) - I just mean the exclusive ranges arriving at that compiler error definitely seems unexpected

Animats• 8 years ago

Go deliberately left that out.[1] Probably a good decision.

[1] https://groups.google.com/forum/#!msg/golang-nuts/7J8FY07dkW...

GolDDranks4• 8 years ago

There is actually a simple reason for that: the ranges might not be constant literals. So the end value must be an expression of some type; here u8. u8 can hold only values 0-255; 256 is out if its range.

Promarged• 8 years ago

Congrats on the release!

Would the book be updated as new features are added to Rust? I see some useful things being incorporated slowly into the language...

steveklabnik33• 8 years ago

Yes and no. Think of it like release trains; the second edition has left the station, and so isn't being updated directly. It's actually pinned to 1.21; it left the station a while back.

Work on the "2018 edition", which is the next version after "second edition", is just starting. It will be getting updates as new stuff lands, though there may be a bit of lag. In general, docs are going to be a bit weird up to the Rust 2018 release; it's all coming together, but slower at first, faster at the end.

(This means that, as of right this moment, there aren't great docs for impl Trait. I'm working on them right now.)

ovao5• 8 years ago

The post doesn’t go into much detail about how the new i128 and u128 types are implemented, so for anyone who’s as curious as I was, the RFC is here: https://github.com/rust-lang/rfcs/blob/master/text/1504-int1...

_zachs• 8 years ago

I'm super excited about the "Basic slice patterns". I've been learning some Elixir at the same time and was blown away by the different style of programming you can write in using matching. Glad to be able to try it out in Rust as well.

pcx3• 8 years ago

The wonderful thing about Rust is that despite being fairly new and rare to get paid for working on it, it is still enticing( to most programmers I've met). The consistent effort to improve it is really paying off. I hope it gets to a place where it's `batteries included` like Python. There are some glaring holes in the stdlib I would like to see fixed sometime soon.

gamegoblin• 8 years ago

Which glaring holes are there in your point of view? Rust devs are on HN a lot, so maybe they will see your comment.

All that said, Rust definitely errs on the side of preferring to put things in 3rd party crates instead of stdlib, even for things that are very common to put in std for other languages (e.g. random number generation).

pcx3• 8 years ago

A couple of commong APIs I can think off the top of my head:

- HTTP client

- CSV parser/generator

I know Hyper and rust-csv are popular. But having an stdlib that's much more feature complete would be great.

pm2152• 8 years ago

Needing to use two separate third-party crates (lazy_static and maplit) to have a global constant-initialized hash table is the one that surprised me recently.

saghm2• 8 years ago

The argument for putting things in third-party "blessed" crates rather than the standard library is that it allows them not to have to follow the versioning guarantees of Rust itself. Given that the core team has stated that they don't plan to have a Rust 2.0, this means that there wouldn't _ever_ be any API-breaking changes for things added to the standard library; by having things like `regex` and `rand` be external crates, versions bumps can happen independently happen, which means (among other things) that major version bumps are possible.

pcx3• 8 years ago

That's certainly an advantage. But for devs like me, we are used to prog langs providing a set of APIs in the stdlibs, that are officially blessed to be maintained. They might not be the best designed, but they are guaranteed to work for a long long time. This kind of trust is very hard to build for 3rd part libs. It's a trade-off to make, and rust for now has decided to keep stdlib lean and quick to iterate over. But I hope at some point, Rust devs would consider including more APIs.

mook• 8 years ago

But the versioning guarantees are _exactly_ why having them in the stdlib would be good for me as a user; it means I'd be able to have code that keeps working, but have new improvements available.

It's totally fine to decide to make the trade off, but it's just frustrating to not have the downside acknowledged.

digitalzombie• 8 years ago

Do you know where I can find the comment about no plan for Rust 2.0? I tried googling it but I couldn't find it. Reason why I'd like to find it to have some guarantee that this is true.

Cause it sounds like a strong commitment here.

jmhain• 8 years ago

Is it possible to match the end of a slice with slice patterns? Something like:

    fn foo(s: &[char]) {
        match s {
            ['a', 'b'] => (),
            [.. 'b', 'c'] => (),
            _ => (),
        }
    }

steveklabnik33• 8 years ago

Not today, but it's coming. This kind of thing does work on nightly.

Lev1a4• 8 years ago

I was mostly excited about slice patterns because of a pattern I wanted to be able to write:

    some_collection.windows(2).filter(|[a,b]|a==b).map(|[a, _] |a).collect();

Turns out the compiler rejects that with a "refutable pattern" error, because the args part of the filter/map closures do not handle the situation where the slice could be empty, which AFAIK can not occur when using windows/chunks/...

Maybe there has to be some special case handling for this pattern to be valid?

nikolay8• 8 years ago

I really wonder why is Golang so popular today when Rust is just killing it?

steveklabnik33• 8 years ago

They're very different languages, so different people like them for different reasons. Why is salt so popular today when pepper is just killing it?

nikolay8• 8 years ago

Well, every two languages are different, but at least for systems programming, Golang unfortunately started to replace Python, but given how vitally important security is in that domain, Rust makes a lot more sense than Golang, won't you agree?

noptys• 8 years ago

I totally just checked whether "pepper" was a competing product to saltstack that I hadn't heard about yet.

nostrademons• 8 years ago

Also Go's 1.0 predated Rust by about 5 years. They started around the same time, but many people won't use a language that's not stable where their existing code may break with each new release. Go has had a ~5 year head start in developing a library ecosystem, tooling, commercial users, etc.

It takes a long time for a language to build momentum and a user base. Python was just starting to get popular when I graduated from college in 2005, and it was already 16 years old at the time.

nikolay8• 8 years ago

This is true, but even today in 2018, Golang still suffers from the dependency-management hell, the notorious GOPATH, and many other issues it should not have being almost a decade old! Even Rust, which some call "lower-level language", which it is not, has Cargo after it learned from Ruby and Node how important is to have easy package management, and being able to install a new project without knowing almost anything about the language.

jkarneges2• 8 years ago

Aside from the head start, I believe Go legitimately hits a sweet spot for developers wanting a language that's relatively easy to use yet also fast and fully compiled.

Rust on the other hand is targeted more towards developers that want C-like low-level control along with safety against shooting themselves in the foot.

The former audience is probably larger than the latter. But popularity isn't everything (JavaScript wins that contest ;)). The important thing is Rust is doing an amazing job in an area that hasn't seen much love.

orthecreedence• 8 years ago

C-like low-level control along with safety against shooting themselves in the foot

Yep, checking in. I want to write libraries that work on Windows, Linux, OSx, iOS, and Android that expose a C api but without having to write any C.

I know a bit of C, but not enough to feel like I can effectively use it to build the things I can build with Rust.

Retra2• 8 years ago

Personally... I used to write Java and Python code (and enjoy it), but fairly straight forward code would just bog down on me. On the other hand, C and C++ code would always crash in frustrating ways.

Rust hits the sweet spot of not being a pain in my ass all the time.

ovao5• 8 years ago

If the Rust ecosystem was up to snuff on the HTTP front, I'd be writing a lot more of it. At the moment, Go's HTTP implementation is just pretty much unbeatable. I'm confident it'll get there — and there's a ton of great work going on to get it there — but at the moment, it's still the Wild West.

Go also hits the sweet spot for CLI apps, in my opinion. The error handling is obtrusive and annoying otherwise, but for command line apps where you're just aborting whenever you hit any kind of snag, it's not a significant pain point.

topspin• 8 years ago

"up to snuff on the HTTP front"

I think this is a pretty major piece as well. Go was introduced many years earlier, backed by Google marketing and had strong HTTP services as a day one feature; it was designed for probably the most popular use case by perhaps the most influential fount of new tech. Given all that has Go really done all that well? Has it gone much beyond network services and a couple other niches (Docker/K8s etc?) It's not really displacing C/C++ in 'systems' use cases. It's not a go-to language for Machine Learning. The runtime+GC obviates most embedded work. You don't see any meaningful uptake of Go among Google's peers; Apple, Microsoft, Oracle, etc. I wonder just how important Go really is.

pimeys2• 8 years ago

Hyper 0.12 is right around the corner with the excellent h2 crate. We've been using the master branch on production the whole 2018 and it's super fast, stable and ergonomic.

sriram_malhar2• 8 years ago

I do a fair amount of Rust and Go, and I am not sure what axis you refer to with the phrase "killing". (Unless it is killing joy, for a lot of people </snark>)

Most apps out there are extremely serviceable with a language environment that runs up to 2x slower than what is possible with Rust. Youtube, edX, reddit, coursera all run on python, Facebook on PHP/Javascript, WhatsApp on Erlang.

In exchange for ceding low-level control, these languages provide a frictionless approach to evolving a system. You get dynamic features that are simply wonderful for creativity. Javascript is a blot on the landscape, but look at the effortlessness of d3.js.

GC is wonderful and does not gets in the way for most apps (from mobile to enterprise). Any time spent thinking about lifetimes sucks the fun out of coding. Lifetimes are fantastic for concurrent programming, no doubt, but there are simple patterns in Go that work well in practice.

Lightweight threads remove another point of friction; they allow you to model the concurrency inherent in a problem without much trouble. I'd prefer Go to get more of Erlang's failure handling and signal delivery mechanisms.

Go is a middling language, but its libraries and ecosystem are solid and have a coherent feel. They work out of the box without having to consult StackOverflow a zillion times.

The language I would love to have is Swift retrofitted with Erlang's process system.

roca5• 8 years ago

Letting GC take care of lifetimes is a big plus for many applications. Rust's ownership model buys you a lot --- no GC overhead (space, not just time), fearless parallelism, more powerful static invariants --- but it costs you development effort, and depending on your application the costs can outweigh the benefits.

Rust improvements like NLL will hopefully reduce the costs. I think we will discover more ways to leverage the benefits, over time. However, I also think it might be interesting to let people opt into a Rust dialect that hides lifetime issues, e.g. using a lot of implicit Rcs and (Ref)Cells.

leshow2• 8 years ago

I have been so excited for this release! impl Trait is wonderful, thanks everybody

pjungwir• 8 years ago

Oh wow, this sounds great! I've hit both the long signatures when returning iterators, and also the dereferencing song-and-dance with match, and my Rust projects have been very limited. So I think these are huge improvements that will help a lot of other newbies like me. I can't wait to start using 1.26 instead. Thanks Rust team! :-)

freeopinion• 8 years ago

Yeah, but can it run Rocket? :-)

steveklabnik33• 8 years ago

Not yet; working on it! https://github.com/SergioBenitez/Rocket/issues/19 is getting shorter and shorter!

stmw2• 8 years ago

Definitely excited by all the progress on the "run Rocket" front!

kccqzy• 8 years ago

Existential types are great! Although I must mention that existential types are basically the way to model OO-style information hiding. It's a great tool to have in any mature type system, although I do wonder how it is compiled. Trait objects are kind of easy to imagine: a heap-allocated dictionary of methods for that trait. I do wonder how heap allocation is being avoided in this case.

EDIT: I didn't read closely enough. Only a single type is allowed, so the traditional existential type construct ("trait objects") are still needed.

kibwen5• 8 years ago

There's intentionally no heap allocation or virtual dispatch when using `impl Trait`; if we were content with that, we wouldn't have bothered implementing it and just continued on as we were with `Box<Trait>`. :P

hardwaresofton2• 8 years ago

As a person who started writing rust this last week, I think I might have picked the best possible time to get in on it.

The community is amazing, and I actually understand all these features that were released I've run into about half of the issues they fix already.

Rust is coming along very very nicely.

MuffinFlavored• 8 years ago

what else would you say it is missing?

Rotareti• 8 years ago

Not essential but keyword arguments / named parameters / default arguments. I love those in Python and OCaml/ReasonML.

hardwaresofton2• 8 years ago

Unfortunately I don't have a good full response to this (otherwise I could contribute it and actually help), but off-head I was surprised by the lack of a `cargo install` (https://github.com/rust-lang/cargo/issues/2179). A few minutes later though I was used to googling for the package i wanted, and getting the version I wanted to use and adding it to Cargo.toml, and that's arguably a better way to do things to start with.

I haven't used it enough to have much more to say -- I've found everything pretty ergonomic so far (especially for a C/C++-tier language), I was most frequently confused when thinking of the most idiomatic way of doing something, but that's remedied by reading more (the rust book first/second edition, the rust cookbook). This should change over the coming weeks.

This isn't a particularly useful comment, but I chose Rust over Common Lisp recently for this new project, and I've found the std library's google-ability to be excellent for rust -- very few pages about steel have come up so far ("result rust" in DDG brings up rustlang related links). When I explored CL, I did not find that to be the case, but maybe I just didn't know where to look -- hyperspec is close but it is a terrible document to navigate through, and the 90s graphics didn't help (though they were nostalgic). Rust documentation is very often concise, well structured, and passably beautiful. I was also pleased with the Abstract Data Type solution in rust -- tagged unions. Some code:

    #[derive(Debug)]
    pub enum ConfigLoadError {
        EmptyFilePath,
        IO(IOError),
        TomlParse(TomlError)
    }

The abstraction enabled here is just right for me, super similar to code that I'd write in Haskell, and helps me abstract over errors thrown by utility libraries (in this case `toml-rs`).

jeffdavis2• 8 years ago

Why is a filtered iterator a different type than an unfiltered iterator?

GolDDranks4• 8 years ago

This is hard to answer as a one-liner; do you know about monomorphic vs. polymorphic code and static/dynamic dispatching? Rust is, by default statically dispatched, so because the two kinds of iterators do different things, they have to be of different types.

jeffdavis2• 8 years ago

Ah, that makes sense, thank you.

One iterator simply returns the value and increments, and the other needs to apply the filter first and potentially advance several times.

mathw• 8 years ago

I wrote a program yesterday in 1.25 which did some simple file I/O right there in main, didn't need to be fancy at all... and then this morning I come online and find that we now have fs::read_to_string and main can return a Result... great!

But I needed this yesterday!

Seriously though, this is an amazing release and so much stuff in here I've been looking forward to for ages. impl Trait is going to change the way I write Rust.

Rust 1.26 released

Related Stories