
Rust vs C Pitfalls - Anilm3
http://www.garin.io/rust-vs-c-pitfalls
======
gravypod
If you're fighting, you've lost. The way to convert everyone to Rust you need
to be better the the competition. Not just better as in "look at my features
that will make your code safer". People may see the value but think "I get on
just fine without the borrow checker so it isn't _too_ important". You need to
be far better then the replacement by providing the following:

    
    
       * Great Tooling ( IDEs )
       * Great Libraries ( Everything and a kitchen sink )
       * Better Documentation
    

Anything that can be done easily in C or C++ will need to be easier in Rust
for everyone to move. No amount of language features will pull people who are
doing well at their job, currently building everything they need to, and who
maintain low level systems. You have to be able to entierly replace the old
systems in a completely feature-complete way that's also easy to migrate to.

Blog posts wont pull me away from C, tooling and docs will.

~~~
voidlogic
On similar note, why Rust over Go?

If I look at everything I used to write in C, I'd say 80% is well suited for
Go and the rest I would fallthrough to Rust for. For the stuff where having a
GC and slightly less control is OK, I don't see why I would want to use Rust.
Rust is just much more complex and I prefer to keep it simple stupid (KISS).

Basically, Go is good for 90% of what I used to use Java for and 80% of what I
used to use C for... trying to understand where it makes sense for Rust to fit
in.

~~~
dispose13432
>On similar note, why Rust over Go?

I was going to say that rust has performance advantages over Go (due to GC),
but look at benchmarks:

[http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...](http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=rust)

Go wins some and looses some, but it's all in the ballpark (except Binary
trees [1] which it loses even to Java(!)).

It's true that rust is a new language, but so is Go.

[1]: I assume it's because it's a test of GC, but Go loses to Java (which,
like Go, is a GC language)

~~~
mmstick
This is only because the Rust implementations are using particularly slow code
paths, either because SIMD/AVX optimizations requires a nightly compiler, some
optimizations would require unsafe code, or that other languages are using
particularly hacky code that would never fly in real world software.

For example, many of the Java/C/C++ benchmarks are using custom optimizations
that should be illegal for the benchmarking. Case in point, some are featuring
custom hash maps that feature hashing algorithms that, while fast, would never
be useful as they provide no protection against collisions. You'll see a
hashing algorithm in a C preprocessor, for example, that just fakes having an
actual algorithm whereas Rust examples are sticking to the tried and tested
production-grade algorithms shipping in the standard library.

~~~
lossolo
> Case in point, some are featuring custom hash maps that feature hashing
> algorithms that, while fast, would never be useful as they provide no
> protection against collisions.

They are useful in this case, aren't they? Custom hash map implementation can
be also useful in other scenarios. This is feature of the language that allow
you to do that so it's not "illegal" to use it. If Rust doesn't allow you to
do something while other language does, it doesn't mean it should be illegal.

I don't see any tricks in Go and it's faster than Rust and more memory
efficient in almost half of the benchmarks. So what's your excuse for those
cases ?

~~~
steveklabnik
Rust can do custom hashes as well, to be clear. There's been some arguments
over what hashes are allowed in the game in the past.

~~~
fungos
If it compiles and run it is allowed. There is no rule to benchmark other than
having the same end result with best performance.

I still can't get all the moral over this.

The best thing here for Rust would be to achieve the best performance on this
game and nothing else.

To me this game is important and winning on it is more yet. So, if Rust don't
have better result by "morals" this is so wrong that hurts. But each time I
read these responses I ask myself if there is not a real problem there.

I like Rust, but performance is decisive. It is really sad to see that Rust
keeps going down on this game and that makes me question myself when trying to
invest time on Rust.

~~~
sanderjd
It isn't a "moral" issue. It is about the usefulness of the benchmarks. If
you're using them to make a recommendation about which programming language to
choose, it is important to have a sense for how well the results generalize to
the kind of programs you will be writing. Using unrealistic hacks targeted
specifically to each benchmark is contra that goal.

If, on the other hand, you're just treating the benchmarks as a fun
competition akin to code golf, then by all means, hacks ahoy!

~~~
fungos
Benchmark GAME :)

~~~
igouy
[http://benchmarksgame.alioth.debian.org/sometimes-people-
jus...](http://benchmarksgame.alioth.debian.org/sometimes-people-just-make-up-
stuff.html#name-game)

------
michaelmior
> “Safe” code is guaranteed to be 100% safe. Not statistically safe. Not safe
> when the compiler feels like it. As long as your code compiles, it will be
> safe in terms of memory safety and data-race freedom.

As far as I am aware, the Rust compiler has not been proved correct. So
whether or not your code is correct still depends on the correctness of the
compiler. Of course this is probably correct, but still not 100% guaranteed.

Edit: Relevant discussion - [https://github.com/rust-
lang/rust/issues/9883](https://github.com/rust-lang/rust/issues/9883)

~~~
millstone
I can make your code as safe as you like, if you only let me define what
"safe" means!

------
sidlls
The kind of safety guarantees Rust provides are, in my opinion, insufficient
justification for experienced developers to move from C or C++. Rust has other
features that make it generally superior in certain (many) contexts. The
safety is a nice "add-on" effect, I suppose, but my view is that constantly
hyping safety as the biggest selling point is missing a mark.

~~~
keldaris
I completely agree. The biggest reason I haven't seriously tried Rust yet is
because, despite all the vocal pro-Rust opinions we've all been inundated
lately, I struggle to name a single interesting thing about the language apart
from "safety". I wish the Rust evangelists would come to terms with the fact
that to many developers memory safety is not a particularly important concern
(for many different and often very good reasons) and talk more about other
aspects of their language.

The tooling seems nice, but far from unique (D, Go and other languages are
quite competitive there). It would be far more interesting to hear more about,
say, traits (can it compete with C++ in compile time polymorphism?) and other
technical aspects that make Rust stand apart from its competitors.

~~~
mmstick
You're only going to anger people by referring to another group as
'evangelists' when you yourself have already made note that you don't know
enough about Rust to see why they are promoting it. There's much more to Rust
than safety. You should actually spend a few months with it, and then give
your opinion.

~~~
tempodox
> ...you don't know enough about Rust to see why they are promoting it.

If you have to know a lot about Rust to find out why you're using it in the
first place, you certainly do have a chicken-or-the-egg problem. And, if the
promotion doesn't leave you with a clear idea of why you might want to use
Rust, that promotion couldn't have been very successful.

~~~
mmstick
The same is true of any technology. One cannot give an informed opinion
without first being informed about the technology in the first place.
Technology moves forward because there are many whom are willing to leave the
comfort of their boxes into the unknown to try things without being required
to be convinced.

------
chj
We are having new languages every year. Instead of debating which language is
the best, why can't we invent a way to let components implemented in different
languages talk with each other easily? We have pipes, sockets and message
queues, but it's never simple enough to glue everything together.

~~~
choudanu4
This is an interesting idea that has been explored before in VMS, an old
operating system I believe competed with UNIX.

VMS had a feature called CLE (Common Language Enviornment) [1] which defined
calling conventions for computing primitives (functions, registers,
stacks...you get it) independent of any language. You could call bits of code
from all sorts of languages like COBAL, FORTRAN, C, and some others I'm not
really familiar with. Because the calling conventions were specifically
designed for language interopperability in mind, VMS was implemented in
several different languages. Different components were coded in whatever
language best expressed them. This directly contrasts with Unix, which we all
know champions C.

I'm not too familiar with Unix calling convention specifics, but as I
understand, it revolves around C and its memory model. I believe this is what
gives some languages difficulty "talking" with each other; if a language
doesn't have a memory or execution model close to C's, it needs to translate
through a FFI (Foreign Function Interface) [2] before exchanging execution
routines efficiently.

[1]([https://en.wikipedia.org/wiki/OpenVMS#Common_Language_Enviro...](https://en.wikipedia.org/wiki/OpenVMS#Common_Language_Environment))

[2]
([https://en.wikipedia.org/wiki/Foreign_function_interface](https://en.wikipedia.org/wiki/Foreign_function_interface))

~~~
chj
I think Unix's pipes are better examples that how components could
communicate. It's a pity that due to terminal limits, the best we can do about
connecting components in Unix is to pipe things through.

------
pklausler
A more interesting question for me is: is there any reason why would I want to
use Rust over Haskell on any task where Haskell is "fast enough"?

~~~
caconym_
Rust seems to be more lightweight and portable in general. I think the
compiler uses far less memory (and IIRC has better cross-compilation support
too). The binaries are much smaller and the runtime is simpler. Cargo is
amazing and I have much more confidence in it to not give me build trouble. In
particular, you get a test framework including doc tests for free; I know
Haskell tools offer similar functionality but in practice the setup cost is
far higher. Haddock is not bad, but it uses its own weird syntax; Rust's
documentation system uses Markdown IIRC.

Also, some things are just easier to write in an imperative language. I expect
that the performance and memory use of Rust programs is also easier to predict
and understand, though generally I think Haskell gets a lot of unfair
criticism in that department.

I haven't used Haskell in a while so some of the things I mentioned may have
been improved upon since then. In particular, Stack may have grown up a bit.

------
Tempest1981
Stroustrup has proposed a way to add safety to C++. It's called "C++ Core
Guidelines", and "GSL".

[https://isocpp.org/blog/2015/09/bjarne-stroustrup-
announces-...](https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-
cpp-core-guidelines)

[https://github.com/Microsoft/GSL](https://github.com/Microsoft/GSL)

I watched his talk -- wondering if anyone is using it.
[https://www.youtube.com/watch?v=1OEu9C51K2A](https://www.youtube.com/watch?v=1OEu9C51K2A)

Using GSL gives adds some safety to pointers and memory allocation -- while
providing the bare-metal performance that C is known for. (It still feels very
low-level.)

------
smitherfield
To play the devil's advocate a bit, most of these are features you already get
with C++, especially if you turn on all relevant warnings and treat them as
errors. I can see the advantage of having things (sorta, given "unsafe")
statically guaranteed for a shared codebase, but what are some compelling
reasons to switch for personal projects?

~~~
isaacaggrey
Manishearth's response [1] plus Cargo [2] hits on a lot of great things about
Rust.

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

[2]: [http://doc.crates.io/](http://doc.crates.io/)

------
faragon
Author forgets some inconvenients of Rust: massive bloat, multi-platform
issues, etc.

~~~
colemickens
What are you talking about? I don't get people making these posts without any
detail whatsoever as to what they're talking about.

I have a fully static binary that includes futures, nix, tokio, uuid, and
more. Even statically compiled with Muslims it's less than three megs.

And if I didn't use the nix package for a setsockopt call, it would be
perfectly capable of running on Windows (and I could easily make it cross
platform if I wanted to invest the effort in adding Windows support). Further,
there are an abundance of great resources out there for extremely painless
cross compilation.

So far I've not heard of problems with multiplat or bloat so I'm hoping you'll
elaborate.

~~~
faragon
There are more systems than POSIX and Windows. Also, even in popular Linux
systems Rust is not even installable in a straightforward way (e.g. Ubuntu
15.10, my system), so go figure. Regarding Rust bloat, I don't know if has got
any better recently, but it was crazy bloated in comparison to C.

~~~
Manishearth
The bloat issues are (a) a constant overhead and (b) a matter of defaults.

See [https://lifthrasiir.github.io/rustlog/why-is-a-rust-
executab...](https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-
large.html#takeaway)

Rust statically links to libstd by default because it's not there as a dynamic
lib on most platforms. On top of that, it links in jemalloc. This makes small
Rust binaries look larger than they need to be. The overhead dwindles as you
start looking at larger Rust programs. If you actually need to get rid of that
overhead, the option is there, it's just not default.

Addition to popular package managers is being worked on.

------
gens
Since this is a "vs" can i assume that rust is better in all regards to C ? As
in that rust is flawless ? Or should it be "Rust vs C's Pitfalls" ?

------
fungos
You're so wrong that is laughably.

That laughably hashing functions are highly specialized implementations for a
proposed problem. There is NO MORAL there.

I code C for living and if we can use "laughably hashing functions" to gain
performance we WILL DO.

~~~
dang
> _You 're so wrong that is laughably._

This comment breaks the HN guidelines by being uncivil. Please express your
point substantively. If someone else is wrong, show them (and the rest of us
readers) how. Then we all learn something. Also, please don't use uppercase
for emphasis—that's in the site guidelines too.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

We detached this comment from
[https://news.ycombinator.com/item?id=13269145](https://news.ycombinator.com/item?id=13269145)
and marked it off-topic.

