
Announcing Rust 1.6 - steveklabnik
http://blog.rust-lang.org/2016/01/21/Rust-1.6.html
======
haberman
Since this release is focused on stabilizing libcore for embedded use, it
seems a good time to ask a question that's been on my mind.

C11 (and C++11) defined a memory model and atomic operations for shared-state
lock-free concurrency. But that model and the atomic operations aren't being
used by Linux, because they didn't match up with the semantics of the
operations that Linux uses. (See
[https://lwn.net/Articles/586838/](https://lwn.net/Articles/586838/) and
[http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2015/p012...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2015/p0124r0.html)).

I'm curious what Rust says about this. Does Rust have a memory model like
C11/C++11? I'm curious whether Rust (and C11/C++11 for that matter) will
evolve to have primitives like what the Linux kernel currently defines and
uses.

~~~
hellofunk
I'm curious if what you mean is that C++11 has a standard spec for the memory
model you describe, but if Linux doesn't use it, then Linux does not actually
adhere to the C++11 standard? Does that mean that Linux C++11 compilers are
non-standard in general?

~~~
Manishearth
I don't think there are any (modern) C++ compilers out there which follow the
standard 100% and perfectly. ICBW.

~~~
hellofunk
I think you're mistaken:
[http://clang.llvm.org/cxx_status.html#cxx11](http://clang.llvm.org/cxx_status.html#cxx11)

~~~
Manishearth
That's a list of features. My point was that there are some slight variations
induced by optimizations or otherwise which are against the spec.

~~~
hellofunk
I think you are confusing specification with implementation. The C++ standard
does not outline how a compiler implements a feature, just how it should
behave to match the standard. There are several compilers that 100% adhere to
the full standard, including the guarantees specified by the standard in the
form of memory and time complexity (optimization).

~~~
Manishearth
Oh, I know that specification != implementation, but IIRC both clang and GCC
have certain behaviour which do not conform to the standard. But I can't find
these right now, so I'll drop it here :)

------
allan_s
I was wondering:

As the HN crowd seems to have quite a lot of Rust supporters, would it be a
good selling point in a job description ?

i.e if (it's just currently a personal hypothesis) a company were to consider
to (re)write some part of its Rest-ish microservices and that Rust was the
chosen language, and was looking for people to help on that, would it make a
`interesting++` in your mind ? for real services used by real people by a not-
so-startup company, in europe.

edit: I already deployed in production for my previous company some (with a
very stricly limited scope) microservices in rust (with everyone approval) and
it was quite a success, so I'm more and more thinking that rust is now enough
developed to fit the market of language for microservices, as it's more or
less "understand HTTP, read/write from redis/postgresql/mysql/memcache, do
some transformation in between" and Rust now support these operations quite
well

~~~
Thaxll
I don't understand why would you choose Rust over Go for backend stuff. From
what I see here on HN, Rust doesn't target backend app?

~~~
echelon
I've already written several components of my home automation system in Rust.
Mio, Hyper, Iron, etc. are great tools for developing microservices.

I cross-compiled this stuff to run on Raspberry Pi, and the binaries are so
small and performant!

~~~
jonreem
Hey, main author of iron here, I'd love to hear more about your use of iron!
It's always nice to hear from users and your feedback is crucial to driving
the project forward.

Feel free to respond here or reach out (contact details in my profile, you can
find me as reem on the mozilla irc network).

------
Cshelton
This is relevant and cool, UPenn now has a course for Rust -
[http://cis198-2016s.github.io/](http://cis198-2016s.github.io/)

You can follow along, all slides and HW are on github.

~~~
blakesterz
That setup is great, that's all on github? Is there a How-To around that I
could follow to put something like that together?

~~~
astockwell
[https://pages.github.com/](https://pages.github.com/)

They probably should have prepended the school name to their GitHub org, but
that's just my 2 cents :)

------
valarauca1
Actually managed to sneak some Rust into production. Nobody cares what
language you wrote the DLL in, just that it does what the docs say it should
do.

~~~
eterm
Said no one who has to maintain others' software.

~~~
humanrebar
It's a fair point, but there's a lot of write-only Perl, PHP, and C out there.
Let's make sure we don't hold new Rust code to a higher standard that that
stuff.

~~~
zenlikethat
Ideally we should hold all new code to a higher standard than that. All
programmers spend much more time reading code than writing it.

Likewise, Rust is not finalized as a language yet. That means whoever has to
maintain the original commenter's code is likely to be in for a rough time if
and when they ever attempt to bump the Rust version.

~~~
steveklabnik
> Rust is not finalized as a language yet.

It is just as finalized as any other language.

> if and when they ever attempt to bump the Rust version.

If the parent is using a stable release, like this 1.6 is, then bumping the
version should be all they need to do. (Unless they're relying on a safety
hole for some reason; we do fix those)

~~~
zenlikethat
Fair enough- I wasn't familiar with Rust's backwards compatibility guarantees
and had heard a bit about breakage, so thanks for pointing that out.

~~~
Manishearth
Rust development was done in public (unlike Go or Swift which started out
privately), so we had a very long 0.x period which was public and had tons of
breakages where the language designers tinkered with just about every
tradeoff.

So it's easy to see where you get the impression that Rust is prone to
breakages, but that doesn't happen anymore.

------
VeilEm
Congratulations! I'm loving Rust, it's my go-to default language now. I'm
going to start messing around with piston.rs to make some basic 2d games. I
already wrote an irc bot with Rust.

For those wondering, stable just meant the API defined for interactions with
some libraries were subject to change. It wasn't like a problem with using the
APIs, it was just the developer has to know that new releases might change how
they worked or if they would even be available in the future.

~~~
chocolatebunny
How are the software libraries for Rust? What did you do for network access,
string manipulation and GUI stuff?

~~~
VeilEm
The string manipulation is good in Rust, but in Rust strings are unicode and
characters are unicode codepoints. IRC is an ASCII protocol and so I went with
using binary slices `[u8]` for parsing.

For network stuff I used openssl[0] and std::TcpStream [1]

I didn't use a GUI. I plan on using piston.rs[2] to build games but there are
Qt, GTK+ and even Cocoa integrations for rust.

[0] [https://crates.io/crates/openssl/](https://crates.io/crates/openssl/)

[1] [https://doc.rust-
lang.org/std/net/struct.TcpStream.html](https://doc.rust-
lang.org/std/net/struct.TcpStream.html)

[2] [http://www.piston.rs/](http://www.piston.rs/)

~~~
fpoling
Yes, its a pity that Rust requires that strings must be UTF-8. Go designers
got it right as their strings are just immutable sequences of bytes making
them very suitable for network protocols and binary data.

~~~
heinrich5991
That's what Rust has byte slices for: `b"abcdef"`

~~~
fpoling
One cannot use string library in Rust against byte slices. For example, regexp
works only against strings making it unsuitable for processing, say, log
files, that may contain non-utf8 bytes.

~~~
heinrich5991
Yea, also found that limitation of the regex library pretty annoying. But
_conceptually_ this has nothing to do with string slices being different from
byte slices... It might encourage it though.

~~~
kbenson
FWIW, I think getting the underlying string representation right (and
relatedly how it interacts with byte buffers/slices) is really hard. So far, I
think Perl 6 probably has the most well thought out structure with regard to
that, but they took a decade and a half and _lots_ of testing to come up with
what they did. Then again, how it works in Perl 6 is also a function of how
the language functions, so it wouldn't be a a direct mapping of concepts, but
there are some really good ideas there.

------
djb_hackernews
I've poked at the language a bit over time and while I don't think I'll ever
"get" rust, I can say the folks in #rust on irc.mozilla.org are friendly and
helpful, which can't be said for all languages.

~~~
dman
Is this you -
[https://en.wikipedia.org/wiki/Daniel_J._Bernstein](https://en.wikipedia.org/wiki/Daniel_J._Bernstein)
?

~~~
nickpsecurity
Best not to even ask such a question as it invites dishonesty. Just look up
the contact information and compare. Here's DJB's:

[http://cr.yp.to/contact.html](http://cr.yp.to/contact.html)

------
EugeneOZ
Keep going! Thanks to all contributors for their work on this awesome language
and crates.

I use Rust for web as REST API and I'm absolutely in love with this language.
Maybe first steps were little bit steep, but it's worth it :)

// cargo run!

~~~
smt88
Would you be kind enough to list the crates that your API is using?

~~~
EugeneOZ
Of course. Special thanks to their authors ;)

    
    
      [dependencies.iron]
      version = "0.2.*"
      
      [dependencies.bodyparser]
      git = "https://github.com/iron/body-parser.git"
      
      [dependencies.redis]
      git = "https://github.com/mitsuhiko/redis-rs.git"
      
      [dependencies]
      router = "*"
      rustc-serialize = "*"
      plugin = "*"
      rand = "*"
      toml = "*"
      rust-crypto = "^0.2"
      hyper = "*"
      r2fa = "*"
      urlencoded = "*"
      regex = "*"
      
      [dependencies.mysql]
      default-features = false
      features = ["socket"]
    
    

And soon here will be added "rusoto".

~~~
dbaupp
(Life will be easier for you in future if you avoid * constraints, by using
things like `router = "0.1"` instead. This means authors can make breaking
changes to their crates without breaking you, e.g. router might make a major
change and release 0.2.0, but you'll still be able to run `cargo update`
without risking picking that up.)

~~~
codys
For many projects (that aren't depended on by other projects), adding versions
in Cargo.toml is just more work without payoff. Specifically, if one is
already shipping Cargo.lock (in a way that it is used), `cargo update
--precise` (in some form) allows the same granular control.

I'd also note that while theoretically restricting versions works, in practice
having multiple versions of a single crate within a rust project often leads
to build failures due to crate A having a public API that uses types from
crate B, and crate C using both, but not getting the same version of B that A
got. This leads to type errors at build time.

~~~
tatterdemalion
With `cargo add` its even easier than adding them with "*" dependencies. Just
`cargo install cargo-extras` to get `cargo add`, and then `cargo add
my_dependency` and it will add the dependency with the most recent version as
the requirement.

~~~
steveklabnik
I and others think cargo-add is a good candidate to move upstream into cargo
itself for exactly this reason.

------
zcdziura
What do you mean when stating that applications aren't supported for
developing around libcore?

~~~
steveklabnik
Specifically, there are two 'weak lang items' that need to be defined. Lang
items are not yet stable. So while you can build libraries with only core, the
final binary still needs to be compiled with nightly.

For now.

Furthermore, you can use a no_std library with an application that uses std
just fine. The use case not quite covered is "I want an application with no
standard library at all, period."

~~~
JoshTriplett
> Specifically, there are two 'weak lang items' that need to be defined. Lang
> items are not yet stable.

What two specific items? By "lang item" here, do you mean roughly "symbol", or
something else entirely?

~~~
brson
'lang item' does roughly mean symbol, but they have their own Rust syntax to
communicate their existence to the compiler. Lang items are special functions
/ types that can only be defined once globally, must be defined for certain
features to work. They are how the standard library hooks into the Rust
language for a variety of purposes, and to a large extent what makes it
possible for Rust to define much of its functionality in libraries instead of
in the language.

The two lang items that are absolutely required but not defined in core are
'eh_personality' and 'panic_fmt'. Read more here: [http://doc.rust-
lang.org/nightly/book/no-stdlib.html](http://doc.rust-
lang.org/nightly/book/no-stdlib.html)

------
criddell
I have a question for Rust fans: how do you deal user interaction? Do you have
a favorite user interface library? Do you separate the UI from the program and
communicate either via IPC or http+html? If you don't care about cross
platform capabilities, is there a great library on the platform you do care
about?

------
nikolay
I think Rust badly needs an AWS SDK as a lot of systems software is being
written now in Go...

~~~
dikaiosune
Like this?

[https://crates.io/crates/rusoto/](https://crates.io/crates/rusoto/)

Haven't tried it yet (backwaters don't usually look kindly on AWS :) ), but
that looks like what you're talking about. There are a _ton_ of libraries for
Rust these days (relative to the amount of time since 1.0, at least).

~~~
hrez
Yes, except with ec2 and tons of other missing AWS services support.

~~~
Perceptes
Rusoto maintainer here: The different AWS services are added to Rusoto through
code generation based on service definitions from the Python project botocore.
We're in the process of moving our code generation from Python to Rust, and
once that's in place, we'll be adding remaining services pretty quickly.

~~~
curun1r
It's too bad that compiler plugins / libmacro are still so experimental. Once
they're stable, the kind of code generation you're doing as a separate step
could be done entirely at compile time. I did some preliminary tests with an
eye towards an AWS crate, but decided that a crate that only works with
nightly and frequently breaks is of dubious value. Still, it's cool that the
Rust compiler will eventually be extensible enough to compile json directly.

Anyways, thanks for Rusoto. It's going to make a project I'm starting next
month significantly simpler!

~~~
Perceptes
Yes, I've been following this issue closely. Nick Cameron is working on a
revamped macro system that will replace the current compiler plugin system for
the purposes of syntax extensions. It's probably still gonna be a while,
unfortunately, since it'll take some time to get that kind of stuff vetted and
baked into the language.

Here are some recent posts by Nick on his experiments and progress (in order
of publication):

* [http://www.ncameron.org/blog/macro-plans-syntax/](http://www.ncameron.org/blog/macro-plans-syntax/)

* [http://www.ncameron.org/blog/procedural-macros-framework/](http://www.ncameron.org/blog/procedural-macros-framework/)

* [http://www.ncameron.org/blog/libmacro/](http://www.ncameron.org/blog/libmacro/)

Pretty much all of his recent blog posts are on the topic, so it's worth
browsing through all of them if you're interested.

------
dikaiosune
May the libc event never occur again (at least, I think it was libc with the
wildcard dependencies). That's great to hear.

~~~
steveklabnik
Yes, that was part of it. It was a complicated situation, from which we all
learned a lot.

(For those not familiar: the libc crate went from 0.1 to 0.2. Many people were
depending on libc="*". Cargo allows for multiple copies of a library with
incompatible versions. But the releases were incompatible for a reason... it
caused problems. This fix is one of the things we're doing to address it,
there's more coming in the future.)

------
sdegutis
After trying to understand some Rust, it seems to me that it's just as
complicated as C++, from the programmer's perspective. Was I mistaken in
thinking that being simpler to program in than C++ was one of the goals?

~~~
echelon
I don't use C++ or Rust in a daily context, but I can say without a doubt that
Rust is the easier language to grasp. I don't have to decide anything about
headers, linking, Makefiles, etc. to get things up and running; I can declare
dependencies in Cargo.toml and it _just works_.

The Rust standard library feels so much more modern and easy to use than the
STL. The documentation is fantastic, too.

C++ pointers, casting, OO, templates, and all the billion other language
features feel like traversing down a rabbit hole. Rust is small enough to grok
in a day. The syntax is incredibly expressive and a joy to use.

~~~
bjz_
> Rust is small enough to grok in a day

I would say it is _far_ easier to learn how to write good systems code in Rust
than C++, but saying you can grok it in a day is a bit optimistic. On the
surface level, perhaps. But the semantics of the type system can take longer
to internalise, depending on one's background.

------
wyldfire
W00t, I made the contributor list!

~~~
steveklabnik
Thank you for your contribution!

~~~
wyldfire
lol it was a paragraph or so of a doc revision. But I'll take it. :)

~~~
steveklabnik
Every bit helps, seriously. No contribution is too minor, in my opinion.
People think that only big stuff counts, but my career is literally built off
of paragraphs of doc revisions.

------
kevindeasis
So, I've recently tried to figure out what rust it's been getting lots of
attention in HN.

So, it allows you to have safety and control. I thought that is very neat.

I've got three questions for experts. One, what type of applications is Rust
intended for?

Two, I like JS because I can code in the client, and server in one language.
Will there ever be a web server framework for rust and an api that allows me
to modify the dom?

Three, what are your predictions for the future of rust?

~~~
glennsl
1\. Rust was designed for low-level systems programming, and in particular the
multi-threaded kind, where performance and memory control are important. So
things like web browsers (it's been developed alongside development of the
Servo web browser), games, operating systems, embedded systems etc. It's
basically a better C++.

2\. There are already several web frameworks, in various stages of earliness.
See [1]. I don't think it will ever be a good idea to write Rust client-side
though (even though I believe there is an emscripten backend for it, so it's
possible).

3\. I see a very bright future for Rust. It could use some ergonomic
improvements (but it's miles ahead of C++ even now, mind you), but is
otherwise a very well designed language that fits very snuggly in its niche.
And it has some very strong backing from Mozilla. I expect it will slowly take
over large amounts of territory from C++ and possibly from C, as these
developers start to realize the benefits of Rusts safety guarantees. It's also
quite unique in that its safety entices many higher-level (python, ruby, C#
etc.) developers into trying system programming, which could be really
transformative to the system programming scene. For example, one thing that
has already come out of this is the cargo package manager, which is similar to
npm, bundler etc. but (before cargo) had yet to find its way down to the lowly
systems programmers. Many (former?) C++ developers actually tout it as one of
the major benefits of Rust.

[1] [http://rustyprogrammers.com/2016-01-web-
frameworks](http://rustyprogrammers.com/2016-01-web-frameworks)

~~~
Cshelton
With Web Assembly coming in the near future, Rust will actually be a very
great choice. Right now they are targeting c/c++, but Rust of course will be a
great alternative.

Do note that, for many things on the web, JavaScript is PLENTY fast. It's when
you are doing crazy things like CAD in the browser, it'll be amazing.

------
posborne
Is there a good way to look up no_std crates? For crates written with no_std,
is there a keyword we should be tagging things with?

I have several crates providing access to GPIO/SPI/I2C under Linux and would
like to put together a roadmap for having the interface to these types of
devices that is portable to various platforms and devices (e.g. Linux as well
as Zinc, ...).

------
jedisct1
I'm still looking for an _easy_ way to write servers that can handle many TCP
connections with Rust.

The native thread/connection model quickly shows its limits, and is very slow
on virtualized environments.

mio is as low-level as libevent and just as painful to use.

mioco and coio are very nice but blow the stack after 50k coroutines.

------
hokutosei
I'm not using rust for heavy/intense db/API stuffs currently w/Go. but in the
future, i'm looking on using it as Main language for our API's. I like how
safe it is and its explicitly.

------
jinst8gmi
Just waiting for official Jetbrains/IntelliJ support...

------
lasermike026
Very exciting!

------
imakesnowflakes
I have looked at both Rust and Go. What I have felt is that, Rust is too
restrictive. I mean, you have to fight the compiler a lot harder then you have
to do in Go. Some times, for example, if you are writing device drivers or
real time embedded programs, then that is great.

But for web services? I think it is overkill. I think Go strikes a nice
balance. I would love to be convinced otherwise though. So please tell me,
what am I missing?

~~~
pjmlp
\- expressive language, including support for FP

\- no need to copy-paste code for generic algorithms

\- proper dependencies management

