
What is Rust and why is it so popular? - xurukefi
https://stackoverflow.blog/2020/01/20/what-is-rust-and-why-is-it-so-popular/
======
alxlaz
Over the last couple of months I've been slowly, but steadily playing with
Rust. I work on embedded systems and while it's gaining traction only slowly,
it feels to me reasonably likely that we'll be seeing non-trivial applications
in the next 8-10 years. I doubt that we'll see it used for low-power/resource-
constrained firmware, but lots and lots of embedded systems are now bulky
Linux boxes with years of uptime, and I can see Rust making inroads there.
It's not a bad idea to be ready for this, just in case it turns out to be a
revolution.

Honestly, I like it, and for all the non-hyped reasons.

Like ownership. Lots of us in the embedded space aren't so impressed by the
extra memory safety because, if you allocate all your memory statically, there
are fewer ways to screw things up with references, and it's a lot easier to do
bounds checking, so fewer bugs slip in. Not that "even fewer" isn't good, it's
just that the impact is less dramatic than in application code.

 _But_ : the borrow checker still pesters me about something I've written
every once in a while. And every once in a while, what it pesters me about is
a data race that would have definitely bit me in the back sooner or later. It
has no security implications, I guess, and it wouldn't crash my program, but
it's still wrong. Yay!

Or like traits, which are just so refreshingly sane.

Lots of people are hung up on security and segfaults, and spend far less time
talking about a far less categorical property: the conventions that Rust
enforces make it easier to write correct code. _Sometimes_ it's not
straightforward code, mind you, but "works right" trumps "fits in a single
line" in my book...

In many ways, Rust is what C++ could have been if it had not been designed by
saying yes to everything. I guess it's not _there_ yet, but there's a chance
it might be.

On a more, uh, philosophical note, I think it's pretty cool that our industry
has been granted a second chance in this regard. We've already been given Ada,
and we missed the chance to adopt it on a wide enough scale to make a
difference. Maybe we won't miss this chance.

~~~
pron
I think that Rust's approach to safety -- soundly eliminate UB in safe code --
comes at the high cost of complexity. This affects how easy it is to write
custom compilers (very important in the embedded space), but it is also not
necessarily the best way to reduce bugs. For some, this cost is acceptable,
and I'm sure some people may even welcome the high-level-looking code [1] that
Rust and C++ support, but I think there are better ways, ones that are more
appealing in low-level ("systems") programming in general and the embedded
space in particular:
[https://news.ycombinator.com/item?id=21970987](https://news.ycombinator.com/item?id=21970987),
[https://news.ycombinator.com/item?id=22021237](https://news.ycombinator.com/item?id=22021237)

Rust is without a doubt a (much) "better C++" but I'm not sure a better C++ is
necessarily what systems programming needs most.

[1]: Not that _writing_ that code is as easy as in a high-level language, nor
does it offer the same level of abstraction as high-level languages, where
changing the details of the implementation does not affect the API and its
clients, but it _looks_ high level, or "expressive", on the page.

~~~
derefr
> This affects how easy it is to write custom compilers (very important in the
> embedded space)

Is there a reason you’d write your own Rust compiler _frontend_ , rather than
just letting rustc generate LLVM IR as it does, and then writing your own LLVM
arch target? None of the Rust complexity leaks over into the LLVM IR it
generates; it looks just like the LLVM IR that e.g. clang generates.

~~~
Const-me
> None of the Rust complexity leaks over into the LLVM IR it generates

The leakage even triggers performance issues in compilers:
[https://users.rust-lang.org/t/5-hours-to-compile-macro-
what-...](https://users.rust-lang.org/t/5-hours-to-compile-macro-what-can-i-
do/36508)

~~~
derefr
No, that's not "Rust leakage", because that misbehavior has nothing to do with
the _semantics_ of Rust as a language. That's the effect of some non-optimized
function-scope-level pattern-matching substitutions that LLVM is applying, as
applied to the user's very large function body. Quoting a reply in that same
thread:

> LLVM is not good at big functions, I have seen this before as well. One of
> the functions you are generating is almost 100,000 lines of Rust code
> including tons of internal control flow.

The same would happen if you wrote (or generated) 100,000 lines of C in one
function body, and fed it through Clang with -O2.

If you're wondering, there's nothing in rustc that makes it implicitly turn
regular code into huge function bodies, either. It's just someone abusing Rust
macros to codegen _badly_ , not taking into account how the granularity of
units of compilation interacts with the time-complexity of optimization
passes.

~~~
Const-me
> that misbehavior has nothing to do with the semantics of Rust as a language.

Macros are part of the language; they aren’t an external code generation tool.

> The same would happen if you wrote (or generated) 100,000 lines of C in one
> function body

Absolutely, but neither C nor C++ makes it easy to generate such code.
Technically doable with C preprocessor, but it’s not easy. C++ templates don’t
normally expand into 100k lines functions either, they can easily expand into
100k small functions.

~~~
jcranmer
People write code generators that emit C/C++ code all the time, and 10KLOC
functions coming from such a generator isn't unheard of. The x86 instruction
selector LLVM generates from tablegen is over 240KLOC, although that's emitted
effectively as an interpreted table, so the actual code size of the function
is much, much smaller.

~~~
Const-me
You’re correct that it’s possible to trigger that performance issue without
Rust.

However, it doesn’t happen with idiomatic C or C++ code. C macros are too hard
to use for that. C++ templates are designed to expand into many small
functions, as opposed to a single huge one.

It was Rust complexity leaking over into the LLVM IR.

~~~
derefr
> C++ templates are designed to expand into many small functions, as opposed
> to a single huge one.

...so are Rust macros. The user was using Rust macros very non-idiomatically.

Also, you don't use C macros to write (large amounts of) C. 90% of the world's
generated C, by volume, comes from, I would say, one of two programs: autoconf
(through m4), or yacc. And both autoconf check stanzas and yacc's inline C
support are easy to screw up in ways that result in horrible code that makes
compilers barf.

Also, to be clear, you're conflating two things with the phrase "Rust
complexity." This thread was originally about the difficulty of _implementing
a Rust compiler_ for a toolchain, which therefore makes "Rust's complexity"
here refer specifically to the complexity of the static-analysis semantics of
Rust that make writing a Rust compiler _frontend_ difficult.

The solution—relying on the existing rustc frontend for the "hard stuff", and
just implementing your own compiler backend to target the embedded
architecture—is not rebutted by a claim that you can write bad Rust code that
makes the _optimization passes_ of certain compilers choke. You wouldn't even
be writing optimization passes. You'd be writing a backend. The optimization
passes are universal. It's the job of the LLVM developers to ensure that they
don't choke on things like this.

And, despite the fact that 100,000-line functions are dumb, it's the LLVM
development team's fault that the optimization passes were written in such a
way that their time-complexity is superlinear in a way that stalls out when
optimizing a function like that. It's not up to the Rust compiler authors to
not emit that type of code, or to somehow prevent you from writing it; it's up
to the LLVM devs to make their optimizer work, and work efficiently, for any
"valid" code. Honestly, if anything, this code—if you could get it—would be a
great integration test to submit to LLVM, for them to work towards passing.

------
potatochup
I work in the embedded space, but the majority of my work is writing
simuators, mathematical models and tests. One of the hidden benefits for us
was that rust is suitable for both resource-constrained embedded code (we use
a lot of C for this) and high-level desktop and cloud based
infrastructure/sim/test code, which we would never consider writing in C.
Serde is amazing, crates.io has so much good stuff on it, C interop is a
breeze. We still use Python/matlab for exploratory and data-sciency work, but
as soon as something lives for more than about 6 months, it usually gets re-
written in rust.

~~~
adamnemecek
Now switch to Julia instead of Python/matlab and you have a really solid
stack.

~~~
locust98
Julia lost its momentum, and for good reasons: insuficient or rushed up
libraries, no option for the generation of standalone executables and general
overselling (by the way, bashing Python at every opportunity didn't lead to a
higher volume of users)

~~~
byt143
Not sure the data supports that ,:
[https://juliacomputing.com/blog/2020/01/06/january-
newslette...](https://juliacomputing.com/blog/2020/01/06/january-
newsletter.html)

------
ChrisSD
I think one of the biggest benefits of Rust is it bakes in static analysis of
code as a first class feature. Which means the language is amenable to
analysis and you don't have to use third party tools to benefit from it.

I also like some of the abstractions. They're clever in their simplicity. For
example, an iterator over an array or vector is simply doing a for loop using
pointers.

~~~
pron
Yes and no. It provides _some_ kinds of (important!) static analysis out of
the box, but at the cost of complexity, which directly adversely affects some
other kinds of (also important) static analysis. For example, there are
_sound_ static analysis tools that guarantee no undefined behavior of C code,
but AFAIK, such tools can at best only work on a subset of C++, because of its
complexity.

Rust goes all out on eliminating undefined behavior, and may well be the best
way of doing that in low-level programming, but eliminating UB is just a means
to an end, UB is not the only source of dangerous bugs, and if the cost of
eliminating it is high it may not be the best way overall of reducing bugs in
low-level languages.

~~~
mcqueenjordan
What is the complexity, and what are its costs? As an active user of Rust, I
haven't seen the (adverse) complexity or its costs yet.

It's worth pointing out that Rust combats more than undefined behavior.
Undefined behavior is a category of bad things that Rust works to eliminate,
but Ownership goes beyond eliminating UB, and eliminates a large swath of
potential logic bugs.

~~~
Thaxll
Programming in Rust is complex, I'm not sure how can argue against that, it is
not straight forward to do simple tasks because of how you need to organise
your architecture with the borrow checker.

Most people that starts using Rust get stuck on issues that you woudn't have
with other languages.

~~~
estebank
In my experience the difficulty of picking up Rust is most pronounced for
people experienced in other languages that have common design patterns that
are discouraged or made impossible by Rust. It's harder to unlearn something
that from your point of view _works_ (even if it had hidden or clear
drawbacks) when you're also having to learn other things simultaneously. Also,
I feel the biggest hurdle Rust has for experienced developers from other
languages is that Rust makes some ineficient code _visible_ , but the way of
optimizing it requires delving into more advanced parts of the language,
frustrating people when they are most "vulnerable". This is where the common
piece of advice for people starting with rust "just clone for now and don't
think about it" comes from: get used to the language first and deal with
borrowing on its own at a later time.

But all of this frustrating learning curve comes to fruition later in when
writing code because the experience is closer to pair programming with the
compiler rather than trying things in a vacuum on your own.

------
psv1
Because the StackOverflow survey which Rust keeps winning defines "Most Loved"
as:

> % of developers who are developing with the language or technology and have
> expressed interest in continuing to develop with it

Because there aren't that many Rust jobs, almost no one _has to_ use it. Which
means people either try it and leave, they like the language and stick around,
or they never use it (the overwhelming majority of developers). This leads to
the Rust being the most loved language by the above definition, which is
completely different from "popular" (as in the title of the OP).

If I make up my own language that I plan to never stop using, even if no one
else ever touches it, I'll get 100% "Most Loved" on StackOverflow's survey.

~~~
marcosdumay
Well, yes. There are plenty of popularity metrics there already, this one is
about something else.

As you said, mainstream languages won't win this one. But it is a valid metric
anyway, and there is plenty of merit on winning it.

~~~
psv1
Think about this - if a bunch of people hate a language and stop using it, the
following year that language's "most loved" score will _increase_. I wouldn't
call that merit, it's just a bad metric.

~~~
marcosdumay
Yes, if people can simply stop using a language, it will not be hated. That's
how it works on real life too.

But most of the time, people can't stop using languages.

------
alerighi
Rust is a great language if you use for what was intended, system programming
and as safe substitute of C and C++.

But it's not the answer of everything, to me it's nowadays abused in a lot of
projects, there are instances of project where using Rust not only doesn't
make a lot of sense but also can be slower than another languages, there are
cases where Go is better, other where Node.js is better, other where Python is
better, other where Java is better, etc. To me the Rust community seems to
want to argue that everything should be rewritten in Rust, just because Rust
solves every problem, while it's not.

~~~
MadWombat
OK, I will bite. If I had to come up with a case where Python is better than
Rust, I would say with rapid prototyping and scientific computing. If you just
want to try a few things out, python has faster development cycle and if you
want to do some super clever math python has better library support. With a
bit more mind stretching, I can make a case for Go with a bit more mind
stretching. If you want to write a massively parallel network server of some
sort you might be better off with Go, especially if you want to use protobufs
and grpc. But what would be the case for Node and Java?

~~~
ggregoire
> If I had to come up with a case where Python is better than Rust, I would
> say with rapid prototyping and scientific computing.

Scripting? I'm not gonna write a 50 LOC single-use script in Rust.

~~~
estebank
I've found that a lot of scripts end up _not_ being single use. In my case
they usually do end up rewritten in Rust, with the benefits of having a proper
--help command from the bother. Once you know enough Rust the obtuse parts of
the language that must exist to cater for the performance critical crowd cease
to be a problem.

------
jdlyga
Rust using the LLVM toolchain is a real plus, which Clang also uses in the C++
world. The Clang and Rust compilers are basically frontends to LLVM, and any
language that compiles using LLVM is translated to IR (intermediate
representation). All code optimization is done on the IR code itself in LLVM,
which both Rust and C++ compile down to before being compiled further into
assembly. That means that the same effort that goes into optimization in the
C++ world for Clang is shared by the Rust community too, and any other
compiler that uses LLVM.

~~~
steveklabnik
We have started doing our own optimizations too: [https://blog.rust-
lang.org/inside-rust/2019/12/02/const-prop...](https://blog.rust-
lang.org/inside-rust/2019/12/02/const-prop-on-by-default.html)

Your overall point is absolutely correct though. We couldn’t have done this
without LLVM.

~~~
galangalalgol
Can you comment on the current state of non-aliased related optimizations? The
issue tracker is byzantine on that one and i can't tell if or to what degree
those optimizations are now done.

~~~
ncmncm
Yes, Rust has the potential to be faster than C, or even C++. But the
compilers' implementations of such optimizations are far too buggy to turn on.

~~~
galangalalgol
All the usual caveats apply, but benchmark game has rusts median already
better than c++, but not as good as c. They are all so close that performance
shouldn't really be a consideration between them I think. You can see g++ vs
clang++ now too.

------
lordleft
The example of an error message in the blog post is the kind of thing that
makes me seriously consider trying out rust. It's excellent. Are most rust
error messages like that?

~~~
shepmaster
Most are that good, or better. I actually debated putting that error because
it's one that doesn't have a "help:" line that actively suggests how to fix
it.

Some errors are admittedly worse, and people like estebank are actively
working on improving them.

~~~
carapace
You're the author of the blog post? Dunno if this is something you care about,
but with JS turned off the code boxes are omitted (with no placeholders or
other clues that something is missing.)

~~~
shepmaster
I am! It's something I care about, but not sure if there's something I can do
about it. The code blocks are powered by a `<script>` tag from GitHub's Gists.
Unfortunately, I don't have the ability to edit that post without Wordpress
completely removing those tags (I don't have appropriate permissions). I can
ask for them to put `<noscript>` tags, but don't know if that will really
help.

------
zozbot234
The more pressing question: What is Rust and why is it so popular on HN?

~~~
rb808
I did an internet search for Rust jobs and it was near-zero. Would be nice but
reality calls.

~~~
GolDDranks
Rust is over the "100% hobbyist" phase, but it isn't still in the phase where
you hire "Rust developers" verbatim. There's an important phase in between:
Rust is being introduced in organizations as we speak, and some people that
were originally hired for some other skills, develop in Rust they picked up
because they were enthusiastic about it.

I am in that position at the moment. We are a multi-language shop, and there's
some components that make sense to write in Rust.

~~~
swsieber
I'm in the same spot. Given the large number of companies who are willing to
state that they use Rust ([https://www.rust-
lang.org/production/users](https://www.rust-lang.org/production/users))
without being able to find openings that are explicitly for Rust, I'd say
you're right.

------
Myrmornis
Wow, that is an extremely well-written brief introduction to Rust. I love the
way it manages to address some more technical (e.g. FFIs, distinction between
borrow-checker and other parts of compiler) but important concepts despite
being so short. Thanks very much Jake Goulding if you're reading.

~~~
shepmaster
You are quite welcome! Hope to see you writing some Rust sometime!

~~~
Myrmornis
I have tried one project so far:
[https://github.com/dandavison/delta](https://github.com/dandavison/delta)

------
baby
Rust for me is the modern C/C++, as much as Go is the modern Java. I see no
point going back to C/C++ now and I will now reject any job offers that deal
with these languages.

------
sethev
I like the fact that Rust has a set of libraries (crates and the standard
library) that provide a lot of the features that you end up re-inventing if
you stick with C. Even C++ is pretty fractured in this regard.

A lot of why this is hard in C/C++ is memory management. Even if you had a
package manager it would be hard to compose libraries together unless they
were designed together (like boost for C++).

~~~
ncmncm
I see that you have no experience with C++ in the past decade. There has been
no fragmentation in C++ resource management since C++11.

~~~
sethev
That's fair - last time i used C++ in earnest was around 2007. Unless they
broke compatibility, it would still be opt-in, though, right? Nice thing about
Rust is that the resource management approach is built-in and enforced by
default.

~~~
ncmncm
Everything in C++ is opt-in.

The Standard C++ Library supports user-managed allocators for all the
containers, heavily used in embedded, low-latency, and real-time applications
to get deterministic performance.

Lack of standard support for user-provided allocators indicates immaturity.
E.g., C++ lacked them until 2011.

------
say_it_as_it_is
I realize /r/rust (Reddit) isn't representative of the entire Rust community
but it's given me a really bad impression of Rust culture.

~~~
psv1
Reddit is great for memes and humour, not much more. Go through any subreddit
on a topic that you know well, and you'll likely be disappointed.

~~~
marcosdumay
/r/haskell is pretty good. /r/python isn't great, but not bad either.

There are subredits of every kind, even great ones. But they change with time.

------
clktmr
As an embedded systems engineer I have very mixed feelings about Rust. There
are a lot of things to like, but Rust seems to miss the point why C++ didn't
replace C and will fail at that for the same reasons. I wish for an economic,
unexciting, conservative evolution of C, which I don't see in Rust. I could
imagine C++ being replaced by Rust, though I don't think borrow checking is
the future of programming.

Another point is the tight integration with cargo, which may lead to the same
dependency problems that npm has. But it will cause significantly more
struggles because of licensing issues. While most npm code was running on
servers, it didn't matter. In the embedded space companies typically insist to
have every library checked by a lawyer before it gets shipped with the
product, which will make cargo essentially useless.

The last one is the community. In fact I think a programming language is to
the largest part about the people using it. And Mozilla sadly created a hype
and a hostile community by aggressively evangelizing the language.

~~~
steveklabnik
Just so you know, there's tools that let you check the entire set of licenses
of your dependency tree, and whitelist/blacklist them. Amazon implemented one
after they started using Rust more seriously.

------
devit
The reason that it's popular is that it's immediately clear that Rust's model
of memory safety without a GC and safe concurrency is the best way to create a
programming language since it unifies the memory safety of GC languages like
Java, the efficiency of C and the concurrency of message-passing systems like
Erlang in a single language that has none of the drawbacks of those systems.

Before Rust, everyone simply assumed that it was impossible to create such a
programming language since it would have otherwise been what everyone used,
and now that it turns out that it's possible, it's clear that it's the best
solution and what should be used in the future whenever possible.

------
amelius
Some problems which are harder in Rust:

[https://stevedonovan.github.io/rustifications/2018/08/18/rus...](https://stevedonovan.github.io/rustifications/2018/08/18/rust-
closures-are-hard.html)

[https://news.ycombinator.com/item?id=16442743](https://news.ycombinator.com/item?id=16442743)

------
janered
Still not hyped. The article does not show anything special or new about the
language that would attract me personally. Type inference -- nothing new and
exists in many other languages. Actually how about compile type inference not
only in function bodies? :) Functional niceness with iterators -- also nothing
new. It can be even more succinct and elegant in Scala for example. But Scala
is not as fast you'd say! Yeah, so what? Python is not as fast as Scala, so.

Control over low-level details is something that exists and should be in any
system-programming language. How is that even a benefit? It is a niche
feature.

Memory safety? You can circumvent it by using "unsafe" and as recent Actix
case shows it can propagate really deep. Should I read the code of any other
Rust library now? What if I am a programmer newbie driven by the hype without
a clue what does memory safety entail? What-ifs... I won't talk about compile
times and the fact that in order to compile some cli tool one has to download
~200mb of rust "stuff". This is simply insane and I refuse to understand how
is this considered to be not an issue.

Rust ecosystem is probably its strongest point right now which is somewhat
funny because it grew out of beliefs in the above "benefits". So, not hyped,
sorry.

~~~
steveklabnik
> Actually how about compile type inference not only in function bodies?

This is actually an explicit design decision; it means that the analysis is
tractable, and that you don't get spooky-at-a-distance error messages.

~~~
jhayward
It's a major detractor, especially for people new to Rust.

The number of times I see people recommend "just cut and paste in whatever
type the compiler said it expected ..." just makes my hair curl.

It also tends to make the code more obscure and unreadable, sometimes
completely so.

------
12thwonder
What influential applications are written in rust? For c++, there is llvm,
chrome, game engines, I feel like c++ is standing very strong in any of these
fields still, why is that? Do u think it’s going to change soon?

~~~
ncmncm
No essential programs are in Rust, in the way that e.g. Docker is in Go, or
your examples in C++, and none are on the horizon unless Cargo becomes a
popular way to build C++ or C programs. Rust is popular to post about on HN,
but the number of people actively coding it is at least 4 orders of magnitude
fewer than mature languages, and the number of people adopting it, likewise:
the number of people adopting C++ is many times larger than the number who
have ever even heard that Rust exists. Those numbers will take many years to
change, if they do. Just as likely, some new hotness will pop up and distract
the early adopters; Rust could very possibly fizzle out. (That would be a
shame unless the new hotness were enough better. Rust++?)

Promoting Cargo as a way to build C++ and C programs could be a way to
establish Rust underpinnings. Cargo is better than most other build systems
now used for C++, and with C++20 getting modules, the fit is improving.

------
0xdead
Does anyone know how StackOverflow measures "love" towards a language?

~~~
shepmaster
> % of developers who are developing with the language or technology and have
> expressed interest in continuing to develop with it

[https://insights.stackoverflow.com/survey/2019?__hstc=188987...](https://insights.stackoverflow.com/survey/2019?__hstc=188987252.63a31c9ff9cab1812469cb8b44e5d5f1.1579486003016.1579544559356.1579630210345.5&__hssc=188987252.1.1579630210345&__hsfp=3030258021)

------
jamil7
I like everything I see and read about rust but I'm unsure where I'd fit it
into my work. Does rust have a future in areas like backend web development or
mobile?

~~~
steveklabnik
My employer, Cloudflare, uses Rust as part of our mobile app for 1.1.1.1. It’s
still rough around the edges, you basically integrate Rust like you would a C
dependency, but it’s been working great.

There are some backend web development deployments at other companies, but the
ecosystem has been changing a lot over the last year. It’s starting to settle
down though. Expect more “Flask” and less “Rails.”

------
pjmlp
I like Rust, however as usual the article fails short of mentioning Ada, and
GC languages that share the same resource management capabilities as C++,
alongside their GC.

~~~
shepmaster
I wouldn't want to mention any language I don't have experience with for the
risk of mis-speaking. I also tried to minimize talking about any specific
language where I could.

~~~
pjmlp
Fair enough.

I just made the point, because from security point of view, we all have to
gain no matter what safe systems programming languages get adopted.

It doesn't need to be Rust vs the others, in what concerns improving the
current state of IT security.

For example, Nvidia is now adopting Ada/SPARK for security critical firmware.

------
SeekingMeaning
Rust newbie here. How do you fix the compile error for the example given? I
imagine it has something to do with transferring ownership, but I’m not too
sure.

~~~
umanwizard
Are you familiar with C++? That example is roughly equivalent to:

    
    
      #include <string>
      #include <iostream>
      #include <string_view>
      
      int main()
      {
          std::string name { "Vivian" };
          auto nickname = std::string_view { name }.substr(0, 3);
          name.clear();
          std::cout << "Hello there, " << nickname << "!\n";
      }
    

which will happily compile, but whose behavior is undefined.

~~~
gramakri
Is the behavior undefined because std::string makes a deep copy of the string?
I thought 'Vivian' would be placed in read-only memory and as long as you
don't modify it, you can hold read-only references to it.

~~~
umanwizard
Yes, `std::string` owns its own copy of the string in typical implementations
(as does Rust's `String` type).

`std::string_view` references that copy. `std::string::clear` destroys it,
leaving the `std::string_view` dangling.

------
vperez
Great article. One nitpick:

> One of the biggest benefits of using a systems programming language is the
> ability to have control over low-level details.

I think this is a misguided conflation of "systems programming" and "low-level
programming", those are separate things. See
[http://willcrichton.net/notes/systems-
programming/](http://willcrichton.net/notes/systems-programming/)

~~~
calibas
Ah, the eternal argument over what qualifies as "low-level". I think we can
all agree it's not Javascript, but beyond that opinions vary greatly and it's
mainly a semantic issue.

~~~
ncmncm
With current languages, we should speak more about range.

C++'s and Rust's ranges stretch from C's at the bottom up to near ML's. Java
is stuck in a little space in the middle.

------
_wldu
It's a programming language and it's not popular.

~~~
sramsay
Any day now, it's going to overtake Logo on the TIOBE index. You just wait.

------
jokoon
This language is awesome, but I'm quite conservative when it comes to syntax.
I don't like how Rust is trying to move away from C when considering syntax. I
tend to prefer languages that can adopt the "C flavor". Python, in my view,
does this very well: its syntax is simple, because it borrows a lot from C in
its "flavor".

Rust is not doing that, and that's a hurdle.

In my view, the "C flavor" is very important because it's a standard of how
people are able to read code. This has nothing to do with the C programming
language, I'm just saying that simplicity is what made C popular and easy to
use. I can understand that Rust brings very nice innovations, but in my view
it should have done so while keeping the "C flavor" as most as it could have.

I admit it's a conservative view, but I tend to believe that a language can be
more easily adopted if at its most basic level, it's simple to read for
beginners. Rust is not great: I'm not talking about its learning curve, I'm
just talking about the "flavor". A language is a tool of expression and
communication, features matter less than readability.

~~~
wtetzner
I'm not sure I follow. Rust syntax seems far more similar to C than Python
syntax does. What parts of the Rust syntax do you feel depart from C-style
syntax?

~~~
jokoon

        fn add2(x: i32, y: i32) -> i32 {
            x + y
        }
    

variable declaration is varname: type, it makes it very hard to read when
declaring arrays or other things

return type is after the paren

the let keyword seems redundant/unnecessary, a little like var in js

Those are good example of "c flavor". I guess they're easier to parse, but
still I would rather have C flavor instead.

~~~
zozbot234
"Very hard to read"? As in, _harder_ to read than the C declaration syntax for
the same types? That's a logical impossibility!

~~~
jokoon
STL containers are pretty easy to read

