Blog: Why would I pick Rust over C?


#1

An attempt to compare Rust with C - why C was good and how Rust is better. https://prataprc.github.io/rust-over-c

Feedbacks are much appreciated. Cheers,


#2

Cool. I like the write-up.

How do you see the ease of co-operation of tasks for C vs Rust? Or, in other words, Would you say that multiple programmers working together on the same application would be better off with Rust or C?

I know that C++ has a massive problem with code readability and cooperation if the C++ programming model is not sufficiently constrained - the coding styles become just too different to decipher in any productive sense.


#3

To be honest, I haven’t setup FFI between C and Rust. Accessing Rust code from C must be constrained, especially with respect to type-parameters, trait-objects etc.

Nevertheless, given the fact that Rust is more formally/cleanly defined when compared to C++, we should be able to do better than swig to connect Rust with C or C++.

I would also like to know if there is any work similar to SWIG to connect Rust with other languages.


#4

And when compared to C , Rust is far more agnostic to the processor or its target platform.

I’m not sure what you’ve meant by that. There are C compilers for bizarre and niche platforms, while Rust works only on mainstream ones. Rust requires 8-bit bytes, 2’s complement numbers, while C leaves a lot of such details as implementation-defined or undefined behavior, which allows C to run on processors that Rust can’t.

One plus side is that Rust works much better on Windows by bringing a modern compiler and dependency management that is mostly cross-platform (OTOH making a C project portable with Windows support is a pain of dealing with the weird and outdated MSVC, fragmented build tools, and no good options for dependency management).


#5

A bit off-topic, but it is worth mentioning a proposal for C++20 that will introduce the requirement of 2’s complement numbers.


#6

There are essentially two angle to portability.

  1. Whether my code will compile on a different processor/platform
  2. When compiled, whether my code will be correct or not.

For the former case, Yes C is a better option than Rust.
Hopefully in time we will find Rust on as many platforms as C :slight_smile:

For the later case, C’s undefined behaviour and implementation
defined behaviour should lead to unportable code.

  • undefined, better don’t use it if we want portability.
  • implementation defined, we can’t move from one compiler to another.

Rust requires 8-bit bytes, 2’s complement numbers

While working with 24-bit bytes, fixed point numbers,
multiple-address-space (harvard architecture), multiple execution
unit packed in the pipeline - we always reverted to hand
coding in assembly. C really works well for mainstream platforms,
and we can get it work on niche platforms, if we are willing to put effort.

On 2’s complement, can’t Rust abstract that detail behind
i8,i16,i32,i64 and i128 types ? Is there a restriction that prevents Rust
moving away from 2’s complement for signed integers, for specific processors?

One plus side is that Rust works much better on Windows

+1

Cheers,


#7

At the table at the bottom, why does C have a N for Macros?


#8

At the table at the bottom, why does C have a N for Macros?

C Macros are essentially pre-processor directives. Unlike LISP or Rust which allow macro authors to interpret tokens or the syntax tree, C macros are more of text substitution. IMHO, Lisp, Rust and Elixir have good abstraction for macro. print!(), nom are good examples for rust.


#9

I don’t disagree, but I’d suggest you try to qualify that in the post or table some how. The average programmer knows that C “macros” exist, even if they are quite different than Rust’s.

Nice write up.


#10

Nice article overall.


Parametric types

While Rust does enjoy limited parametricity for types T where T: 'static does not hold, it will most likely not do so in the future when specialization lands. For lifetimes parametricity will remain tho. Whether this means that Rust will still have “parametric polymorphism” I’ll leave unsaid. Usually parametric polymorphism is coupled with parametricity.

Rust design includes some of the latest advancements in type system along with memory safety built into the language.

Probably not. While Rust has a quite a modern type system it’s mostly System F with type classes (traits), region typing and affine/linear types with some specific variations for Rust. The main novelty is having this in a systems language. There’s nothing particularly state-of-the-art here tho; no dependent typing, no Homotopy type theory, univalence, effect polymorphism, etc. Not even System Fω (higher kinded types).


#11

Amended the post to clarify C Macros. Thanks.


#12

Had to google the type-theory concepts mentioned here. Yep they are state-of-the art.


#13

Interesting discussion. Although, I’d say an industrial-strength language would explicitly not be “bleeding edge”. The usability of systems comes from a confluence of technical advancement and exquisite timing. Hence why the iPad was not the first tablet ever, but was the first truly successful tablet. The combination of sufficiently mature technology together with an excellent implementation quality made it a success. If Rust had those very advanced features, it’s widespread success probability would be very low i.m.o.

Therefore, a safer wording could be “Rust design includes an advanced but mature type system along with…” or something like that.

Like Roger Penrose’s books on science, the editors told him “for every equation in the book your readership would halve”. We could jokingly say “for every state-of-the-art concept in your language, your users would halve”. :face_with_raised_eyebrow:


#14

Rephrased it as,

Rust design include some of the latest, but mature, type system

Thanks,


#15

Oh sure; I’m not saying that Rust should have the latest bleeding edge state of the art type theory because those are usually not proven out yet wrt. ergonomics, understandability, and such. I’m just noting that most of the type theory in Rust doesn’t include recent advancements (tho there are some cases where we do use some not-so-long-ago advancement such as in the exhaustive_integer_patterns feature). :wink:

That said I think refinement / dependent typing and effect polymorphism does make sense to take a look at due since we started with const generics (RFC 2000) and since we have several “effects” now (const, async, unsafe, various target_features…). So these may become necessary. But things like HoTT are for sure entirely out of scope.

Also, I should say that Rust’s type system is relatively speaking quite advanced (but not state-of-the-art) as compared to most other other industrial-strength languages. It’s probably only Haskell which is more advanced here and which has an industrial-strength compiler (GHC).


#16

Agreed, it would be cool to play with some of those advanced features in like a special “experimental” Rust branch. Maybe once the IDE work is done and array+matrix support libraries are first-class (we want Rust to replace Fortran in supercomputers eventually).


#17

You mean the nightly compiler under feature gates? :wink:
First we need to think really hard and come up with some designs tho.


#18

Because rust teaches you to be patient I personally spent past 3-4 days on just fetching a stupid simple json data over an api and unmarshalling it which would take me like 10 minutes in go or lets say an hour or two in c++ considering i write c++ rarely.

Event the simplest tasks are extremely difficult and tricky so you learn to be patient and not to break you computer.

I am still trying to understand is rust really valuable enough the invest my time (so much time) in it and the answer is not really positive at this point but i will fight a bit more to see how it goes over time(its been around a month already and it still takes freaking 4 days to fetch data and deal with it. I learned golang in a week or so and in the end of the month i could already do anything i want comfortably.)


#19

@NikosEfthias Yes the learning curve for Rust is pretty steep.

With languages like Python, Golang, we can start with values,
types, literals, loop constructs, branch constructs, functions
and arguments without worrying about the unique and advanced
features offered by them. Then, to get productive, we move on
to standard-library. And as we work with the language we slowly
digest the advanced and exiting features offered by them, to write
idiomatic, high performance code.

With Rust,

  • Many of the features that one might expect as part of the language
    are actually implemented as part of the std-lib.
  • Features like type-parameters and traits are first class citizens,
    which means, even built-in types and standard libraries
    are tightly weaved with standard traits and parametrised APIs.
  • Stdlib is heavily influenced by functional programming, but it doesn’t
    have to be like that.
  • And most difficult part, at-least for me, is that we often
    find circular dependency of abstractions. Typically it is easy if
    abstractions/features are stacked on top of each other, unfortunately
    that is not the case here.

Although it might look cumbersome at first, you might find more than one
reason to call them as “rightly done”.

My tip would be -

  • To follow through Rust-book and Rust-examples.
  • Don’t touch the std-lib for now.
  • Start solving simple problems from places like project-euler and exercism.
  • Start playing with advanced features of Rust.
  • Improve your solutions (euler/exercism) with better abstractions offered by
    Rust.
  • Move on to standard-library.
  • crates.io comes much later.

Yes lot of patience required. For some it would be weeks, others it might be
months. Either way a stream of “aha” moments will come and a rust-mechanic
shall be born :wink:

Cheers,

PS: I can get into how Rust is better than this language or that language, but IMHO the choice of language is choice between trade-offs.


#20

(imho, Project Euler isn’t really a great “programming puzzle” source for feeling out a language, as most of their questions are math rather than programming.

Since it’s the season, I’d recommend the Advent of Code instead (and there are plenty of other solutions being shared to check out).)