
2017 Rust Roadmap - muizelaar
https://github.com/aturon/rfcs/blob/roadmap-2017/text/0000-roadmap-2017.md
======
cheepin
I read through the Rust book, and the problem I was having with it and the
other docs is that it was hard to map the Rust concepts with what actually
runs when it is compiled. For a language that touts "uncompromising
performance", it was difficult for me to find performance characteristics of
the underlying abstractions and std library (for example, are algebraic data
structures just tagged unions or does the compiler do more fancy things with
them? What about iterators?). I'd really like to see a "Rust for C/C++ devs"
guide that helps you figure out if you were using [some C++ feature] the way
to get that behavior/performance with idiomatic Rust.

Another thing that is still tricky for me is figuring out when I should use
'unsafe' blocks in my code. Is it to be avoided if at all possible, or should
I go there any time the 'safe' part of the language is making it difficult to
express what I want? The meme that Rust is C++ without SegFaults and or race
conditions is a bit misleading since the actual guarantee is that you don't
get SegFaults or Race conditions outside of Unsafe blocks, and any nontrivial
project will make use of unsafe blocks.

~~~
pcwalton
> for example, are algebraic data structures just tagged unions

They're tagged unions with no implicit heap allocations. I guess we should at
least document that in the reference (though we don't want to overspecify,
because we do some tricks in the compiler to try to avoid leaving space for
the tag if we can). But I don't think it'd be a good idea to document this
straight away in the book: the goal is to make Rust easy to pick up, and
adding more information than necessary when introducing enums (which a lot of
folks will only see for the first time in Rust) isn't going to do people any
favors.

> What about iterators?

The documentation for Iter explains this pretty well, I think:
[https://doc.rust-lang.org/stable/std/iter/](https://doc.rust-
lang.org/stable/std/iter/)

It even shows the exact implementation of (basically) Range, to give you an
idea.

That said, it would probably be worth calling out that most iterators are
guaranteed not to allocate. Note, though, that that isn't a hard-and-fast
constraint that implementors of the trait have to abide by—you can make your
own iterators and implement them however efficiently or inefficiently you
like.

> The meme that Rust is C++ without SegFaults and or race conditions is a bit
> misleading since the actual guarantee is that you don't get SegFaults or
> Race conditions outside of Unsafe blocks, and any nontrivial project will
> make use of unsafe blocks.

They'll make use of unsafe blocks _transitively_ , by using unsafe code in the
standard library or well-tested crates. Think of these unsafe blocks as part
of the compiler: you trust the compiler to generate correct machine code when
you type "a + b", so likewise you trust the standard library to do the right
thing when you say "HashMap::new()".

It is not the case that most projects should use unsafe _themselves_
everywhere: that usually just makes life harder. The primary exception is if
you're binding to C code, in which unsafe is unavoidable.

~~~
kalkin
Speaking of "guaranteed not to allocate", is there a way that you could
express that in a type? Seems like that might be nice to have.

~~~
tatterdemalion
Not in Rust's type system. In a pure language, you could have some sort of
"Heap" monad similar to the "IO" type in Haskell.

~~~
Too
So Rust has no way to mark side effects and global dependencies of functions?
Allowing singletons in a language that is supposed to be safe sounds like a
huge design flaw.

~~~
steveklabnik
Mutable statics are unsafe to access or update. You can use interior
mutability with something like a Mutex to get a mutable-but-not-to-rustc
value, which is safe.

Systems programming languages need this kind of functionality.

~~~
Too
Putting a mutex around a global variable doesn't change the fact that it is
still a global variable.

Memory access might be safe but you get spaghetti code and combinatorial state
explosion due to all the potential side effects.

 _Allowing_ singletons for edge cases is fine but with no proper way to
_enforce_ it except code review you really have now idea what the underlying
code might potentially do.

~~~
steveklabnik
I agree with you that using globals as sparingly as possible is good, but your
original claim was about safety, so that's what I focused on.

------
adamnemecek
I would also suggest taking a page out of Apple's playbook and providing some
official sample apps like
[https://developer.apple.com/library/content/navigation/#sect...](https://developer.apple.com/library/content/navigation/#section=Resource%20Types&topic=Sample%20Code).
Reading the books is one thing, but seeing the patterns actually used is
another. You don't need as many as Apple, only a couple really, but make sure
they are well written and straddle a couple of use cases. And like go crazy
with the idioms, I want to see the most idiomatic Rust code.

When learning a new platform, it's always frustrating having to hunt for good
code. I actually find these similarly important as docs (maybe even more
because I tend to reference good open source for much longer than docs).

~~~
nrjames
I agree with the example apps. Some annotated source would be great, too.
Something similar to the way dc.js annotates this example: [https://dc-
js.github.io/dc.js/docs/stock.html](https://dc-
js.github.io/dc.js/docs/stock.html)

~~~
dumindunuwan
+1 for usinf dc.js type examples. I wished many times "Rust by example" could
follow this type of detailed explanations and complex examples.

------
joshmarlow
I would love to see Rust with a REPL. I use Python professionally a lot and
have done a fair amount of OCaml in my spare time and both have excellent
REPls in the form of `ipython` and `coretop`. Quick experiments _with auto-
complete_ is incredibly helpful for exploring a language. That's the only
thing I really miss from those languages; when I want to wrap my head around a
bit of syntax or a library feature in Rust, I build out a quick little
experiment and see if it compiles and behaves as I expect it. With a good
enough REPL, that's unneeded.

~~~
Cyph0n
Scala does this extremely well too. Not sure whether or not a snippet will
work? Run 'sbt console' and you're in a REPL with all of your code imported.

~~~
joshmarlow
Something like `cargo shell` or `cargo repl` that automatically imports
whatever crate you happen to be working in would be _fantastic_.

If you had something like that, I imagine you could probably write a Kernel
for Jupyter which would be a huge win.

------
dikaiosune
It's important to note that this is an RFC which has been proposed, and
there's likely to be a good deal of discussion and revision before it's
merged/adopted as the official 2017 roadmap.

The conversation can be followed/joined/whatever here:
[https://github.com/rust-lang/rfcs/pull/1774](https://github.com/rust-
lang/rfcs/pull/1774)

~~~
collinmanderson
"accordance with RFC 1728" \- could they have chosen a naming scheme so their
documents are not confused with the _real_ RFC's? Even RRFC 1728 would
helpful. Or maybe just #1728?

~~~
tatterdemalion
Lexical scope. You should assume an RFC cited in a Rust RFC is a Rust RFC,
you're in the Rust RFC scope. If an IETF RFC is cited in a Rust RFC, it won't
be ambiguous.

------
leshow
Awesome. I have used Iron a few times to write small web services, but I can't
wait for Rust to really have a strong story for the backend. If that happens
it'll be the first language I reach for whenever I need to write a backend.

I think it has a lot of great bonuses already. It's language ergonomics are
that of a high-level language, yet it is extremely fast, and I can be very
confident in my code if it compiles.

Rust is one of my favorite languages, keep up the great work guys.

~~~
berntb
Are you saying that Rust, a system programming language, can compete with the
scripting languages in speed of developing features?!

Or are you saying that it is a pleasure to use, so you'll use it for smaller
backends where development speed isn't that critical?

(Asking, not flaming. :-) )

~~~
tatterdemalion
> Are you saying that Rust, a system programming language, can compete with
> the scripting languages in speed of developing features?!

I'll say it. At work, the backend is Rails, and I am a Rust contributor in my
freetime. I am in the early stages of working on a framework for web apps in
Rust & I believe it will be comparatively productive to Rails. Only your code
will be faster and many bugs will be caught at compile time.

~~~
berntb
Bold. :-) I do hope you're correct.

(Given a modest test suite and checking parameters at external API interfaces,
scripting languages didn't have much problems with bugs that could be found at
compile time, imho.)

~~~
tatterdemalion
> (Given a modest test suite and checking parameters at external API
> interfaces, scripting languages didn't have much problems with bugs that
> could be found at compile time, imho.)

Not my experience _at all_.

~~~
hinkley
I've given JavaScript about six years to prove that tests make up for static
analysis and all I've learned is that we need MORE static analysis.

I've met about four people in a dozen years that write better tests than me,
and pretty much everyone else is writing garbage. And when I look back at my
own I'm never satisfied.

Essentially the only thing worse than no tests is thinking you have test
safety when you don't.

Particularly, negative tests in a dynamic language are easy to write but are
virtually guaranteed to break at a later date without anyone noticing, because
you are now looking in the wrong spot for a piece of data.

~~~
Can_Not
Coming from dynamic land, including JavaScript, one thing I noticed about
rust's types and compile time safety was how it would probably eliminate 90%
of the unit tests needed for an equivalent JavaScript program, essentially
allowing the programmer to focus on less pendantic and more useful-looking
unit tests.

------
fixxer
Awesome to see the learning curve addressed with such high priority.

I like Rust and I'd like to use it more, but I generally lean on Go or C for
writing anything that needs performance. I can't quite get past the awkward,
fumbling stage with Rust. Go, on the other hand, was really easy to get
acquainted with and not too substantial of an effort to get to strong
expertise. I've been able to teach Go to junior devs with no background and
hand off projects within a couple weeks. Rust is awesome, but fits in a very
different bracket IMO.

~~~
pcwalton
It's important to note that Go and C have very different design goals from
Rust. Go was never designed to have zero-cost abstractions (garbage collection
being the most obvious outcome of this, but there are many others), and it has
a runtime. C was never designed for safety and security, memory safety or
otherwise. In short, Go sacrifices performance and C sacrifices safety, while
Rust's goal is to sacrifice neither.

Addressing the learning curve of Rust is important, but we aren't going to be
able to do it by adopting concepts from Go or C. By and large, they just don't
apply.

~~~
kjksf
It's also important to note that Go was designed for programmer productivity
and Rust wasn't.

GC is incredible productivity boost which is why no recent language (except
Rust) does manual memory management.

Compile times in Go are a fraction of Rust compile times, which is another
productivity boost.

Go gives you one good way to do concurrency, Rust believes in tyranny of
choice.

Without mentioning that you don't paint the whole picture, just the parts that
are favorable to Rust.

~~~
pcwalton
> It's also important to note that Go was designed for programmer productivity
> and Rust wasn't.

Rust was absolutely designed for programmer productivity. Source: I was one of
the designers.

> GC is incredible productivity boost which is why no recent language (except
> Rust) does manual memory management.

That's true, it is a productivity boost. But it also has a cost. Rust didn't
want to pay that cost, especially when the same mechanisms are useful for
preventing data races. (In fact, removal of GC was something that happened as
a consequence of the data race freedom features; it wasn't a design goal from
the beginning.)

> Compile times in Go are a fraction of Rust compile times, which is another
> productivity boost.

And rustc performs much more optimization. Again, a tradeoff.

> Go gives you one good way to do concurrency, Rust believes in tyranny of
> choice.

That's untrue. Go has threads, channels, mutexes, condition variables, and
atomics. Rust has threads, channels, mutexes, condition variables, and
atomics. The only thing I can think of that Rust has that Go doesn't is, like,
SIMD, and I'm sure your comment wasn't just referring to SIMD.

~~~
jdf
> The only thing I can think of that Rust has that Go doesn't is, like, SIMD,
> and I'm sure your comment wasn't just referring to SIMD.

Just to clarify, are you referring to Rust using SIMD by way of LLVM, or by
way of being able to use SIMD primitives / intrinsics directly in Rust code?

The former works much better than I had anticipated. I've been surprised by
the extent that my iterator code ends up vectorized without me doing much
work.

The latter does not give me warm Rust feelings today. There's a SIMD crate,
but it doesn't look maintained and only works with the nightly compiler
releases. I didn't think there was any stable way to do inline assembly, so I
think linking C is my best bet here?

~~~
Manishearth
> The latter does not give me warm Rust feelings today. There's a SIMD crate,
> but it doesn't look maintained and only works with the nightly compiler
> releases. I didn't think there was any stable way to do inline assembly, so
> I think linking C is my best bet here?

Yeah, the person formerly working on simd is no longer able to contribute to
random open source projects. It's still something the Rust team wants to make
stable, just not right now. SIMD is a bit complicated because you need to
address target support in a straightforward way.

------
cm3
> Rust should integrate easily with C++ code

The day that Rust manages to have always up to date Qt bindings that do not
force you to make compromises compared to the C++ API, I think the C++ support
will be at a comfortable level. Right now there are fresh efforts in the Rust
and Haskell camps to solve this cleanly in a modern way. It would certainly
help if the consumption of C++ APIs via llvm (which is used a lot byt Rust)
was made a first class feature like you can import and export C APIs.
Exporting C++ classes is a whole different story and may not map in any
reasonable way to Rust modules or crates.

~~~
bch
I'm ignorant of Rusts ABI/requirements, but can the C ABI be used as a lingua
franca, or are there necessary facilities that are unsupportable there?

~~~
dikaiosune
FFI through a C ABI is how Rust <-> C++ currently works, but IIUC it's quite
limiting when one might want to make use of C++ specific features. Especially
important when a given C++ project doesn't have a fully-featured C API, or any
C API at all.

------
rjammala
One way to improve productivity of Rust with respect to the learning curve is
to add more screencasts/tutorials to
[http://intorust.com](http://intorust.com)

I found the existing ones very helpful and instructive.

~~~
dj-wonk
Thanks, I'm watching now. I recommend it.

"The primary author ... and the narrator on the screencasts, is Nicholas
Matsakis ... Niko has been involved in Rust since 2011 and is a member of the
Rust core team as well as the leader of the language and compiler teams"

------
kalmar
This is a better link, as it will include the discussion:
[https://github.com/rust-lang/rfcs/pull/1774](https://github.com/rust-
lang/rfcs/pull/1774)

------
EugeneOZ
> Rust should provide a solid, but basic IDE experience

After using IntelliJ IDEA plugin [1] (works in free community version too), I
don't understand what else people need :) Plugin is pretty powerful. Also
Racer works great in VS Code and other editors.

> Rust should have a lower learning curve

Rust is easy enough to learn, the only issue is a steep start. After couple of
months everything is not harder than JS and smart compiler actually makes me
more and more lazy :) So I think only thing we need is books/articles to help
people switch from other languages, to help them overstep initial
difficulties.

[1] [https://github.com/intellij-rust/intellij-
rust](https://github.com/intellij-rust/intellij-rust)

------
ifhs
It's amazing how much the rust team has nailed it. they know exactly what the
problems are. I do not know of any other team as talented as rust. Then
language is also quiet brilliant. I have started rewriting all my code in rust
the days. It just makes sense.

------
gravypod
> 1 in 19: lack of IDEs (1 in 4 non-users)

I expected that to be higher actually, but that's still the only reason I
don't use the language. I've come to rely heavily on IDEs. Whether right or
not it's a huge factor in my decision to wait for the language.

~~~
unfamiliar
What kind of IDE support do you typically use that isn't handled by a modern
text editor (such as go to definition, variable renaming, find and replace,
etc)? I'm starting to use CLion for my C++ work now, because "go to
definition" is much more reliable than most editors can manage with C++ code,
but I find that most of the fancy refactoring features like extracting
functions or subclasses are not used often enough to be really useful.

~~~
gravypod
The features I need are:

    
    
       - Refactoring Support (rename variable, class, function)
       - Code Folding
       - Automatic type checking
       - Automatic error detection (tells me when syntactical or other errors are made)
       - Built-in documentation loading/display on hover of cursor. 
       - Same thing as above except with any documentation I add myself on a function. 
       - Debugger with comment overlay of values (like PyCharm)
       - Dependency management/Building/Deploying all a *button* (not 10 commands) away 
       - VCS integration
       - Automatic code formatting 
       - Automatic code "cleaner" (change for (int i = 0; i < arr.length; i++) to an expanded loop for example)
       - Automatic import cleaning
       - Automatic project creation for basic use cases (console, GUI, maybe a web framework)
       - Change CWD/environment variable for running the program
       - GOTO definition 
       - A Graphical User Interface (Graphical being the biggest requirement) 
    

Outside of all of those, there is a much much much more important feature:
Auto Complete. A smart auto complete. An autocomplete that understands the
type system and the function's return types.

For instance if I am typing:

    
    
       String sub = someString.
    

It shouldn't recommend "length()" as well as in the case of:

    
    
       String lengthStr = Integer.toString(someString.
    

It should recommend things that return an integer. This needs to be fast and
needs to be non-case-sensitive. Also, if I am typing

    
    
       Lis
    

It should recommend List, ArrayList, etc in that order with the closest thing
up front. It should also in the recommendation screen show documentation, a
link to official documentation, and possibly an example of how to
initialize/use the code. If something isn't imported and so it's not currently
usable, if the user clicks enter or whatever on the auto-complete screen you
should import it. If it has that, and has that working quickly, and has that
working completely it's a "real" IDE in my book. That list is just "wants",
this one thing is a "need"

If I had that for rust, I'd switch over to rust as my main language. Anything
that doesn't have something like that will never compete with Eclipse in ease-
of-adoption in my book.

------
unfamiliar
>We asked both current and potential users what most stands in the way of
their using Rust, and got some pretty clear answers:

>1 in 4: learning curve

>1 in 7: lack of libraries

>1 in 9: general “maturity” concerns

>1 in 19: lack of IDEs (1 in 4 non-users)

>1 in 20: compiler performance

>None of these obstacles is directly about the core language or std; people
are generally happy with what the language offers today. Instead, the
connecting theme is productivity—how quickly can I start writing real code?
bring up a team? prototype and iterate? debug my code? And so on.

I don't really see how this conclusion was reached from that data. The
"learning curve" is almost certainly a reflection of the language being a
little esoteric and the demands of the borrow checker. And "lack of libraries"
is partly a comment on the ecosystem, but also partly shows that std is
obviously lacking for some needs. Finally, "general maturity concerns" refers
to worries that the language or std will keep changing, as is assumed they
have not been perfected yet.

Those are the top 3 concerns and to me, both seem to relate directly to the
language or standard library.

~~~
bpicolo
I also don't think library maturity is necessarily the only problem that makes
working with libraries difficult at time. You can get burned pretty easily by
someone not having e.g. Send + Sync on an essential library data structure.
(Though maybe there's a way around it other than forking?) That metadata ends
up being very important

~~~
burntsushi
Send + Sync are automatically implemented for a type X if all of X's
constituents are also Send + Sync. In practice, this means that unless you're
using unsafe code, Cell/RefCell or Rc, then the Right Thing will just happen
automatically. If you are using Cell/RefCell/Rc/unsafe, then you need to think
carefully about your synchronization story anyway, so it's typically not
something you just forget to do.

For more details, see: [https://doc.rust-
lang.org/std/marker/trait.Sync.html](https://doc.rust-
lang.org/std/marker/trait.Sync.html) and [https://doc.rust-
lang.org/std/marker/trait.Send.html](https://doc.rust-
lang.org/std/marker/trait.Send.html)

------
geodel
Overall it looks good.

When I look at this :

"Production use measures our design success; it's the ultimate reality check.
Rust takes a unique stance on a number of tradeoffs, which we believe to
position it well for writing fast and reliable software. The real test of
those beliefs is people using Rust to build large, production systems, on
which they're betting time and money."

I see a little bit of haste towards production use. From 'Rust 1.0 is out just
last year' to 'We really need successful production use', It does some to be a
push from management to justify continued investment in Rust project.

~~~
aturon
The intent wasn't to say that we should be seeing big production use _right
this second_ , but rather to set out an overall "north star" for work on Rust.
The investments in Rust today should be made with an eye toward driving or
enabling production use in the future.

I've updated the RFC to clarify this; thanks for the comment!

------
dj-wonk
Re: "Here are some strategies we might take to lower the learning curve: ...
Improved docs. While the existing Rust book has been successful, we've learned
a lot about teaching Rust, and there's a rewrite in the works. The effort is
laser-focused on the key areas that trip people up today (ownership, modules,
strings, errors)."

Yes, please. I get better every day with Rust. I'd ask that the docs on
lifetimes be improved with more elaboration on the ideas and more examples.
Frankly, I still find the details confusing, so I can't offer more particulars
right now.

------
agentgt
For what it's worth I hope serde or whatever default serializers are improved.
I had some serious issues trying to combine libraries because of serde
changing too much. Albeit this was about a year ago so it probably is fixed.

Second it would be nice to see some best practices not just for libraries but
application development. What to do and what not to do. Maybe a cookbook or
even... design patterns. I had a hard time trying to figure out if I should
embrace closures or go traits (at the time closures were not working as well
so maybe this is not an issue either).

~~~
steveklabnik
We have already landed the underlying things Serde needs to be better in
nightly Rust, and it should be stable soon.

I would love to see such a thing as well; I wonder if we're not quite old
enough to have said patterns really gel yet. We'll see if someone comes up
with something.

------
coherentpony
I'd also like to see a push towards applications in scientific computing.

~~~
synparb
First class multi-dimensional arrays with natural indexing syntax would be a
huge draw. You get that in Numpy, Julia, Fortran and it is extremely powerful
in terms of expressing the types of operations that are common across many
scientific domains.

------
zzzcpan
Focus on high-performance servers, async I/O, C integration is very promising.
These are Go's weak points, could become a good alternative and a direct
competition for Go.

~~~
wahern
Care to elaborate on Go having weak async I/O support?

~~~
Scarbutt
It doesn't have it, Go uses a different concurrency model.

~~~
wahern
I manage a Lua framework that wraps Linux epoll, BSD kqueue, and Solaris
Ports. Lua provides asymmetric coroutines, which the framework uses as logical
"threads" for execution state. A Lua coroutine is a just a couple hundred
bytes of state, likely smaller than a JavaScript/NodeJS closure all things
considered, though slightly larger than a Lua closure.

Lua also has very clean and elegant bindings to C. Lua is designed to be
implemented in strict ISO C, yet also to make the C API a first-class citizen
--not a hack around the VM like Python, Ruby, etc. The one caveat to this
equivalence is coroutines--when a coroutine yields and resumes, it can't
revive any C invocation frames (e.g. when Lua calls C calls Lua). So the C API
to invoke a Lua routine can take a callback and cookie. If the VM yields and
then resumes a coroutine across a C API boundary, the "return" from the Lua
routine invocation happens by invoking the C callback. (See lua_callk in the
manual.)

From the perspective of C, as well as the kernel, this is a classic
asynchronous I/0 pattern. From the perspective of Lua-script code, everything
is transparent.

I take it that because Go implements light-weight threads (goroutines, which
is likely a pun on coroutines) you do not perceive it as offering async I/O.
And yet from the perspective of the implementation as well as the kernel it's
classic async I/O using epoll or kqueue, whether goroutines are bound to a
single CPU core or not. The send and receive operations on a Go "channel" are
very similar to the resume and yield operations of classic routines, and
semantically identical in the context of async I/O programming (because with
both goroutines and async I/O there are no guarantees about the order of
resumption).

Do you equate async I/O with callback-style programming? Do you think
callback-style is somehow intrinsically less costly in terms of CPU or memory?
I would dispute both of those contentions.

~~~
yazaddaruvala
I think the difference is in how people define "async I/O". When saying "Go
doesn't use async I/O", what that really expands to is: "While Go can use
epoll[0], it doesn't abstract over epoll optimally." i.e. There is a
difference between "zero-overhead async-I/O" and goroutines.

I'm not an expert but I'll try to describe why goroutines would have overhead
(Someone correct me):

The posterboys of async I/O are Nginx and Redis. I'm probably simplifying, but
this is the basics of how they work are: When using epoll directly, the
optimal way to store state per connection is using a state machine. The state
machine is usually some C-like struct which the compiler can give a fixed
size. Each state machine is then constructed to have X memory, and is unable
to grow. In theory (I don't believe anyone actually does this), if the program
was comfortable with some fixed connection limit, you could fit all of these
state machines on the program's stack, and require no heap allocations.

Meanwhile, Go's routines have stacks which can grow. Each goroutine has some
max size, and some initial size, both of which are pre-set by the Go-lang team
(I'm sure they are configurable). Since the stack can grow: They have to be
heap allocated, and need to be either segmented or copied when they need more
space[1]. Additionally, there is "internal fragmentation" because a growable
stack needs to be consistently overallocated, which is a "waste" of memory.

Very quick Googling suggests that Lua has growable stacks as well.

[0] FWIW: Go could use M:N scheduling of kernel threads to achieve goroutines.
Which is another reason why saying goroutines are async I/O could be
incorrect. I don't know how its actually implemented.

[1] [https://blog.cloudflare.com/how-stacks-are-handled-in-
go/](https://blog.cloudflare.com/how-stacks-are-handled-in-go/)

------
sotojuan
Really nice! I try to learn as little languages at the same time as possible
so sadly I have no time for Rust at the moment, but it looks like it'll only
get better.

------
Dowwie
Idiomatic Rust guides would be very helpful

------
petters
My personal code base is C++/cmake and Python.

It would be really nice with a way to slowly start writing code in Rust
instead.

~~~
azdle
You might be interested in this post about using rust with python:
[https://blog.sentry.io/2016/10/19/fixing-python-
performance-...](https://blog.sentry.io/2016/10/19/fixing-python-performance-
with-rust.html)

------
serge2k
> Rust should have a lower learning curve Rust should have a pleasant edit-
> compile-debug cycle Rust should provide a solid, but basic IDE experience

I know the list isn't necessarily prioritized, but these 3 feel backwards.

A good IDE will provide can help facilitate easier edit/compile/debug cycle
which makes learning the language faster because it's cheaper (time wise) to
figure things out.

~~~
steveklabnik
They're not ordered.

