
Two Weeks of Rust - omn1
http://www.matusiak.eu/numerodix/blog/2016/1/10/two-weeks-rust/
======
taliesinb
"No segfaults, no uninitialized memory, no coercion bugs, no data races, no
null pointers, no header files, no makefiles, no autoconf, no cmake, no gdb.
What if all the problems of c/c++ were fixed with one swing of a magic wand?
The future is here, people"

It certainly is.

The advantages over C++ seemingly never end. I'd add to the list: rigorous
portability, non-broken macros, ADTs and pattern matching, a careful language
stability protocol, standard test and doc tooling, flexible namespacing via
visibility and modules, the _absense_ of vast lacunas of undefined behaviour,
simple numeric promotion rules, meaningful compile-time errors for generic
code. Plus things already mentioned in the post like Cargo.

People tend to focus on the safety side of Rust, but as impressive to me is
just the... solidity on all these other axes. If you stripped out lifetimes
and the borrow checker you would still have an incredibly compelling
alternative to C++.

~~~
petke
Languages come and go but C++ remains. I wonder if this one will be different.

Im not trying to be a jerk. Just voicing my concerns. Learning a new language
and producing code in it is a huge commitment. It better be around in 10
years. Will it still be as clean and simple, or will it have grown complex.
What if Mozilla stops sponsoring it?

C++ is 35 years old. It has stood the test of time. I would not be surprised
if it was still popular in 35 years time, when I retire. There is so much C++
infrastructure code in this world, that its not going anywhere.

In the meantime C++ has evolved. I cant remember the last time I had an
uninitialized memory, null pointers, or buffer overflow -bug. Those are low
level C problems. If you avoid C-style programming and stick with modern C++
(RAII, value semantics, STL, boost, etc) you wont get them.

C++ is changing fast. In the next few years we are getting high level
concurrency and parallel language support and libraries (no more low level
thread problems), we are getting modules (no more preprocessor hacks), compile
time reflection (no more manual serialisation), concepts (no more ugly error
messages), ranges (no more cumbersome iterators), and a whole lot more.

And finally there is "C++ Core Guidelines" which aims to be checkable by
tools. So you get a warning when you are relying on undefined behaviour.

I think C++ is still the future.

~~~
blub
It's funny to see how these languages topics always explode. I read it when it
had about 20 comments and then it predictably devolved into a mess of hype and
comparisons.

Anyway, I think your strategy is sound. Rust is a young language and I would
be pleasantly surprised to see code written today still compile in five years.
I got bit by this with Swift v1 in a little app. When 1.x came, it failed to
correctly transform the source and the whole thing was a major PITA to update.
Completely soured me from using Swift.

I can understand why Mozilla wants to use Rust. It solves a problem for them,
they largely control how the project evolves and can plan for it. To me, the
big questions are what will happen to Rust if Mozilla changes strategies
(Persona, Thunderbird, FirefoxOS) and whether Mozilla will continue to be a
successful organisation. Personally, I root for them, in spite of their recent
missteps.

I think Rust might be a good choice now for language aficionados and early
adopters which can afford to waste time in exchange for other potential
benefits. I would absolutely not use it to bring a project to market or for an
OSS project which has a long term vision. In 5+ years I expect such a decision
could be worth revisiting.

~~~
pcwalton
> Rust is a young language and I would be pleasantly surprised to see code
> written today still compile in five years.

We have had a code stability promise for months now in 1.0. So what you are
saying here is that you do not believe that Rust will adhere to what it very
publicly planned to do. Do you have specific reasons for this?

> To me, the big questions are what will happen to Rust if Mozilla changes
> strategies (Persona, Thunderbird, FirefoxOS) and whether Mozilla will
> continue to be a successful organisation.

Rust has a core team and community that overlaps a lot with, but is very much
not identical to, Mozilla. Probably most Rust users aren't even Firefox users.

Rust is not "Mozilla's language". It's the Rust community's language.

~~~
comex
> We have had a code stability promise for months now in 1.0. So what you are
> saying here is that you do not believe that Rust will adhere to what it very
> publicly planned to do. Do you have specific reasons for this?

Since 1.0, Rust has in fact had multiple significant stable-breaking compiler
changes, not to mention that, among other things, adding any new method to a
trait or type in the standard library has the potential to cause breakage. The
official code stability promise has not been violated by these changes only
because it's riddled with exceptions.

~~~
pcwalton
> Since 1.0, Rust has in fact had multiple significant stable-breaking
> compiler changes, not to mention that, among other things, adding any new
> method to a trait or type in the standard library has the potential to cause
> breakage. The official code stability promise has not been violated by these
> changes only because it's riddled with exceptions.

This is essentially the same as any other language. Adding a new method to
traits or types can _also_ break JavaScript, the other example you gave.

In fact, I know of one such example where code _was_ broken in the wild
because of new methods being added, and we did not revert the change. Marijn
Haverbeke's winning js1k entry relied on the 4th and 7th letters (or something
along those lines) of every CanvasRenderingContext2D method being unique,
because it compressed code by renaming the canvas methods with what was then a
perfect hash function. A new Firefox version was released months later that
added new methods and broke the code. That was deemed an acceptable piece of
breakage, and Rust's policies are very similar.

Anyway, the vast majority of breakage that we've seen so far was due to the
libcpocalypse. This was an issue with people not specifying specific versions
of libraries they depended on, not the language.

~~~
comex
Here's another example with less trivial breakage, which was reverted:

[https://www.fxsitecompat.com/en-US/docs/2015/string-
prototyp...](https://www.fxsitecompat.com/en-US/docs/2015/string-prototype-
contains-has-been-renamed-to-includes/)

Unless you mean to refute the idea that JS doesn't break _anything ever_ \-
which it clearly does, _occasionally_ , but proof-of-concept golf code that
intentionally takes fragile shortcuts isn't the best example.

...But JS has moved away from monkey patching builtin objects for good reason,
whereas Rust tends to be relatively promiscuous in adding methods to other
people's types via trait impls. This isn't bad per se, but I do think it
creates bigger compatibility risks.

------
goodplay
I'd like to echo the author in that Cargo is the best language package
manager/build system I've had the pleasure to use.

However, there is one serious problem with Cargo's packages: They simply
aren't authenticated. Cargo's developers acknowledge this issue and there is a
proposal to amend it by adopting the TUF [1]. but this issue doesn't seem to
enjoy the attention it deserves.

As a person living in a country that increasingly edging towards going the
Kazakhstan route where all secure traffic will be MITMed, simply relying on
transport security as a way to secure crates is not sufficient. and that's
ignoring compromises due to server security failures. At present, my only
options are to include the entire dependency tree in crate or avoid
dependencies altogether.

Even ignoring my problem (which wouldn't effect a large number of rust
developers), Mixing transport security with authentication and integrity
shouldn't happen in vital infrastructure like a language package system.

There are other problems like not representing system libraries that a crate
depends on in the project manifest, but unauthenticated crates are a ar more
serious problem.

[1]:[https://github.com/rust-
lang/crates.io/issues/75](https://github.com/rust-lang/crates.io/issues/75)

~~~
wuch
Is there a language package manager that you would consider a good role model
in this respect?

~~~
goodplay
I'm not aware of any language-specific package manager that gets close to
having developer-package authentication, but chromium's add-on system comes
pretty close as it requires add-ons be signed by the developer's private key
(at least, that was the case before I stopped developing for it). I believe
android's packages are secured in a similar fashion.

~~~
eurg
IIRC Common Lisp's asdf-install did use GPG signing from developers; IIRC-
again, most people disliked it. Now quicklisp exists, which does _not_ use
GPG; a quick google didn't reveal any info on package authentication. Maybe a
lisper can chime in?

------
EugeneOZ
I'm working with Rust 2 months. In my opinion, pluses:

\+ Compiler with very helpful error messages;

\+ Cargo is the best package manager in the universe;

\+ Result<> is the most correct way to return results from function, I dreamed
about it;

\+ Community of smart and friendly people.

Minuses:

\- Functions are not first class citizens - you can't return function as
result;

\- Violation of "explicit over implicit" rule in methods declarations:
argument self/&self is implicitly omitted in call, but exist in signature.
Because of this, for example, you can't use method of class as request handler
in Iron, you need closure wrapper with same order and count of arguments. Pure
ugliness;

\- Often you need just add lifetime definition to satisfy compiler, without
doing anything with this lifetime anywhere else in code;

\- Extremely verbose syntax;

\- Rust has exceptions (panic), and you can't catch them. And with promised
panic::recover you'll have limitations of supported structures;

\- Errors handling encourages copy-pasting;

\- Syntax is not intuitive, especially when traits and lifetimes comes into
declaration - in such cases you can look at own code and think "I hope at
least compiler can read it";

\- Nested structures is pain;

\- Lack of optional and named arguments, lack of predefined values in
structures;

\- Too few modules for web. Just 1 module for MySQL (thanks to it's author -
actively maintained);

\- Usage of safe code can lead to out-of-bounds errors, with thread panic
(hello to vec macros).

And I still think it's best language we have:) Biggest advantage - most of
errors can be found on compilation step. But price is all of these minuses.

~~~
masklinn
> \- Functions are not first class citizens - you can't return function as
> result;

Of course you can: [http://is.gd/YASF8T](http://is.gd/YASF8T)

One issue is that closures don't really have their own types, so to return
closures you need to use trait objects, which means dynamically-sized types,
which means you have to box them

\- Rust book on the subject: [https://doc.rust-
lang.org/book/closures.html#returning-closu...](https://doc.rust-
lang.org/book/closures.html#returning-closures)

\- Example of returning a boxed closure:
[http://is.gd/pJIqiu](http://is.gd/pJIqiu)

> Violation of "explicit over implicit" rule in methods declarations: argument
> self/&self is implicitly omitted in call, but exist in signature.

That's a debatable assertion, in a method call, the self/&self is the subject,
the part before the dot.

> Because of this, for example, you can't use method of class as request
> handler in Iron, you need closure wrapper with same order and count of
> arguments.

By "class" what do you mean? Because AFAIK it works on struct methods
[http://is.gd/xu6HRc](http://is.gd/xu6HRc)

> Rust has exceptions (panic), and you can't catch them

That's because Rust doesn't have exceptions, it has panics, they're not a
general-purpose error-reporting or control-flow mechanism.

> lack of predefined values in structures

[http://doc.rust-lang.org/std/default/trait.Default.html](http://doc.rust-
lang.org/std/default/trait.Default.html)

> Usage of safe code can lead to out-of-bounds errors, with thread panic
> (hello to vec macros).

Safe rust doesn't mean no panics. `panic!` is safe rust.

~~~
EugeneOZ
println() is not Iron request handler, you gave wrong example. Signature
matters.

I don't see how you can declare field if structure to have default value
65535, even with Default trait.

I posted opinion not to argue and really frustrating to see downvotes for
opinion. Make discussion more constructive.

~~~
masklinn
> println() is not Iron request handler, you gave wrong example. Signature
> matters.

println is not relevant here it only shows the result of the call, the point
is that you can use a method as a function, I expect the issue is elsewhere
(but not having used Iron, I wouldn't know where).

> I don't see how you can declare field if structure to have default value
> 65535, even with Default trait.

Implement Default then call it when instantiating struct:
[http://is.gd/2YSoKd](http://is.gd/2YSoKd)

> I posted opinion not to argue and really frustrating to see downvotes for
> opinion. Make discussion more constructive.

Er… I didn't downvote you? I just replied to some of your objections which I
assume is what you expected?

~~~
EugeneOZ
> Implement Default then call it

It's far from "default values in struct declaration". I mean this:

struct X { i:u32 = 5, j:u64 }

------
grabcocque
I never found the borrow checker to be that hard to work with. For a start, if
you're developing a systems language in a modern way, (say C++11/14) you're
already used to thinking in terms of move semantics, const refs and shared vs
unique pointers.

Secondly, Rust's compiler gives INCREDIBLY detailed explanations of what the
borrow checker doesn't like, where the conflicting scopes begin and end, and
helpful suggestions of what to do to make it work.

~~~
wuch
On one hand it indeed feels like more strict version of move semantics in C++,
on the other hand it also prohibits what is central idea of STL - having
multiple mutable references to the same object (almost all algorithms operate
on at least two iterators from the same container). It seems there is no place
for STL-like library in Rust - which is quite regrettable.

~~~
yati
Most algorithms that I use from the C++ stdlib take `container.begin()` and
`container.end()`, and use the latter to check for the end condition in the
main loop. Given that Rust has the `Iter` trait which allows you to iterate
straight through any type that implements it, I do not see the point in having
multiple mutable references. I mean, sure, it is useful sometimes, but it also
brings in a lot of headaches with it :)

~~~
wuch
Right, in most cases you could replace begin(), end() with whole container /
range, when considering arguments to the algorithm function. Though, there are
some exceptions, like std::rotate, or just cases where you want to place
result in the same container.

Looking from the perspective of implementation of those algorithms, it is no
longer that simple and single iterator is rarely sufficient, consider:
std::unique, std::reverse, std::partition, std::sort, std::inplace_merge to
name a few, where there is much more to it than just checking for end.

~~~
Tyr42
Some of those do show up on iter.

[https://doc.rust-lang.org/std/iter/trait.Iterator.html](https://doc.rust-
lang.org/std/iter/trait.Iterator.html)

But some of the more specialized ones don't work using just iter. But on the
other hand, no iterator invalidation.

~~~
wuch
The crucial difference I had in mind, is that those from C++ work in-place.
Returning a new collection as a result poses no problem for either of those
languages. Writing specialized version for each collection is also possible,
but with STL you don't have to do that.

Maybe it would be possible to implement those algorithms in Rust in terms of
ranges like in D, instead of iterators? I will have to try and see.

~~~
Gankro
The problem with Ranges is you _can 't_ trust anything they tell you about
bounds, and they _can 't_ trust you about bounds, so every access has to be
checked. This hurts in algorithms like binary search and sorting (which are
some of the few algorithms that don't work for iterators).

Ultimately though, there just hasn't been a lot of demand for ranges.
Iterators and slices do most of the work people care about. We actually had
tried to make iterators more like ranges back in the day, but we tore it out
because no one cared. To this day you can't sort a VecDeque, _and no one has
ever bothered us about it_.

~~~
wuch
I did indeed look a little bit about previous attempts at collections in Rust,
but didn't find too much about ranges. What would be good keywords and place
to look for, any hints?

It seems to me that you can go quite far with mutable but mutually disjoint
ranges - which is more or less what slices do for vectors currently. They are
also safe, because you can only split them into subslices (which borrow
ownership), but not extend them (what could potentially create overlapping
ranges). Moreover as long as there is any range to given container, you can't
perform operations that could invalidate derived ranges (things that
reallocate vector, etc.)

Range checking don't seem that bad, because in most cases it is not about
trusting what a range tells you, but range trusting itself which is fine. Take
you example of binary search, if range would know how to split itself in the
middle, it wouldn't really have to do any bounds checking. For sorted ranges
maybe operation like lower_bound or upper bound would be great primitives, or
single operation that encompasses both situations:

    
    
      let (lower_range, equivalent_range, upper_range) = range.split(&value);
    

Of course, in general as you point out, you would have to pay a price of
bounds checking for random access.

As far as I can see, this should be sufficient to implement algorithmic part.
What I still find hard to do, is to modify collections based on resulting
range. For example, how to write equivalent to following C++ code, that first
moves consecutive duplicates to the end of array, and then erases them from
container:

    
    
      std::vector<int> v { ... };
      v.erase(unique(v.begin(), v.end()),
              v.end());
    

I have a few ideas, which mostly boil down to following: create a description
of operation to be executed, but is executed only after all ranges have
returned their ownership over collection. But so far this interface have not
been fully satisfactory.

------
lifthrasiir
The submission and expanded discussion at /r/rust:
[https://www.reddit.com/r/rust/comments/40d8ca/two_weeks_of_r...](https://www.reddit.com/r/rust/comments/40d8ca/two_weeks_of_rust/)

------
crncosta
In 2016 I would like to see a Rust frontend for GCC, with LTO support and all
the list of target backends GCC support.

~~~
goodplay
There used to be gcc front end during Rust pre-1.0, but it seems that the
language was too unstable for it to keep up.

A gcc front-end would be great, if only to show that the language spec is
mature and complete enough that other implementations can be built on it.

------
purpled_haze
I'm a little skeptical after first reading "Disclaimer: I'm digging Rust. I
lost my hunger for programming from doing too many sad commercial projects.
And now it's back. You rock, Rust!" and then seeing comparisons to Python in
the text where it seems like the author might prefer writing in Python,
especially with all of the Rust cons listed.

Is the author saying Rust is a breath of fresh air from C++ or from all other
programming languages? Ruby was my breath of fresh air for a while, but lately
I've not been enthusiastic about any language or framework, really, so I
curious how great Rust really is these days.

~~~
omn1
As somebody who comes from the Python community just like the author, I can
relate to some of his points:

"In Python I try to avoid even having dependencies if I can, and only use the
standard library. I don't want my users to have to deal with virtualenv and
pip if they don't have to (especially if they're not pythonistas)"

This rings so true to me. Package management in Rust is much better than in
Python.

Also, Rust feels a bit like "pythonic systems programming". I mean that it
just feels like the right tool for the job. And it might feel a bit verbose in
the beginning, but in reality it's explicit and precise. It feels pretty
ergonomic just like Python.

Isn't it fantastic that people start comparing Rust to more high level
languages like Python and Ruby instead of C++ or C? It says a lot about the
language design and its goals.

~~~
StavrosK
Am I the only one who doesn't find Python's dependency management a problem?

"pip install -Ur requirements.txt" and you're done. A virtualenv is one extra
line.

~~~
dikaiosune
Very easy when you're in control of the machine (and are a developer). A while
back I had written a tool in Python purely for myself (mistake #1), and relied
heavily on dependencies which needed to compile C extensions (mistake #2), and
then it turned out to be very useful for others on my team (mistake #3), which
consisted of mostly non-developers (mistake #4) using Windows/Mac (mistake
#5). I've since left, and while they supposedly have a dev who can help them
install the tool, I'm still running it for them on a regular basis because I
don't want to be mean and they haven't sorted it out.

Python's dependency management is great for devs who have a GCC toolchain, but
it really sucks when you need to share code with non-developers.

~~~
fanf2
It's good to be nice like that but you should still be getting a consultancy
fee.

------
beerbajay
I also tried rust for a couple of weeks, but holy hell is it ugly. Why improve
on c++ and not improve the syntax or containers? It's like python never
existed.

~~~
shmerl
_> It's like python never existed._

Whitespace / indentation used for scope delimiting in Python is a bad idea.
No, thanks. I'm glad Rust isn't using anything like that.

~~~
beerbajay
I agree that whitespace scope delimiting is a bad idea, but I was thinking
more about general syntactical clarity. Just because C++ uses every possible
typographical symbol doesn't mean rust should. Simple example which had me
WTFing:

    
    
        use std::collections::{HashMap, HashSet};
    

Are all those ::s and {}s adding to clarity?

Why are there no easy to use initializers for maps? It's 2015! I have to do:

    
    
        let mut map = ::std::collections::HashMap::new();
        map.insert("a".to_string(), "b".to_string());
        ...
    

or some such nonsense. Oh, right, I have to write a macro and basically learn
another language. Also, using the macro system for basic things like println
just seems bonkers to me; use macros when you really, really need to do
something special, not everywhere.

~~~
steveklabnik
Println is a macro because it needs to be: it does compile-time checking of
the format string.

~~~
shmerl
Do you think it's feasible to implement initializer lists in Rust, or there is
some language limitation which makes it hard?

I.e. I'd prefer to write:

    
    
        let v: Vec<i32> = {1, 2, 3, 4, 5};
    

Instead of

    
    
        let v = vec![1, 2, 3, 4, 5];

~~~
dbaupp
Initialistion from initializer lists in C++ basically rely on the = operator
being able to do arbitrary work, e.g. allocations and generally manipulating
the heap in arbitrary ways. Rust tries to avoid implicit performance sinks
like that, and so doesn't have constructors in the same manner as C++.

That said, in future, it is likely to be possible for things like
`Vec::from_array([1, 2, 3, 4])` and `HashMap::from_array([[1, 2], [3, 4]])` to
work.

~~~
shmerl
Rust doesn't need to take the C++ approach to implement it, but it can still
use the same syntax which is simply much neater. HashMap::from_array([[1, 2],
[3, 4]]) looks horrible in comparison.

Exact implementation is another question. That's why asked, whether it's
feasible or it's something hard to fit into the language.

~~~
dbaupp
I don't see how Rust can get the same syntax as C++ without having the
implicit performance sink I mentioned: creating vectors and hashmaps needs to
allocate, and so letting this happen implicitly is not great. In fact, the
syntax was pretty much the whole meat of my comment.

~~~
shmerl
Why can't Rust do what it does already with macros, except using the simpler
syntax described above? I.e. that syntax can mean explicit allocation (it's
just a short form for it).

------
amelius
How does Rust interoperate with C++? For example, would it be easy to
integrate V8 into a Rust project?

~~~
mseri
With specific C++ features there is still a lot of work to do, however the C
FFI is solid and simple to use if that is enough for you (see e.g.
[https://doc.rust-lang.org/book/ffi.html](https://doc.rust-
lang.org/book/ffi.html)).

Interfacing Rust and python, ruby, node can be quite simple in fact (micro
demo for node: [http://calculist.org/blog/2015/12/23/neon-node-
rust/](http://calculist.org/blog/2015/12/23/neon-node-rust/))

------
cikey
Nice to see rust getting along. Coming from C and C++ is really dig the new
ideas for better and more save low level languages.

What really bugs me, is what the author describes as being'concise'. Shortcuts
like fn, pub or vec, in my oppinion, hurt readability more than they help me
to write code faster. But maybe thats just my brain, or lack of time using
rust.

~~~
lifthrasiir
As far as I understand, the length of keywords and common identifiers is
roughly proportional to the reciprocal of frequency. `fn` and `pub` are used a
lot; `return` is less used (Rust returns the last expression by default);
`continue` is even less so, and it's familiar to C/C++ programmers.

~~~
cikey
thanks a lot for the info. I can perfectly see the reasoning behind it. Still,
i find it harder to read. But as i said, that can be a lack of practice.

------
pjungwir
I've been experimenting with Rust for a few weeks, and I really like it, but I
hope they improve how you write functions that return iterators. I can't find
all the discussion now, but here is some of it:

[http://stackoverflow.com/questions/27535289/correct-way-
to-r...](http://stackoverflow.com/questions/27535289/correct-way-to-return-an-
iterator)

[https://www.reddit.com/r/rust/comments/2h26cj/functions_retu...](https://www.reddit.com/r/rust/comments/2h26cj/functions_returning_iterators/)

[https://github.com/rust-lang/rfcs/pull/105](https://github.com/rust-
lang/rfcs/pull/105)

[https://github.com/rust-lang/rfcs/pull/1305](https://github.com/rust-
lang/rfcs/pull/1305)

Reading those RFCs can be frustrating, where a discussion goes on for over a
year and people add more and more wants to an idea until it sinks. Same thing
with the discussion about a `yield` keyword:

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

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

It reminds me of the JCP in Java. I guess every standards committee is like
this, and I actually like how careful the Rust team is about extending the
language---but I think we should be prepared for it to evolve slowly. Right
now I feel like Rust's pace will be more like Java than C#.

~~~
steveklabnik
One reason you're seeing slowness is that the compiler is undergoing an
internal refactoring that will _completely change_ the way these kinds of
features will be implemented. So they're effectively on-hold-ish until after
that's done.

Also, this particular feature seems easy from a usage perspective, but the
type theory behind it is actually pretty intense, and there's multiple
possible ways of doing it. So those need to be explored, discussed, and
figured out.

This feature is one that's of high importance, and is coming sooner rather
than later.

~~~
pjungwir
Thanks for the reassurance! Sorry if I sound critical. There will always be a
tradeoff between speed and purity---Java vs C# is a actually a pretty
interesting case study---and for a language that is as experimental as Rust, I
think taking your time to make careful decisions is the right approach. I'm
just trying to prepare myself for the wait. :-)

Also thanks to you personally for your work making Rust accessible to us
newbies. The book is very nice, and a few weeks ago you were really quick to
answer a question of mine on IRC. Keep up the good work!

~~~
steveklabnik
No bad feels taken!

You're welcome. I hope the next iteration of the book is even better :)

------
vitriol83
The article is comparing Rust principally to Python (a new dynamically typed
language) and C++ (an old statically typed language). It's certainly plausible
that it can bring benefits over these.

More interesting to me would be comparing it to a new-ish multi-paradigm
language, of which there are many right now (e.g Swift, OCaml, Haskell, F#,
Scala). It seems like in practical applications these newer FP languages will
be much more productive than Rust, as memory management is much simpler.
Rust's principle of zero-cost abstractions is great in theory, but can't think
of many applications where it's the limiting factor except perhaps embedded
devices and kernel development.

~~~
scott_s
Rust is designed as a _systems programming_ language, so it was explicitly
made for situations where zero-cost abstractions and explicit memory
management matter. Embedded devices and kernel development are two places that
matters, but there are more: web browsers, web servers, databases and runtime
systems all come to mind.

~~~
vitriol83
I don't think that one can necessarily equate systems programming with manual
memory management (see e.g. Go). It's true that manual memory management will
(probably) be more efficient and more predictable, but ultimately depends on
how important that is in your application.

~~~
Narishma
Go is not a systems programming language (as the term is usually understood),
and Google labelling it that way when they first introduced it is unfortunate.

~~~
vitriol83
Citation needed. Plenty of people regard high-level languages as nonetheless
suitable 'systems programming'. This is the first FAQ on golang.org! See also

[https://ocaml.github.io/ocamlunix/](https://ocaml.github.io/ocamlunix/)

~~~
tarblog
I would define the term "high-level language" to mean that it's possible to
write programs in the language without needing to worry about the specific
hardware that the program is running on.

I would consider systems programming to be things like writing operating
systems, drivers, high-performance native applications (for many difference
definitions of high-performance), and databases.

I consider rust to be a high-level language and I further consider it to be
suitable for systems programming using my definitions.

However, I don't consider go to be suitable for a lot of systems programming
tasks because it has a significant runtime system that includes a garbage
collector. Just because they describe themselves as a "systems programming
language" doesn't mean that I believe them (at least as far as I understand
that term). That said, there are certain applications that work fine with GC,
and in those cases it can be a very nice way to achieve memory safety without
programmer burden.

------
loaaa
Future? well, 10 year later, quantum computer maybe come to reality which is
much much faster than current computers. At that time who will care about Rust
or C++? The easiest language will win.

~~~
tarblog
You shouldn't expect quantum computers to bring a "free-lunch" speedup the way
that clock-speed increases did for such a long time.

------
markque
When you've worked with languages with a garbage collector, having to worry
about memory management and all that jazz seems a step backwards just to save
a few cycles. You want to be focusing on the domain problem not the machine.
(This is directed at people who use Rust as a general purpose lang, im sure
it's good for low level systems programming).

~~~
amelius
It would be nice if the language itself provided hooks (or whatever you would
call it) to implement your own GC (or, of course, to use a library for that
purpose). I have not yet encountered such a language, though (LLVM has a low-
level language that allows it, but I don't know the details).

~~~
viraptor
Rust does that. Rc type is implemented in Rust. ([https://doc.rust-
lang.org/nightly/std/rc/struct.Rc.html](https://doc.rust-
lang.org/nightly/std/rc/struct.Rc.html)) There's also arena allocation
available as a library. ([https://crates.io/crates/typed-
arena/](https://crates.io/crates/typed-arena/)) You can add your own memory
management abstractions as libraries.

~~~
amelius
Very interesting.

I'm also interested in one particular kind of memory abstraction: abstracted
access to memory mapped files. Here the problem is that the base address of
the memory mapped area might change whenever you perform the mapping. And you
would like to use standard data-structures (like maps, lists, etc.) inside the
memory mapped area.

~~~
viraptor
Mmaped files are already available it seems
([https://crates.io/crates/mmap/](https://crates.io/crates/mmap/)), although
I've never tried it. You'd have to implement the interesting structures on top
of that yourself however.

~~~
vardump
Relative pointers are great in memory map data structures. All pointers are
relative to current offset. That way it's almost always also possible to get
away with just 32-bit pointers -- you get +- 8 GB range.

A library that can do that in Rust would be great.

~~~
agrover
A signed 32 bit "offset" value gives you 2GB in each direction, not 4GB in
each direction.

~~~
vardump
Only if you use byte aligned relative pointers. For data structures you don't
need better than 32-bit aligned pointers. So you get +- 8GB relative offsets.
It's not all that unreasonable to use 64-bit or even 128-bit alignment, for
+-16 GB and +-32 GB respectively.

