
Rust 1.37.0 - pietroalbini
https://blog.rust-lang.org/2019/08/15/Rust-1.37.0.html
======
jedisct1
Rust has evolved from something safe and _simple_ (once you grasp the
different type of pointers) to something way less accessible.

Rust source code is now full of annotations, and very hard to read and
maintain.

Traits have evolved from a nice feature to something overused everywhere.

Basic crates use so many generics, impl Trait and abstractions over
abstractions over abstractions that it's really difficult to follow what
concrete types you need to satisfy these.

When one of the oldest and still unanswered issue in the Hyper HTTP library is
"how do I read the body?", there is a conceptual problem.

And things got even more complicated with Futures. async/await don't solve
much, as besides textbook examples, these are unusable without deep knowledge
of how everything works internally. Pin/Unpin makes things even more
complicated.

I'm an early Rust adopter and advocate. However, I wouldn't consider it any
longer for new projects.

My productivity in Rust has become very low compared to other languages such
as Go or even C, that let me easily express what I want to do.

With Rust, 90% of my time is spent trying to understand how to express what I
want to do. Such as what types I have, what 3rd party crates expect and how to
convert them.

~~~
amedvednikov
I'm working on a language with similar goals, but with the focus on
simplicity:

[https://vlang.io](https://vlang.io)

A relatively stable 0.2 release will be out this month.

~~~
oconnor663
I'm curious about the example code at
[https://vlang.io/compare](https://vlang.io/compare) (apologies if you
answered this before):

\- Does the compiler use escape analysis to determine that the `cursor`
variable needs to be heap allocated? If not, how does it know that the worker
threads won't outlive the stack frame that owns `cursor`? If so, when does the
allocation get freed? And does implicit heap allocation conflict with the goal
of being as fast as C?

\- How does the compiler know that the `lock` block is the only code that
touches `cursor`? Does it still work if the `lock` block is in a subroutine?
Does that require whole-program analysis? If two different `lock` blocks touch
the same variable, are they implicitly a single `lock`?

~~~
kbd
The two languages I'd be most interested in seeing added to that comparison
are Nim and Zig. Those definitely have most of my mindshare on "new low-
level/efficient languages simpler than Rust".

------
eyeinthepyramid
In case anyone else is curious, async/await isn't part of this release but
should be in the next (1.38):

[https://github.com/rust-lang/rust/issues/62149](https://github.com/rust-
lang/rust/issues/62149)

~~~
jjtheblunt
Genuine question: given a language which has a real notion of
parallelism/concurrency and can run real threads on multiple cores, what is
the appeal for async/await?

~~~
GrayShade
And now you have 32 cores just waiting for slow HTTP clients. Apache with the
prefork MPM does exactly that.

See [http://www.kegel.com/c10k.html](http://www.kegel.com/c10k.html) for an
in-depth, if old, discussion.

~~~
umanwizard
Why would cores be waiting? A thread blocked on synchronous I/O will in
general not be scheduled on a core. This is true on all OSs that I’m aware of.

Not sure if Apache had some spin-wait loops or something, but if so then that
was a bug in Apache, not a fundamental characteristic of doing synchronous I/O
in threads.

~~~
GrayShade
You're still paying some costs: there might be scalability issues in the
scheduler data structures (how long does it take to schedule one thread out of
a million blocked ones?), you need memory to store their stacks (hope you're
on 64-bit), when they become runnable, you have a lot of context switches
(which cost even more now after the Spectre fixes). Probably others that don't
come to mind right now.

As for Apache, it spins a number of processes up to a point. When there aren't
any free ones, the clients don't get any data.

~~~
umanwizard
Yes, I pointed all of this out in another reply:

> For one thing, threads take up memory and address space, and create work for
> the scheduler.

It is the right answer. "Cores are waiting" is not the right answer.

------
sitkack
Interesting how much two of the big cloud providers are assisting the Rust
project. Is GCP absent due to Chrome/Firefox?

> AWS has provided hosting for release artifacts (compilers, libraries, tools,
> and source code), serving those artifacts to users through CloudFront,
> preventing regressions with Crater on EC2, and managing other Rust-related
> infrastructure hosted on AWS.

> Microsoft Azure has sponsored builders for Rust’s CI infrastructure, notably
> the extremely resource intensive rust-lang/rust repository.

~~~
thramp
I did a chunk of the work on the AWS side, and it's not not due to
Chrome/Firefox—Google is using Rust for Fuschia, after all.

At least on AWS' side, it was some individuals—me included—who sent emails to
the right people internally & pushed on tickets to be prioritized. There was
surprisingly little pushback.

~~~
sitkack
Are you in Seattle? Do you go to the Rust meetups?

~~~
thramp
Nope, I'm in Boston, but I did the attend the July Rust meetup at Microsoft.
You?

~~~
sitkack
I will at some point. Meetings in Redmond are difficult but this should also
allow the NWC++ users group to more easily cross paths with Rust.

[https://nwcpp.org/](https://nwcpp.org/)

------
steveklabnik
Glad we’re finally able to talk about the Amazon and Microsoft support; both
companies have been good to the project.

I don’t personally use cargo vendor but seeing it up streamed is also a big
plus, IMHO.

~~~
koolba
Why was it a secret at all? Seems like nothing but good PR all around.

~~~
GrayShade
It wasn't a really a secret. They ran into all sorts of issues with Travis,
and people from Azure offered to run the Rust CI instead. The initial
discussions were public.

Unfortunately, the build times still seem to be close to four hours, which
limits the amount of changes that can be merged.

~~~
centril
We aggressively use rollups to merge PRs into rust-lang/rust to mitigate the
effect of the 4 hour build times. But it would sure be nice to bring it down
to less. It would certainly make my life as the maintainer of the bors queue
easier. ;)

~~~
wyldfire
It's probably a testament to the scope of the build + test that makes it four
hours. If it were faster, would the scope tend to increase in order to hit
more tiers/more tests?

I'd rather my commit sit in a test queue for several hours than push and cross
my fingers like LLVM does it.

~~~
centril
With faster builds, would probably reduce the queue latency and land more PRs.
We'd probably also allow more toolchains to be tested and whatnot.

------
stmw
As one of the larger production users of Rust, it has been great to quickly
the language and the ecosystem are growing.

Small things like Option::xor() or default cargo run are signs more and more
people are using it "for real".

~~~
_zachs
What are you building with Rust? Curious about its prod usage!

~~~
brennanvincent
Not the person you were replying to, but we're using Rust to build
Materialize: [https://materialize.io](https://materialize.io)

------
philbo
I really appreciate the clarity and communication style of these Rust release
notes.

As an enthusiastic Rust user who is perhaps not as academic/intellectual as
most of the Rust community, I often find Rust-related reading material quite
daunting. But never these. They're simple and they're great.

~~~
centril
Thank you! I tried hard to make this blog post easy to read so it's nice that
it feels that way. :)

------
nicolashahn
Profile-guided optimization seems huge. Does anyone have any numbers relating
to the performance increase we can expect?

~~~
slovenlyrobot
The effect is very dependent on program structure and actual code running, but
for a suitable application it's reasonable to expect anything from 5-15%, and
sometimes much more (see e.g. Firefox reporting 18% here:
[https://glandium.org/blog/?p=3888](https://glandium.org/blog/?p=3888) )

------
svnpenn
Rust platform size has recently increased by 50%:

[https://github.com/rust-lang/rust/issues/61978](https://github.com/rust-
lang/rust/issues/61978)

which puts it at over double the size of Go. Worse is seems to be no impetus
to fix this. Also notable is Rust still doesnt have a Map literal:

[https://github.com/rust-lang/rfcs/issues/542](https://github.com/rust-
lang/rfcs/issues/542)

~~~
mlindner
I'm confused, why would you care about the rust compiler size? I can't imagine
a situation where this metric is useful.

~~~
svnpenn
Why would you not? Surely you would agree there's a point where it starts to
matter. What if the platform was 1 GB, 10 GB? Eventually everyone would care.
So the point is it's crossed the threshold where I care about it. Maybe it
hasn't for you, or maybe you just haven't thought about how big is too big.

------
Sharlin
I almost got to make my first contribution to Rust, by correcting a small
semantic error in the (pre)release notes, but alas, I wasn’t at a real
computer at the time and someone else was faster :)

~~~
fb03
Well there is still time and lots to do. Let's help the project in any
capacity we can.

I am a coder but I'm not well versed in Rust enough to be able to contribute
code, but i'm gonna try to investigate and find other venues I might be
helpful (writing documentation, translation to the languages i speak, etc).

------
tass
I’ve tried spending time learning rust, but keep getting stuck since I don’t
have a good project to work on.

What are some good open source projects built in rust which wouldn’t be too
difficult to contribute to?

~~~
rvdca
Depending on your profiency : \- you can actually contribute to the compiler
itself : [https://github.com/rust-
lang/rust/issues?q=is%3Aopen+is%3Ais...](https://github.com/rust-
lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AE-easy+sort%3Acomments-asc) \-
you can contribute to the low-level abstracting graphics library :
[https://github.com/gfx-rs/gfx/labels/contributor-
friendly](https://github.com/gfx-rs/gfx/labels/contributor-friendly) \- and
more generally you can also take a look at the weeksletter (and previous
iterations of it to see where help was requested) :Week's letter :
[https://this-week-in-rust.org/](https://this-week-in-rust.org/)

~~~
tass
The call for participation in week in rust gives a lot of different projects.

I also like that the compiler issues are tagged by difficulty and whether a
mentor is available, fantastic.

Thank you!

------
sleepysysadmin
Newb Question:

Why didn't Rust go with an easier to read syntax? Why did they stick to old C
syntax?

Edit/ Sorry, didn't mean to offend anyone.

~~~
jcranmer
For most programmers, a C-ish syntax is going to be most familiar. In general,
I'd define the "universal C-ish syntax" as:

* Ending statements with ;

* {} for braces, lowercase keywords for control flow

* [] and 0-based indexing for arrays

* Infix operator notation, with mathematical operator precedence

* &, |, ^, ~ for bitwise operators

* . is used for member access

But they didn't copy all of C's syntax:

* There's no ->, since dereference is usually automatic.

* No ?:, if/else can be used as expressions instead

* No ~, since ! on an integer variable does bitwise negation instead.

* Pointer, array, and function types don't have the weird syntax they do in C... you say [ * mut fn()->i32; 4] instead of int ( * ())[4]

* Types follow variables instead of precede them (x: i32 instead of int x)

* No C-style casts (x as i32 instead of (int)x)

~~~
gjm11
I was going to make a snarky comment to the effect that the Rust syntax for an
array of pointers to functions isn't obviously less weird than the C syntax --
I assume the basic thing there is [<type>; <size>] -- but then I noticed that
the C syntax above was very wrong, and the correct syntax is weirder :-).

So what it should actually be is int ( * [4])(). The principle is that
"declaration mimics use" and that a type is written like a declaration with
the variable name omitted. So, for an array of pointers to functions mapping
no-args to int:

If f is such a function, you would call it as f() and get an int, so the
declaration would look like int f() and the type would be int () except that
functions, as opposed to function pointers, aren't first-class objects in C
and don't have a type.

If pf is a pointer to such a function, you would need ( * pf) instead of f, so
the declaration would be int ( * pf)() and the type would be int ( * )().

If apf is an array of those, then you would need to replace pf with
apf[something], so the declaration would be int ( * apf[4])() and the type
would be int ( * [4])().

Which is, indeed, a bit weird.

(Note: Spaces around all the asterisks because that seems to be the least-bad
way of making HN not interpret them as markup. It's quite impressive how
damaging HN's markup feature manages to be given how little it's capable of.)

~~~
jcranmer
Good lord, you're right. I constructed the C syntax off the top of my head,
and I knew about the declaration-mimics-use, so I started constructing it as
if I would use it... I just somehow mixed up the [4] and the ().

C's function pointer and array syntax does make sense when you understand it,
but even for experts, it can be difficult to get it right on the first go.

------
ausjke
not really into rust(yet), just wondering why each cargo install takes
forever(it rebuilds everything related from source?).

By all means I feel rust still compile too slowly, if it has faster build time
I might spend some time playing with it.

~~~
mlindner
It only has to do that once though. Once it's built once it's cached. When
you're working on code you don't even need to fully compile your own code
every time.

------
leshow
Congrats! Like many I was looking forward to async/await in this release but
I'm happy they've taken some extra time to work through any existing issues
before releasing it.

------
johnisgood
Anyone knows when will [https://github.com/rust-
lang/rfcs/blob/master/text/0066-bett...](https://github.com/rust-
lang/rfcs/blob/master/text/0066-better-temporary-lifetimes.md) be fixed?

------
Siecje
With Rust can you cross compile for another platform?

~~~
jen20
Yes:

\- [https://github.com/japaric/rust-cross](https://github.com/japaric/rust-
cross) (more involved)

\- [https://github.com/rust-embedded/cross](https://github.com/rust-
embedded/cross) (straightforward)

(Edited for formatting)

~~~
Arnavion
Or just `cargo build --target` if your distro has cross-compiler + library
packages already, instead of needing to use cross's two-year-old Docker
images.

