
What is Rust 2018? - steveklabnik
https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html
======
egnehots
I thought, yeah that's just feature gated stuff. It's just marketing but my
code will break even if I don't use the new edition because my dependencies
will use it.

Turn out that it's false. What's amazing is that the compiler ensures that
projects using the legacy edition can still use libraries relying on the new
edition.

 _that if you’re using Rust 2018, you can use dependencies that use Rust 2015
with zero problems. If you’re sticking with Rust 2015, you can use libraries
that use Rust 2018. It all works together_

That's great!

~~~
xfer
Not sure why you would think that, it also works the same in C/C++ world.

~~~
pcwalton
Not really, because libraries have headers that have to be _textually
included_ into your source. Because they're pasted in as far as the compiler
is concerned, you have to pick one version of the language to compile your app
and all the included headers with.

------
ilovecaching
I'm really loving Rust. I've been 100% C++ dev for work, and Rust is starting
to gain internal traction. Go fell over as a replacement for our less resource
intensive applications because the lack of generics killed interoperability
between it and C++. Rust wins in that area. My only fear would be Rust
continuing to tack on features without every removing anything and turning
into C++ 2.

C++ 17 is still really nice, the language is just old and C compat + lots of
historically bloat makes it crusty. A better type system with more FP concepts
and more safety is a win-win in my book.

~~~
blub
What do you mean by C++ interoperability (re Rust)? As far as I was able to
determine a couple of months ago, there isn't really a good way of doing
interop except by going through a C shim.

The case I was analysing was Qt C++ UI plus Rust library. There's a Rust text
editor (xi?) which is using JSON to communicate between the UI and the core.
In that case I believe it was designed like that to allow for different UIs,
but it looks more appealing than the C interface.

~~~
steveklabnik
Bindgen has grown support for enough C++ to be able to bind to Spidermonkey,
but it's far from full support.

------
sbjs
It's interesting that Rust is starting to use the same version-naming scheme
that ECMAScript and Ubuntu did, being year-based. Personally I think Ubuntu's
naming scheme and release schedule is the best, releasing $N times per year
and naming it $YY.$N, where N is the same each year. This has a host of
benefits: it's obvious how old any given version is, it's predictable when a
new version will be released, it helps prevent development from stalling for
any reason, especially unnecessary-rewrites and way-too-big-features, _and
more!_

~~~
dmoreno
AKA calendar versioning. I also love it.

[http://calver.org/](http://calver.org/).

~~~
eindiran
Interesting, I did not know that this was a thing. That document lays out some
of the potential advantages quite well.

------
samueldavid
I'm afraid of rust adding too many features for its own good like c++ did..

~~~
steveklabnik
We don't just add things for the sake of adding them. Most new features are
being driven by two things:

1\. Making the language friendlier for beginners and easier to understand.

2\. Addressing pain points by production users.

That being said, I'd push back a little on "number of features" as a measure
of complexity. There's a few ways in which this is a problem.

For example, the "waterbed theory of complexity", that is, if you make the
_language_ simpler, you push the complexity elsewhere. This can be good or
bad, depending. I generally hesitate to compare Rust to other languages, but
there was a good illustration of this the other day, about Rust and Go:
[https://news.ycombinator.com/item?id=17618918](https://news.ycombinator.com/item?id=17618918)

Basically, Go has kept the language incredibly simple. Rust has added many
features that Go does not. But that means that error handling in Go is
significantly more verbose than in Rust. You can't just wave away the inherent
complexity of properly handling errors; it has to go _somewhere_. Both choices
are 100% valid, just different.

The other big issue with simply enumerating features is that _cohesion_ and
_orthogonality_ is important. C++ did something truly impressive; they changed
the fundamental model in which you write code. Idiomatic C++98 and idiomatic
C++17 look and feel _very_ different. The cost of this is that many features
don't quite fit together as well as you would like. Or at least, that's what
people say. We try to really make sure that features fit together in a way
that makes sense.

Time will tell if we succeed.

~~~
andrepd
>We don't just add things for the sake of adding them.

I hope you realise that the C++ design committee also doesn't add things for
the sake of adding them. They aren't morons. Often there is a very real
tradeoff in every decision, but generally the motivations seem to also be
those two you mention.

~~~
infogulch

       This paper proposes a web_view facility for the C++ standard library.
    

[http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2018/p110...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html)

Yes, _web view_ and _standard library_ are being used in the same sentence.
How on earth a web view might be considered for inclusion in a standard
library is beyond me.

~~~
steveklabnik
In-context, this makes a bit more sense, though I'm not sure I'd vote for this
proposal if I were on the committee. The introduction does a decent job of
explaining the motivation; this is an alternate to the long-going discussion
about putting 2D graphics in the standard.

Getting outraged at proposals, especially from the outside, doesn't make for a
healthy process; not every proposal becomes accepted. Off-the-wall proposals
can sometimes help explore a problem space with a new outlook. That doesn't
mean that every single proposal is worth taking equally seriously, but Hal is
a well-known name in this space, and has done a lot of good work.

(Incidentally, this kind of situation is why we're interested in adding stages
to Rust's process; we want clarity around the maturity of a proposal. Some
proposals are just for brainstorming. Some are more mature. It can be hard to
tell sometimes from the outside which is which.)

------
baby
I got into Rust recently and I have to say I like it. The syntax is a bit
noisy to my taste (generics, lifetimes and macros) but overall I really like
it.

It seems like it's maybe not a good idea to get too much into it though, the
language seems to move a lot, there are still a lot of things that are not
here (a rand library, benchmarks) or are subject to change. I'm not sure if I
should give it more of my time.

~~~
steveklabnik
We do have the rand crate, and whole built-in benchmarks aren’t stable, the
bencher crate does port them to stable Rust.

While we do add stuff a lot, we don’t break old things, so what you learn is
still going to work!

~~~
Thiez
Except for the breaking changes every edition, of course.

~~~
steveklabnik
Because those are opt-in, they will never break your existing code.

------
stochastic_monk
The thing keeping me from Rust is the weaker metaprogramming relative to C++.
Do you have plans to expand Rust to things like compile-time expressions,
template templates, and perfect forwarding?

~~~
steveklabnik
We do! We've been pretty quietly developing it, but right now, the Rust
compiler contains a full interpreter as well, specifically to do compile-time
evaluation. But, we also do not want to have unlimited compile-time
facilities, as that has serious soundness problems. "const fn" is the name of
the user-facing feature, and MIRI is the underlying interpreter, if you want
to do some searching.

That said, that work tends to fall under "compile time expressions"; "template
templates" are more likely to be served by some sort of eventual HKT, or maybe
even by ATC. I always forget what perfect forwarding is so I probably
shouldn't comment on it.

I am willing to bet that this stuff is a major part of next year's roadmap,
but we'll see!

~~~
Sharlin
For the uninitiated, HKT means higher kinded types, which is the type
theoretic term for what C++ calls template template parameters. That is, the
possibility to pass around type-level functions. I don't know what ATC refers
to.

~~~
steveklabnik
Yes, thank you! ATC is "associated type constructors". I believe Haskell calls
them "type families"? It's sort of a similar idea; a form of higher-kindness.
We are likely to get ATC in the medium term, but full HKT is farther out.

~~~
Sharlin
Right, thanks! It sounded familiar but google revealed nothing. Should have
tried "atc rust".

------
ThJ
I have one sore spot about Rust: The Rust build tools are almost unusably slow
on small ARM devices like the Raspberry Pi Zero. I can compile a simple C++
program just fine on such a device, but Rust will take ages building
dependencies and requires a swap file because it eats up all the physical
memory. Meanwhile, in C++ land, my distribution's package manager includes
prebuilt C++ libraries and headers. I tried cross compilation but that was a
nightmare to set up, and got even worse when Cargo packages depended on C
libraries, which then also had to be cross compiled. In the end, I was unable
to get it working, and had to give up my attempt at targeting that platform
with Rust.

~~~
iknowstuff
Cross-compilation should be much easier when rust starts using the lld linker.
You can try it out now by building a statically-linked musl binary in nightly.

    
    
       rustup target add arm-unknown-linux-musleabihf
       RUSTFLAGS='-C linker=rust-lld -Z linker-flavor=ld.lld' cargo +nightly build --target arm-unknown-linux-musleabihf

------
reificator
An interesting approach to fixing and changing without breaking backwards
compatibility. Time will tell if it lives up to its promises, but I'm
intrigued...

The closest I've seen to this model is "use strict", but having this at the
package level is a nice quality of life improvement.

------
hinkley
IME we put far too much gravity on 1.0 and 2.0. If you’re building a team to
last, you’ll be at 3.0 before you know it. If you didn’t, you’ll be out of
business before it happens. I know which team _I_ want to work with...

