
Rust 2018: an early preview - steveklabnik
https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776
======
qop
Rust is getting too complicated and noisy.

It's not that it's difficult to use, but there's just too much stuff shoved
into the drawer, and I really just need some silverware.

my two cents. All the rust I've written is just rewrites of things I
originally wrote in other languages. I'm a little disappointed to realize that
I'm glad I don't have to write Rust for a living.

I also think the 6-week release cycle is WAY too fast for a language with the
low-level ambitions of rust. Granted, it's not like stuff is being broken
every six weeks, they're doing a wonderful job with backwards compat in mind,
but just the sheer volume of language delta is a lot for the average
programmer, I think. Maybe I'm just a below average Rust hacker and maybe I'm
just not "getting it"

------
pietroglyph
These are welcome improvements, but I worry that they will continue increasing
complexity to the point that we have another C++ on our hands. There's a
balance between new features and improvements, and simplicity and stability. I
hope the Rust team finds that balance.

~~~
danieldk
_but I worry that they will continue increasing complexity to the point that
we have another C++ on our hands_

I am currently teaching a course where Rust is the main language and this is
already a problem. Some recent changes have made Rust more difficult to
understand. E.g. impl in argument positions have are really opaque. For
example, it is quite easy to explain and understand the difference between

    
    
        fn foo<T>(t: &T) where T: SomeTrait
    

and

    
    
        fn foo(t: &SomeTrait)
    
    

because the type parameters are explicit in the static binding case. On the
other hand,

    
    
        fn foo(t: &impl SomeTrait)
    

is really opaque. I know that it is an ergonomic win and provides consistency
between impl in argument and return positions, but it makes Rust more
difficult to understand for new language user. Other magical/difficult to
understand semantics: automatic derefs in pattern matching, deref coercion,
different drop orders for structs/local variables, impl coherency rules, the
distinction between copy/move types, etc.

Don't get me wrong, Rust is my all-time favorite language. But I agree that
increased complexity is the most dangerous pitfall for Rust. I fear the day
higher-kinded types are added and the catogory-theory fest will be added in
addition to the existing complexity.

~~~
chrismorgan
Note that in Rust 2018, trait object syntax moves to using `dyn` (see
[https://rust-lang-nursery.github.io/edition-
guide/2018/trans...](https://rust-lang-nursery.github.io/edition-
guide/2018/transitioning/traits/dyn-trait.html)), so that your second code
block will actually be:

    
    
        fn foo(t: &dyn SomeTrait)
    

&dyn SomeTrait and &impl SomeTrait are then more directly comparable. “&impl
SomeTrait” should be read as “a reference to a type implementing SomeTrait”.

It’s different from the angle-bracketed generic syntax you may be used to, but
I _think_ it’s generally superior. I certainly find it _much_ easier to write
and read than the generic syntax or generic-syntax-with-where-clause versions.
Well, I say generally superior—but its potential downfall is the turbofish
issue, that impl in argument place is _not_ just sugar for the generic syntax.
And thus that for now impl in argument place is arguably unsuitable for
library code and only suitable for application code. We’ll see how that pans
out.

You mention higher-kinded types: there is actually a plan now for a feature
equivalent to HKT, generic associated types (associated type constructors),
[https://github.com/rust-lang/rfcs/pull/1598](https://github.com/rust-
lang/rfcs/pull/1598), and I’m glad; note when I say _that_ that I was one of
the few that campaigned before Rust 1.0 for explicitly _not_ touching HKT for
a few years purely for marketing reasons—they’re scary and will put people off
Rust. But certainly I have encountered a couple of situations where generic
associated types would substantially improve ergonomics in my HTTP and web
work, and this is a proper Rust-flavoured take on the concepts behind HKT. I
believe it will be good to have.

I am still a bit anxious about the volume of change happening, just as you,
others, and graydon just now on the forum post.

~~~
nixpulvis
I still haven't used it enough to have a real opinion, but I think `dyn` is
the one thing in all this I feel is a bad change. Otherwise the module system
is going to be much nicer, `impl Trait` has been a thing needed since day 1,
and some new forms of elision are nice. I'll be curious to see if I like the
`match` changes though.

~~~
steveklabnik
Incidentally, the match changes work in stable today.

The audience for the edition isn’t just those who follow Rust closely, but for
those who don’t. And even for those who do, we want to take a look at some of
the things that make writing Rust feel differently in the last few months.
Turns out the match stuff was good enough to stabilize a bit earlier, even
though it was designed with all of these other features.

~~~
nixpulvis
Yea fair point, just haven't been writing enough rust over the last few months
:(

There remains a small part of me that enjoyed the explicitness of fighting the
compiler to understand what type I was actually dealing with (forced
learning).

~~~
steveklabnik
Have you read [https://terrytao.wordpress.com/career-advice/theres-more-
to-...](https://terrytao.wordpress.com/career-advice/theres-more-to-
mathematics-than-rigour-and-proofs/) before? I find it _extremely_
interesting. Sounds like you may be on the "rigorous" stage. This kind of
feature helps the pre and post stages, at the expense of that one.

~~~
nixpulvis
I hadn't. It's a great peice though. The rust programmer who adds and removes
`&` and `ref` blindly is in phase 1, the part I'm claiming to like is more or
less phase 2, where some real thought goes into it, "here I have a &Option, so
here it must be &Some(...)" and so on. Phase three is practical, much like how
I might tell someone in casual conversation that something took orders of
magnitude more time, without worrying too much about what magnitude I'm really
talking about. This can give you the head space to tackle "real problems". As
rust matures (and its users with it) I can understand the desire for these
conveniences. I do feel the language loses some of its educational prowess.
I'm always arguing in favor of more Racket like ideas, but the whole family of
languages thing helps in this regard, but makes for quickly divergent
communities. </ramble>

------
ben0x539
Yeah I can't see myself ever writing "crate struct Foo" or "crate use foo". :/

~~~
steveklabnik
There’s no plans to remove pub(crate), so you can still use it if you like.

~~~
ben0x539
Plain `pub` was concise and local and simple. :<

~~~
epage
I think I saw something about a lint for bare `pub` that isn't visible to the
user. I think one of the intents is to make it easier to audit for what is
publicly exposed and what isn't.

Found it: [https://github.com/rust-
lang/rust/issues/45521](https://github.com/rust-lang/rust/issues/45521)

~~~
ben0x539
Yeah, that's gonna be seriously annoying. :/

------
nazka
Please don’t make Rust harder to read and code. I am almost done with the long
tutorial/documentation and it’s already a lot. The genetics syntax with the
ownership and the strut/impl/trait is already a lot to eat. For me if you have
to break the past version of the language for the better it’s great. Just
build an as simple and readable language as you can.

~~~
pimeys
When you've written Rust a bit longer (over two years for me now), these
changes address issues we face every day, making it now much easier to reason
about your code. Before the introduction of `impl Trait`, splitting a large
function using Futures to smaller ones either required you to have a
ridiculously long type signature or take a performance hit with dynamic
approach using a `Box`.

The introduction of NLL will make beginner's life easier, so will the changes
to the lifetime variables and if writing async code, you should be counting
days to get the async/await and pinning to the stable rust.

I'd like to know what changes here you think will make it harder to read and
code Rust?

~~~
nazka
From where I am now and so not far in the world of Rust, I am struggling to
learn all the new paradigms and ways of doing things with a special syntax.
Maybe the syntax is easier for others or it will get better for me after a
while but when I see the new dyn it’s hard for me to place it in an already
crowded things to know.

The other thing is how past and future features/syntax are supported, like for
the new modules systems. I will prefer to break things when it makes sense
with new features well thought out rather than support different ways of doing
something and have as many ways of writing it. At the end of the day with a
full team it’s as many way we have to read and so to understand. And even
thought your team has the same guideline it’s the same problem when we start
to read open source projects all with different ways of doing things. I won’t
want to have a language that don’t break things and features stack themselves
across the years but rather a language that refine itself over time with only
one way of doing things. We can see how it turned for C++ where the language
is so big that you have different ways of writing it and like how Google has
its own guidelines and others too. On the other end look how Swift look now.

Right now my feelings are not to add new features but to refine the language
and the syntax. But I can be all wrong. I mean I have just starting to learn
Rust. A syntax with some ideas from ReasonML for instance will maybe make it
better.

On a side note I hope this comment comes not too raw I see many down votes. I
am just expressing my point of view as a beginner. Right now I know many of my
coworkers will be turn down with what I said in my first comment. And they
will turn to Go instead. Which I am sure can be fine technically but I really
want to see Rust succeeds and have even more Rustaceans!

~~~
burntsushi
FWIW, I would consider a good chunk of Rust 2018 to be refinements on the
language and the syntax. The amount of thought that has gone into those
changes is enormous. I mean, if you just look at the new things in Rust
2018[1], then basically every single one of those is a refinement or
clarification on an existing idea. The major exceptions are async/await, SIMD
and _maybe_ impl Trait. SIMD isn't a language change though; just an
incredibly large std::arch library module. :-) impl Trait has fairly limited
scope in my view. I think its primary advantage at this point is to make it
easier to write compositional code when dealing with futures.

It is hard to say "no" to _some_ new language features because many of them
are very very strongly motivated by incredibly compelling use cases.
async/await is the big one. Rust's direction is nothing if not pragmatic, and
async/await is kind of the obvious direction to head in if we want people to
be able to write asynchronous code happily.

[1] - [https://rust-lang-nursery.github.io/edition-
guide/2018/statu...](https://rust-lang-nursery.github.io/edition-
guide/2018/status.html)

~~~
chrismorgan
`impl Trait` syntax has been used casually in conversation on
irc://irc.mozilla.org/#rust since _long_ before Rust 1.0, and some at least of
us had hoped to have it before Rust 1.0. It took a while, but we finally got
it, so now we’re fairly happy. (I think the turbofish issue hadn’t occurred to
those of us that casually wrote it before, but once it was being implemented
it became obvious.)

~~~
burntsushi
I know. I was there. ;-) What I meant was that `impl Trait` hasn't existed yet
on Rust stable, and it gives folks legitimately new powers, so it seems like
it was on the line between it being a refinement and it being a legitimately
new language feature. But this is splitting hairs; the classification doesn't
matter much.

------
nixpulvis
I'll be really curious to see how the async/await stuff plays out. I'm still a
bit unclear as to why it needs to be a language feature and not something in
STD or an external crate. I'm sure if I read the RFCs/Issues I'd understand
better, but it's been a while. Regardless, most of the changes so far are
welcome in my eyes :)

~~~
steveklabnik
The PR to add it just landed in nightly, incidentally!

But yeah, if you care, reading the RFC _should_ explain that. It's been a
while since I read it, but we had a procedural macro based version, but ended
up with real language support for a reason.

------
Mouse47
Stupid question on `Box<Foo>` vs. `Box<dyn Foo>`: does this syntax apply to
any other places where a trait is used as a type parameter?

E.g.

    
    
        //do we write the type of MyBox like 'MyBox<dyn Debug>'?
        struct MyBox<T : ?Sized>{
            inner: Box<T>
        }

~~~
chrismorgan
Yes. The unsized trait object type is being renamed from `Trait` to `dyn
Trait`.

------
jokoon
I recently found out about volt. I was so glad i found this language, which
has everything i want, basically an improved c.

Then I learned it was garbage collected. I felt disappointed.

------
ben0x539
Using JavaScript to remove certain lines from the code examples in the book is
such a weird choice.

~~~
steveklabnik
It’s primarily so that tests can still be run, while presenting only the info
you want to show to those who read the docs.

~~~
ben0x539
You should filter those lines before they hit .html files.

~~~
maxbrunsfeld
There's a button to toggle whether these lines are shown or hidden.
Implementing this button's behavior using JavaScript seems perfectly
reasonable to me.

~~~
epage
I appreciate this. There are too many times that example code omits things and
as someone new you get confused as to what the boiler plate is you should use.

