
Why we chose Rust - ingve
https://bitbucket.org/blog/why-rust
======
lacker
Rust seems like a fine choice for this use case. However, the decisionmaking
process is a bit odd. They considered Java, Lua, and Python, but not Go? I
think Go is far more "Rust-like" than those other three, ie for people who
want something one notch nicer than C++.

~~~
bluejekyll
While I don’t disagree about the consideration of Go, calling Go Rust-like is
really strange.

I think of Go as more Java-like than Rust-like. But even that’s a hard
comparison. Really, Go is C-like with a garbage collector for memory safety.

Rust is Java or C++-like with a strongly typed compiler, support for generics
(not Go), lifetimes for memory management and no GC (closer to C++), and a
type system that enforces some constraints around concurrency. I guess they
are similar in that they both (by default) create static binaries, but so does
C and C++ (if you want).

Rust and Go seem to get lumped together because they both came on the scene
around the same time, but that is pretty much where the comparison ends.

~~~
apta
> Rust and Go seem to get lumped together because they both came on the scene
> around the same time

That, and that the golang authors at that time claimed that it was a "systems
language". They would later go back on that by attempting to redefine what
"systems language" meant.

~~~
pjmlp
However Go is indeed being used as real systems language, even if the anti-GC
crowd deslikes it.

Examples in production, gVisor, Android GPU debugger, Biscuit and other
research OSes, tiny GO for embedded targets, compiler development.

~~~
apta
I'm not anti-GC :) The language itself though doesn't lend itself well to
larger complex designs however, which I feel precludes it from more
interesting projects, and we can see that by the fact that it's mainly getting
used for "devops" kind of work. Compare that to Rust or Java (e.g. GraalVM) or
C#, the latter two which weren't really advertised as "systems" languages, yet
were used there anyway (maybe real-time Java is something else though)

~~~
pjmlp
I am also a Rust, Java, C#, C++, ML,... kind of dev.

However as safety minded person, I rather see such projects being done in Go
than C, even if I am not a big Go design's fan.

This is actually the area where you will find positive comments from me
regarding Go.

------
nevi-me
This post feels like hype marketing or something. They're telling me what I
already know/believe about Rust, and it doesn't help that it's a guest post.

They're choosing Rust for an embedded usecase, they could have gone into
detail about embedded Rust, and whether they consider the ecosystem to be
mature/sufficient for their needs.

If they didn't consider this (seeing that this feels like a decision made over
theoretical discussions and previous benchmarks), this could come back to bite
them.

------
Waterluvian
Off topic nitpick: I wish Python stopped being added to these kinds of
performance lists. Python isn't a poor tool for those kinds of problems, it's
the wrong tool. And I don't mean, "oops you locked yourself into the wrong
language." I mean that valid Python is Python that calls into a language like
C or Rust when there's performance needs. Numpy and Scipy are, I'm going to
bet, mostly C.

Imagine I did a comparison of the fastest way to cut a board lengthwise. And
my comparison was using a table saw, a jigsaw, a circular saw, and a planer.
Actually, that sounds dumb enough that I kind of want to do that. All the
worst ways to rip a board.

~~~
tylerhou
> Numpy and Scipy are, I'm going to bet, mostly C.

You'd be surprised; About 25% of SciPy (much of the numerical computing
portions) are in FORTRAN. It turns out that decades of compiler/numerical
computing research has made the FORTRAN compiler generate numerical code which
runs faster than GCC/Clang today.

[https://github.com/scipy/scipy](https://github.com/scipy/scipy)

~~~
cyphar
Most people use the GCC Fortran front-end. I think the main reason you get
speed from Fortran is because it provides more hints to the compiler, but also
because generations of PhD students have been optimising compilers for
Fortran-specific performance gains.

~~~
pjmlp
People that care about Fortran performance use Intel, PGI, IBM compilers.

~~~
cyphar
Maybe, but most people who are using numpy are probably using their Linux
distro's package for it (or the pip package) which means it's being compiled
using GCC.

~~~
pjmlp
Depends if they work on HPC environments or not.

------
hackcasual
I don't believe the author works for either Atlassian or on bitbucket, just
uses it.

~~~
kaycebasques
Yes, this appears to be a guest blog. The way that HN only exposes the domain
of URLs led me to believe that Bitbucket was now using Rust.

~~~
Deimorz
Even the full url doesn't make it any more clear, it's just
[https://bitbucket.org/blog/why-rust](https://bitbucket.org/blog/why-rust)

It's strange that Bitbucket is giving urls like that to "guest posts". There's
very little distinction from an official post like this one:
[https://bitbucket.org/blog/take-control-with-branch-
restrict...](https://bitbucket.org/blog/take-control-with-branch-restrictions)

It even shows Ash Moosa (an Atlassian employee) as the author of all the guest
posts when you're on the main blog page
([https://bitbucket.org/blog/](https://bitbucket.org/blog/)), and you can only
see who the _actual_ author is by going into the post individually and looking
for the "guest post by" section at the top of the text (and below _another_
section showing Ash Moosa as the author).

Really bad design if they're planning to put up a lot of guest posts like
this.

------
fwip
I'm surprised to see that Go wasn't considered. While not as lean and mean as
Rust, it also has excellent support for parallelism and safety, while being
easier to get into.

Edit: For clarity, I'm not saying Go is the best choice. But when Lua, Python,
and Java are in the running, it's surprising that Go wasn't. Especially when
the article calls out the learning curve of Rust as a downside.

~~~
0815test
Well, Go has excellent support for parallelism _and_ excellent support for
safety - whereas Rust actually supports parallelism _with_ safety. Rust is
also gaining lots of useful "tweaks" that will make it quite a bit easier to
get into in the future - and the syntax alone is a big draw to former Ruby,
Python etc. programmers, while you really can't say the same about Go. Now, of
course Rust is not for everything (some things really can't be done without
efficient GC, and Go gives you that), but it looks like these Bitbucket users
made a very solid choice here.

~~~
reificator
> _it looks like the Bitbucket folks made a very solid choice here._

Just a heads up, this is not from the bitbucket team. That's just where it's
hosted.

------
kahlonel
If you're gathering data through multiple sensors data from one end, and
pushing it out to network from another, the performance of the 4-core ARM CPU
should be the least of your concerns. You are never going to reach 100% CPU
utilization unless you're doing something very wrong. Contemporary sensor
protocols are slow, to say the least. Same for the network end. You'll
saturate atleast one of those two ends before running out of CPU power. Use
Python. It is easy, fast and has a ton of library support for numerical
analysis. Stop buying into the hype please.

------
lacampbell
My big takeaway from the benchmark was that C++ used just over 20% the memory
of rust. If you're stressing about performance, that's huge.

~~~
0815test
They're just linking to an old blogpost from 2015 there. Back then Rust used
to rely on a custom memory allocator which introduced a lot of RAM overhead,
this has been fixed for quite some time now. Don't get me wrong, I like that
these folks are using Rust, but this post is leaving me with a bit of a weird
feeling - it just does not seem very impressive or meaningful.

------
iampims
Why is this on bitbucket.org? I don’t see a link between the author’s post and
the bitbucket blog. Is it just “content marketing”?

------
nullbyte
Wait, isn't Bitbucket written in Java though?

Are they rewriting it in Rust?

~~~
kunday
It seems to be a guest post. The url makes it appear like Atlassian is doing
some rust. Which it is not atleast, in this case.

Edit: ex-atlassian here. Bitbucket initial implementation was in python when
Atlassian bought them in 2011. Not sure what the stack is now.

------
sonnyblarney
It would be nice if some details could be given about the project so we could
put 'performance' etc. into context.

There are not that many applications that really need the extra performance
boost from the JVM to C++, usually, that would be a platform issue, i.e. the
device can't support the JVM or whatever.

For smaller projects (we're dealing with sensors, does this mean it's small?)
especially hardware related, the issues are going to be integration,
libraries, supportability for those tricky things; in such scenarios one's
hand is often pushed to C etc..

The advantages of Rust it would seem would have to be rather significant and
noteworthy to make the jump to a nonstandard platform, for so many reasons.

