C, C++ or Rust
Looking at this thread
https://news.ycombinator.com/item?id=10706314
from 2 years ago, I'm interested to see if people's opinions around this have changed at all.
Most of the suggestions seem to be C or C++ with a majority being C, does that still hold up in 2018?
-------------------------------------------------------
To follow up an early question
I'm looking for something to deep dive on and try and learn it from the ground up.
This is primarily for me to build more performance conscious applications and tools for my work, they are unlikely to be worked on by other staff in the near future but who knows in a few years time.
This will be primarily Linux and Windows focused work but will eventually want to branch into the embedded space.
8 comments
[ 3.3 ms ] story [ 29.0 ms ] threadRust is really interesting and promising but it's newer. It has less platform support. The compilers probably aren't as good. There's not as much tooling.
Oh you wanted advice...
(1) How adventurous are you?
(2) How many platforms do you want to port this to? Do you want to port it to old, embedded, or closed platforms?
(3) How many people will you need to hire to work on it?
Ask questions like that and you'll get your answer.
I have yet to learn Rust but I'm following it closely. I'm a pretty heavy C++ programmer and it's the only language I've seen in many years that might be a contender to replace it.
1) Adventurous as I need to be, happy to take a deep dive into a language and try and understand corner and edge cases where necessary
2) Most likely would be running on Linux+windows but unlikely to be embedded
3) I'm mostly interested from the context of learning tools to make my work more performance conscious and just as a general learning exercise.
You want C for this. C++ and rust are aiming to give the same level of performance in higher level languages but to achieve this they have to abstract things from you. C has very little of these abstractions and you're forced to be much more aware of where your CPU cycles are going, it also allows you to optimize them in ways that can be harder in c++/rust.
It's not just the language itself but the libraries, the "standard" c ones are rather anemic which means you have to code a lot of things yourself, even for simple things like dynamic arrays and dictionaries. This means your directly exposed to a lot more of the basics and have to consciously think about things like memory layout.
This statement looks uninformed. The is just the one Rust compiler. (Yes, I'm aware if the other one that only works on valid Rust, so you can't use it without the first compiler.) And the one compiler uses LLVM, so it's as good as clang.
> There's not as much tooling.
Some C++ tooling like debuggers work for Rust with minor caveats about enums and trait objects.
OTOH, the tooling that exists is awesome. For example cargo compared to make.
I've been using Rust for a while and I can mention one thing that I changed my mind about:
With time, and as you build more things on top of previously built ones and the knowledge you will gain, Rust features were promoted from "good to have" to absolutely fundamental for building things on top of them. There is no going back to C/C++ once you get used to ADT, cargo, helpful error messages, train model release cycle (new features with full backward compatibility every six weeks) and most importantly - with what people do with having those features. C becomes more dated every day and it becomes more and more noticeable. C++ may pick some of Rust features in some future, but you will still have to work with code without them for a very long time.
> This is primarily for me to build more performance conscious applications and tools for my work
For me Rust makes much easier to just focus on the problem I want to solve and not worry much about the tooling, build system and other unrelated details, so I find far more practical. It may be different if you need close cooperation with C/C++ ecosystem.