Ask HN: Learn C++11 or Rust in 2022? Python/Golang/C (ye, C) day-to-day job here. I am interested in either updating myself on (C++11>) or going the Rust way. I see a lot of criticism/hate of C++ lately (mostly due to the comittee), but the tooling and libraries are there for multiple areas. Rust is also interesting to me from a security standpoint. So I don't really have time to invest in both languages; any directions? |
Just go with C++11/14/17/20 and you will be set for life.
From a practical perspective, if you're short on time and want a return on your investment, C++ will open up more opportunities on the job front.
In the future, those codebases will only be the legacy ones and you will end up doing more maintenance with C++.
With Rust your investment of today will pay off in a few years.
Deciding what to learn today is an investment decision and you should look into what you think the future will look like. To me it looks Rusty. :-)
Now, for C++ I can share some links I personally follow:
https://github.com/AnthonyCalandra/modern-cpp-features
https://www.youtube.com/c/lefticus1/videos
https://www.fluentcpp.com/
https://www.cppstories.com/
https://hackingcpp.com/
https://www.modernescpp.com/
Enjoy!
Why not? It's not like "two languages == double the time".
In this particular case, learning both side by side and comparing design choices may well lead to a better understanding and even be faster than just learning one of them.
C++11 is a well-known and popular language for software engineering, but was released in 2011. Most programs written in C++11 are being updated or rewritten in Rust because of its simpler syntax, more modern features, and generally easier development process. Additionally, many companies will hire programmers that specialize in Rust over those who specialize in C++11.
Although it is possible to find jobs doing C++11 development, we would recommend learning Rust instead.
I’m actually surprised that the general consensus isn’t rust as that’s the new shiny plus the people saying C++ are giving very valid reasons beyond the usual language dogma arguments that these discussions usually devolve into.
As you say I wanted to know how's the scene at the moment; I am very disconnected from how they have both evolved and their future (mostly because what I see is hate to C++)
Yes, you can get that last cycle of power from a piece of hardware by going with C or C++, but on the other hand finding people who can do that is time-consuming and expensive. And in many cases eventually not worth it.
"C++" is such a big concept toi grasp fully, that I don't see the point of studying it unless you're getting paid for it.
This is simply not true. Examples of major software that is being actively developed:
- Lots of compilers/runtimes (gcc, LLVM (which Rust builds upon), Java/JDK/JVM, Swift, node.js) - All major browsers and browser engines (Chrome/Chromium, Firefox, WebKit) and thus Electorn - Lots of rich client applications using either some Windows API, or something like Qt, or Electron (JS + C++) - Major game engines such as Unreal, Frostbite, CryEngine - Major OS'es graphics API build upon C++: Microsoft's Direct3D, Apple's Metal
And this is completely ignoring the embedded world, where C++ competes at least at some higher level with C.
All of this requires C++ engineers.
The amount of people actually _making_ compilers and runtimes is multiple orders of magnitude smaller than the people using them.
Same with browser engines and game engines. For every coder doing the actual engine, there are a hundred others just using the engine, not touching C++.
You did list a pretty substantial portion of the segments where C++ is a valid choice and in many cases (along with C) the only option.
Not really necessary to grasp the entirety of the language to use it effectively, I dabble in C++ here and there and usually treat it as a fancy C just using stuff like smart pointers, strings and vectors. Even learned some C++17 stuff which made what I was trying to do a lot simpler though I can’t remember what I was up to, think it was some boost lib I was already using that got promoted or std::variant shenanigans with my asdl generator — definitely yaks were being shorn I can say for sure.
So e.g. you hire a bunch of fresh graduates who've learned some programming maybe Java and Python, and maybe have other expertise you value (e.g. maybe they're aerospace engineers and you write control software for jet engines) and you spend money hiring somebody capable to stand at the front and teach them how to write C++. It's their job to learn this, so you can do it pretty intensively, e.g. lecture slot / exercises / break / repeat.
C++ is a big sprawling language, but you can make a good start on them in two weeks.
You've presumably worked somewhere with at least some onboarding or spin-up time. Somewhere you weren't employee #1 and responsible for buying your own stationery and cleaning the toilet ? What did you do on day one? Fire training? How to use the CI system? Anti-bribery? Getting your photo taken for an ID badge? Maybe some "easy" first tasks just to learn your way around the systems?
If you have a job where you turn up on day one and are just as productive as a long haul employee, I have terrible news for you - you are the most replaceable person in your organisation and you are going to get fired.
Programming languages are like actual languages, after you know the first two or three, the fourth one isn't that much of a hassle (there are exceptions of course).
I didn't know crap about C# when I started my current job, but I did have a decade of Java under my belt. Took me about a day to figure out the basics. Ifs and switches and functions and classes are the same everywhere.
If I would've had to study something like Haskell or Scheme, it would've taken a bit longer.
In any case, the point was that those that know how to repair the gearbox must come from somewhere.
> I see a lot of criticism/hate of C++ lately
Should tell you something. It's not like agenda driven PR campaigns are new to social media. Whenever I see a wave of criticism or praise on social media, I think to myself, what would paul graham do?
If your job is Python/Golang/C why do you want to learn C++ or Rust? Learn neither. Why not learn a functional language or SQL instead? Or delve deeper into python or go or c.
Why?
Many reasons. For starters, C++ is 40 years old at this point and embodies software engineering practices from the late 70's to early 80's (for you young folks, structured programming was the new hotness in the 70's!) C++ was also designed to take advantage of C's tooling, or lack thereof. C had incredibly simplistic dependency management. It worked well for the time since there were very few external dependencies, almost the entirety of the codebase was hand-built by the entity creating the software. There were very few libraries outside of the standard libraries.
C++ has an object model making it difficult to use and extend objects from different code bases/libraries. Never mind the inheritance patterns leading to lots of confusion. Just remember, Java and later C# were created to address these issues with C++. They were both touted to be better versions of C++ (which was true in the application development space where a GC could be tolerated)
Finally, the C++ type system is barely a type system as we understand them today. That's just history - C++ reflects our best thinking from the 70's and the modern type systems started emerging in the 80's. The simplicity makes some things unduly burdensome to implement.
Don't get me wrong - I've programmed in C++ for decades and I like it, warts and all. But I'm also practical and I recognize its days are numbered. Will C++ be around in 20-30 years? Absolutely! But so is Cobol, and would you start a major project today using Cobol? No. You can see we're shifting from C++ to Rust. C++ is the past and the lion's share of the present but Rust is gaining on the present and is the future. If I did't know either Rust or C++ in 2022 then I would focus my efforts on learning Rust.
You might not start a project in it, but goddamn I bet you could make a boatload of cash doing consulting work to keep ancient COBOL systems running. Even today that's pretty lucrative business if you have the skills and connections.
While C/C++ are everywhere, they are mostly in very low level places. You don't find a lot of new backend projects that go the C++ route.
Rust will likely eat up a significant chunk of C++'s current market share and SOME of the backend service market share (where CPU and Memory are REALLY important). However, I don't find it terribly likely that it will grow much beyond that.
As for the Cobol analogy, a good one, but you have to also realize there are about 1,000,000x more lines of C++ in the wild than Cobol. For cobol to die takes some institutional investment that most companies are not willing to burn. C++ will have a MUCH harder time being purged.
TBF, C++ was never a great backend language. Rust "the language" isn't either, but "Rust the package ecosystem" might be one day (because unlike C++, Rust is coming out of the "web hemisphere").
But—also learn Zig in addition to Rust.
Having seen first-hand how so many threat vectors these days are now supply chain attacks, having reported CVEs and earned P1 bounties in memory safe languages, and having worked on static analysis systems to detect zero day exploits—I'm also impressed by Zig's overall approach towards safety, as being more than only memory safety.
For example, this comes through in Zig's extreme simplicity and explicitness, and also how Zig enables checked arithmetic by default for safe builds. For people who haven't worked in security, integer overflow and wraparound may seem like small things, but they increase the probability of exploits such as buffer bleeds, i.e. attacks like OpenSSL's Heartbleed, which are often remotely accessible and easier to pull off than a UAF.
In fact, no language is 100% memory safe, i.e. able to prevent a memory buffer bleed, because these are logic errors with respect to the protocol. However, explicit control flow and checked arithmetic do help to close semantic gaps and minimize ambiguity, which is what good security comes down to.
Of course, Zig only offers spatial memory safety, and not temporal memory safety like Rust. So Zig is more memory safe than C, and less memory safe than Rust or JavaScript. Nevertheless, Zig is safer than Rust when it comes to being able to handle memory allocation failure.
Again, Rust's borrow checker is also valuable for concurrency safety, i.e. for multithreaded systems, but if you're using io_uring for fast I/O, then multithreading is less of the necessary evil that it used to be a few years ago.
Zig is something you can pick up in a week, with state of the art tooling, and fantastic C-ABI interop for libraries.
So... learn both!
Spoiler: I did this exercise myself. I found Rust to be more convenient in some ways. The Rayon crate made adding parallelism (threads) pretty easy. Some other crates made things pretty terminal output easier.
C++ feels more familiar to me in many ways though - I also write C fairly often. Implementing parallelism was more difficult. (I tried `pragma omp` stuff which should work similarly to Rayon, but couldn’t get it to work.) But just getting something working seems a little more straightforward.
I find myself fighting Rust somewhat often. In C/++, if you know what you’re doing, and you just want something working as a fun side project, it usually takes less dev time in my experience. Maybe that’s because I’m still learning it. Some folks will argue that the Rust compiler forces you to write better code and actually makes dev faster because it catches your mistakes. I haven’t found this to be true.
For example trying to implement simple polymorphism in Rust that was analogous to the implementations in Raytracing Weekend got ugly very fast. I ended in a weird hell of having to add annotations to everything to support generics. Again maybe I don’t understand the language enough, but adding polymorphism was a 5-minute straightforward exercise in C++, even as someone who doesn’t write it often.
I like a lot of stuff about Rust but I’m doing my hobby dev stuff in C instead nowadays, mostly for dev speed like I said, and probably would opt for using a subset of C++ for higher-level projects.
[1] https://raytracing.github.io/books/RayTracingInOneWeekend.ht...
Going to rust directly has been a very frustrating experience and made me give up.
Instead I spent time learning C++, I found out I could more easily transfer my knowledge/skills there. Once you become more proficient with the basics you learn about move, copy, smart punters, ownership, etc.
After some point you start to notice that you are basically doing in your mind exactly what a borrow checker enforce. So that made me curious and I tried rust again, and this time everything made complete sense and the language has been incredibly refreshing to work with.
This intermediate state was very useful for me to build my mental model and develop a better intuition, C++ made it simpler to do it in a more progressive way. And Rust is a fantastic langage if you can wrap your mind around it’s semantic and learn to work with the borrow checker.
IMHO, you could learn Rust as a first PL by treating it as a functional programming language with a focus on purity, like a twist on ML or F#. The borrow checker rules and things like the String/&str distinction follow naturally from that POV. Then learn how "interior mutability" is used to enable more C-like procedural programming with shared mutable state.
With Rust, depending on what you're working on, you may lose almost no time integrating C and C++ (with an extern C interface) libraries, or you may lose 50% of it. Sure, you don't have to know CMake at least (which is a hard requirement for C++ nowadays), but using any extraordinary library dependency in Rust may prove to be a nightmare. Essentially: if someone else didn't already package it, prepare to lose some serious time. The language is nice, but the ecosystem is immature.
Things are probably going to change, and Rust will become more viable over time, but C++ is also improving at a rapid pace so I guess Rust will never completely outcompete it.
This is also the main selling point of Rust, IMO.
Rust is less expressive than C, but likewise it does give less chances to shoot yourself in the foot.
C++ is often derided for its complexity, arising from its long development. While it's true that C++ allows many wrong ways to do something, I don't think that should really be a problem. The language's main problem is societal: C++ (and C) is often used by people who haven't bothered to learn the language. E.g. one can't rely on random unknown C++ code handling integer overflow and type punning correctly, so in such cases it's wise to compile with
-fno-strict-aliasing -fno-strict-overflow
Rust's advantage in this regard is that it's more centralized, it's lead by a foundation instead of being standardized, so everyone who learns Rust, learns the one, correct way to do things.
My idea is to either C++20 (not sure if there is a resource to learn directly from C++20 or if there are compilers supporting it) or Rust, personally I would go for C++ seeing as there's a wider ecosystem and tools out there, lots of libraries (which are a bit of a pain to use sometimes) and it is almost anywhere.
But to be fair, I am out of the loop of C++/Rust and what I see in my internet circles is Rust > C++ mostly because of the memory safety; which makes me wonder if it is worth or not; also lots of C++ hate which reminds me of PHP.
I just have a hard time making decisions.
C++ I find can get a little unwieldy quite fast, but is generally easier to keep simple. It maps to higher-level concepts in easy and intuitive ways. Rust, I hate to say it, but unless you know best practices / idiomatic Rust from the start, you'll have to do a lot of refactoring as you learn the language. Some constructs simply aren't possible using safe Rust. Many embrace the limitations, many else frustrate themselves again and again until 'the Rust way' drills into their heads. But, of course, once you get a feel for it, it's pleasant to write in.
How much difficulty you'll have with Rust or C++ depends on what problems you try to solve, and what your approach to programming is generally. If you're more of a pragmatic "I write simple programs that actually do things" I don't think you'll have any problems with Rust. It's very straightforward. And the tooling is second-to-none. If you like to partake in exploratory programming, trying out different theoretical models and different abstractions, C++ caters to that by allowing you to write more elegant designs than in Rust, with the downside that it also lets you make worse mistakes.
The wider cross-language library ecosystem is mostly C-based I've found, so, in C++ you can just use those libraries directly with no hassle (the only hassle being the build system, or lack thereof). Rust can use those libraries as well (as long as you don't have a gut-reaction "ew" to using `unsafe` everywhere) but unfortunately the safe and idiomatic Rust library ecosystem is kind of on the bleeding edge at the moment. Hopefully things will stable out soon, and all these hip new technologies will come to fruition, but that day is not today.
I know this isn't really nudging in one way or another but really it comes down to what you value in a language and what projects you want to see through using these technologies that will determine which one you like better. Have fun!
Rust is probably a better bet for web-related things. There is not much C++ there, and Rust seems to get some popularity. After all, Rust was originally made for Firefox.
For more industrial applications, or game dev, C++ is likely the way to go. Where I work, we do a lot of industrial applications and we have a lot of C++ projects, including new ones. Rust is not even on the radar. [Edit: C++ here is mostly C++11 now, with some C++98 and not much C++14 and later, I expect that we will get to C++17 soon enough but C++20 probably has a long way to go]
Forget about the criticism/hate of C++ and hype of Rust, it has little to do with practical applications.
Learn Rust because it has things to teach. Learn C++ for what it has, too, and because it is the language work gets done in.
They are much more similar than different. Rust builds in prescribed solutions for what its designers have deemed the most pressing problems. C++ builds in more power for library designers to address what each considers the most pressing problems.
There is broad agreement on what are problems, but with different solutions. Both languages work. I personally find Rust unable to express what I want to write, but it is evident not everybody wants to write those things.
Knowing both will make you a better programmer in either.
Practically all of the highest-paid coding work is conducted in C++. That will be true for many years to come. More people pick up coding C++ professionally, in any given week, than the total paid to code Rust. That has been going on for years, and is accelerating: attendance at C++ conventions, and the number of them, is exploding.
So, keep up with C++, and keep an eye on Rust.
So first learn Rust, later learn C++11+ (by the time there will be a successor of C++11 that may look even less like the C++ you know).
Learning Rust will develop your thinking and taste, and this will then help you judge the flavour of C++ that you will be learning later (and because you'd update your C++ skills later, you may skip another C++ legacy flavour in the process).
Also, if you're already fluent in another imperative programming language, it shouldn't take more than one or two weeks of a few hours after work to get an initial grip on both languages and decide whether you like them or not.
Personally, I find both languages equally frustrating for 'spare time stuff' (for different reasons though) and prefer simpler languages like C, Zig, Go, Python or Typescript (depending on the problem at hand).
I like C++ and my main caveat is that you don't just write C++. You also have to get good at tools like Valgrind and develop a deep intuition and understanding of what the language does under the hood. That's going to require a significant time investment and some people just don't have the right energy for it.
Nowadays the only reason I would learn C++ instead of Rust would be if I wanted to benefit from the much bigger C++ ecosystem, for example to build a game engine from scratch.
With C++ you'll have more offers, but you are more likely to be unsatisfied with your job: in large corps you'll usually have to untangle lots of messy legacy codes; while in start-ups things are more likely to be done quick and dirty and the flexibility C++ provides doesn't make it any better.
With Rust unless you are in the US, it's gonna be extremely difficult for you to find an opportunity; even in the US I gather there are not many chances and I _guess_ recruiters would expect higher proficiency as Rust is known for its steep learning curve.
If you have a long time horizon, Rust is the safer bet, if you want a job fast, C++ has probably more job offers.
At the moment I just write bits in C whenever I need it but when it scales in a decent size I would just write the whole thing in C++/Rust
I mean, maybe. Or maybe it gets replaced by something else.
EDIT: Ah yes, the "crawww C is unsafe, use rust crawww!" downvote crowd is out in full force today.
Unlearning bad C habits is hard because the language accommodates them for as long as you continue to cling to them. You need to consciously decide you will use the new, better way. Once you have done each once, there will be no temptation to backslide.
P.S. I haven't downvoted you.
Is C++20 support in compilers already? MSVC/GCC/Clang
I’ve found that Rust requires more careful design to satisfy the borrow checker, whereas in C++ you’d just copy or use a smart pointer and move on with life. Additionally, when in Rust you have to change that careful design, the changes tend to cascade and spread.
All of the above could be largely avoided by using copying and smart pointers also in Rust, except that goes against the culture and what everyone else is doing. Most of the APIs you’re using will probably want you to use references…
To me Rust is the kind of language you’d use if you have your solution figured out and you want to implement a robust program based on that. Flexibility and development speed are not its strengths.
A warning: Rust as a language has a large surface area, and there are some features and design paradigms that can make it messy to read and write. I would treat generics as a tool to be used sparingly, vice as a default API, for example. Same with Async and Tokio.
As others have remarked, there’s a lot more C++ gigs out there. I don’t think knowing C is actually much of an advantage to learning C++ though, the idioms and libraries are too different. Personally, I like Rust, it’s got a great community and the language feels “next-gen” in a way C++ never will.
For example, one of my products embeds Chromium (via CEF), which itself is a huge C++ project. I'm interested in working with Rust, but it's simpler for me to just use C++ rather than working against the grain.
For Cloud Native stuff, Rust might be a better option, specially due to the security focus.
> For example, this comes through in little things like Zig's extreme simplicity and explicitness
"Simplicity" does not mean safety. In fact simplicity means you can't describe hard problems easily without being overly verbose, which means more code and more attack surfaces. Problems are what can be simple or complex. If your language advertises "simplicity" it just means it can't solve complex problems in straight forward ways. Zig is just repeating the mistakes of C++ as well as all the mistakes of Go.
> or people who haven't worked in security, integer overflow and wraparound may seem like a small thing, but they increase the probability of buffer bleeds, i.e. attacks like OpenSSL's Heartbleed, which are often remotely accessible and easier to pull off than a UAF.
Zig does exactly what Rust does in this case.
> In fact, no language is 100% memory safe, i.e. able to prevent a memory buffer bleed, because these are logic errors with respect to the file or protocol format.
What are you trying to argue here? Buffer bleeds can't happen in safe rust.
> The borrow checker is obviously great for multithreaded systems, but if you're using io_uring for fast I/O, then multithreading is less of the necessary evil that it used to be a few years ago.
Syncronization is a problem in any kind of multitasking. Whether that happens inside or outside the language is the only question. The OS can have all the same problems your code can have. https://mobile.twitter.com/axboe/status/1505335772706091011 Also io_uring assumes you're only ever writing for Linux.
> Nevertheless, Zig is safer than Rust when it comes to checked arithmetic or being able to handle memory allocation failure.
This is simply incorrect. Most of the problem with unchecked overflow is for buffer overflows, which are fully caught. Rust gives options to handle memory allocation failure if you want to handle it. Generally though for most applications simply crashing is completely fine.
Thanks, I've tried to clarify that Zig provides spatial memory safety but not temporal memory safety, so hopefully it's less confusing.
> "Simplicity" does not mean safety.
Ceteris parabus, complexity breeds bugs and simplicity improves the probability of safety. For example, if I were auditing a piece of code for security, I would prefer the simplest correct program to the most complex correct program. Reduced surface area means reduced area for attack.
When I say that Zig pursues simplicity, I also mean this as high praise, that Zig is highly "orthogonal". In other words, able to solve difficult problems with a minimum of overlapping features. For example, Zig's comptime gives you generics, but also gives you so much more, plus there is also type safety throughout Zig's comptime, yet it eliminates the need for macros, and is more versatile, powerful and flexible at the same time. It's incredibly elegant. Nothing left to add, nothing left to take away.
> Zig does exactly what Rust does in this case.
Things like checked arithmetic matter and should be enabled by default in safe builds, yet Rust does not actually do this in safe release builds. Zig does and I hope that Rust one day will.
> What are you trying to argue here? Buffer bleeds can't happen in safe rust.
By definition, buffer bleeds can in fact happen in safe Rust. The borrow checker can protect against UAF and overflow, but the borrow checker can't protect against all kinds of underflow, which is what a buffer bleed is. You can even pull them off in JavaScript.
No language is actually 100% memory safe, not with respect to buffer bleeds.
Zig enforces correctness much more than C or C++ does (e.g. no implicit 'lossy' conversions, much stricter and enforced error handling, no implicit null, etc.), so it's completely fine to say that Zig is much safer than C or C++.
The main difference between Zig and Rust is the borrow checker, but a lot of memory corruption issues in C and C++ are "second order effects" of sloppy code which would be caught in Zig either at compile or runtime.
Hence simplicity is not a desirable goal. We need to create complex languages so that fewer people can understand and use it in a few projects and write very less code. Less code means less bugs. ‘Complex’ is the way to go. /s
Stick to C++ or Rust, which I won’t weigh in on here. But both are much more mature.
I guess as C++ veterans, we have to re-learn which approaches will work straight-forward, and which are the ones are asking for trouble. (I eventually found decent solutions for my problems that, while not the ones I had in mind initially, didn't require solving any hard puzzles.)
Is it a sin to say that, because you know c++ so well you don't need the nanny's and excessive overhead of validation?
That's akin to someone saying they never need to write tests.
Have you ever started a project without tests?
This seems like a weird statement. Yes, C++ has a load of features you can't express in a C API. But so does Rust! Yes, Rust can produce and consume libraries with a C API. But so can C++! They're in pretty much identical positions here, aren't they?
It's true that serde is great, and C++ doesn't have an equivalent (AFAIK). But C++ does typically have excellent piecemeal support for popular serialisation formats.
struct foo { int x; std::string label; };
soo... tooling ? how is that different from using valgrind ? it's literally one click in my IDE to use it and it will show e.g. the time spent at each line of code directly in it.
> If you use Python and JS chances are you do some form of web development, where most performance issues have to do with I/O, and most of those I/O issues are caused by bad queries.
I don't know about this, what I know is that multiple times in my career I had people come at me with python software that was slow, and transliterating them almost line by line to C++ made them much, much, much faster.
Also I have all these apps on my system which apparently depend on python, none of them being a web app:
Name : 3dsconv
Name : anydesk-bin
Name : arandr
Name : asciidoc
Name : bind
Name : binwalk
Name : bpytop
Name : breezy
Name : carla
Name : ceph-libs
Name : cmake-format
Name : cppcheck
Name : cppman-git
Name : cython
Name : deluge
Name : deluge-gtk
Name : diffuse
Name : distcc
Name : fio
Name : fontforge
Name : fvwm
Name : fwupd
Name : gconf
Name : gcovr
Name : gdb
Name : gdb-common
Name : gdown
Name : glusterfs
Name : gnome-tweaks
Name : gobject-introspection
Name : gtk-doc
Name : i3-workspace-groups-git
Name : ibus
Name : inkscape
Name : iotop
Name : ipython
Name : itstool
Name : jack_mixer
Name : kajongg
Name : kig
Name : kitty
Name : kitty-shell-integration
Name : libffado
Name : libixion
Name : libopenshot
Name : libreoffice-fresh
Name : libsearpc
Name : libsigrokdecode
Name : lldb
Name : mallard-ducktype
Name : meld
Name : mercurial
Name : meson
Name : mono
Name : mypy
Name : namcap
Name : node-gyp
Name : nuitka
Name : openshot
Name : pahole
Name : paperwork
Name : pax-utils
Name : pcsclite
Name : perf
Name : ps_mem
Name : pyalpm
Name : pyside2
Name : qemu-tools
Name : reflector
Name : repo
Name : rubber
Name : samba
Name : scons
Name : seafile
Name : setconf
Name : smbclient
Name : smem
Name : solaar
Name : speech-dispatcher
Name : tellico
Name : thefuck
Name : thonny
Name : torbrowser-launcher
Name : udiskie
Name : virtualbox
Name : yelp-tools
Name : youtube-dl
Name : yt-dlp
Name : zim
The entire origin of unchecked arithmetic being a problem originates from their use as indexes to buffers. If you solve the indexing buffer issue you don't need to completely expand every single mathematical operation to a checked one which slows down the code. If people want checked artihmetic for some reason in the rare case that it matters in a non-buffer case, then they can used things like checked_add.
First of all, that's security, not safety. Lots of software exists in an environment where it isn't going to be attacked.
> Things like checked arithmetic matter and should be enabled by default in safe builds.
Rust offers actual checked arithmetic - for example, suppose I have a 32-bit signed integer (i32) and I want to add something to it, in Rust I can choose the most appropriate of:
add - also presented as the + operator, in debug this will panic on overflow, but in production I can choose, either panic or just have it wrap silently
checked_add - at runtime check for overflow and get either None or Some(i32)
overflowing_add - this time instead of Option we get a pair back, with our (wrapped if necessary) numeric answer and a boolean saying if we overflowed
saturating_add - addition saturates at the minimum and maximum thresholds
unchecked_add - even in debug builds this is not checked (yes it's unsafe)
wrapping_add - this performs the most likely native hardware behaviour, wrapping numbers around at the limits
You might also realise your variable should inherently have certain arithmetic, for example a 16-bit PCM sample should always have saturating arithmetic (getting this wrong is one reason badly written older audio software can sound bad) so you can make them Saturating<i16> or maybe you actually want wrapping arithmetic on the simulated 32-bit CPU registers in your Motorola 68000 simulator, so you use Wrapping<u32> for them.
The debug behaviour for the trivial + operator is not intended to be your best defence, if you're sure you want wrapping, write that down, if you're sure you want to check, write the check. But sure, if you somehow want your release code to panic, but don't want to write the panics out by hand, you can tell the compiler you want this in release builds.
> By definition, buffer bleeds can happen in safe Rust.
Nope.
> The borrow checker can protect against UAF and overflow, but it can't protect against all kinds of underflow
And it doesn't, in safe Rust the actual bounds checks are emitted, and they only get elided in most cases because in idiomatic Rust it's clear to the compiler that the checks are unnecessary (e.g. iterating over items in a vector, the compiler knows how long the vector is, and it can see we're starting at the beginning and stopping at the end, so, we don't need the bounds check and it won't actually be emitted in the machine code). thing[index] is bounds checked in safe Rust.
> No language is actually 100% memory safe, not with respect to buffer bleeds.
Many languages are 100% memory safe. Most fascinating here is WUFFS which - in exchange for its restricted purpose - gets to be both entirely safe and faster than the C (or C++, or Rust) you'd actually write.
You literally can't write a "buffer bleed" type goof in WUFFS. I don't mean "You won't because it's so easy to get it right" or even "It will warn you about the problem at runtime so you can fix it". I mean code which can exhibit that bug does not compile.
I use the terms interchangeably on purpose, because safety and security are really two sides of the same coin. In the past, I've worked in security and I now work in a domain where safety is critical. It's my experience that the two fields have considerable overlap.
We can always get better at interdisciplinary sharing of knowledge.
That said, there are at least three stealth-mode SaaS companies I know of betting on Zig for their performance sensitive / low-latency software. Where I work, we're tracking Zig's nightly build and follow/contribute to Zig progress and stability roadmap.
Zig hits a sweet spot between C and C++. It feels really nice to work in -- in a way that many people describe Go. I think Zig is a very attractive option for allocation sensitive programs like games, audio, or purpose-built data stores. Give it a look and decide for yourself.
The General Purpose Allocator can optionally catch use-after-free by not recycling virtual memory addresses, not very efficient for small high-frequency allocations of course, but then Zig isn't an OOP language either (where it would be common to create and destroy massive amounts of tiny objects).
Exactly, which begs the question why bother with Zig at all.
i worked for a startup once that put a java based GUI on top of some C code and used the JNI. the endless issues with java bankrupted the company as the clients who were supposed to adopt the solution refused to deal with the sub par performance and reliability.
Some recent examples, Apple recently added support for using Metal from C++ instead of Swift secure bindings, Android now supports Rust at the OEM layer, no roadmap for NDK/AGK support for anything beyond C and C++, Azure Sphere is "secure" yet SDK is all about C and C++ (no Rust plans), Khronos API ecosystem is all about C and C++, CUDA,....
It's like the "I know React but not JavaScript" crowd all over again.
RAII is about resource management, regardless of where those resources live on.
Heap allocated, OS handles, indexes on a fixed sized buffer, network sockets, ...
C++'s problem is that most people never learn it properly and think "C/C++" is a thing because most courses/tutorials are stuck in the 90s and effectively teach shitty C with classes and iostream. Rust is great and has really nice features which I'd like to have in C++ too (like pattern matching) but memory safety is really not an issue in proper modern C++. I'm aware that this is a bit of a "you're just holding it wrong" but pretty much all languages have things you shouldn't do anymore once they evolve, it's just more obvious in the one with strong backwards compatibility requirements to the ancient language created before all the modern research into language design.
std::vector<int> v {1, 2, 3};
int& x = something(v);
something_else(std::move(v));
x = 42;
Honest question as I'm not a C++ developer: Even with all the new C++17/20 stuff?
All the things Rust advocates insist cannot be done safely in C++ are now trivial. Use-after-free, leaks, buffer overruns, what-have-you, no longer need any attention to avoid if you stick to modern C++. Some people insist on coding as if it were C, and bring along all of C's failings. Leave them behind.
Those people that insist on coding as if it were C are still a very big group across the industry.
Maybe someone proves me wrong with some killer application that makes Zig unavoidable for the rest of us.
Again, what did being pedantic prove here? You clearly understood what I meant.
Heap allocated data is one special case of OS resources that can be managed by constructor/destructor pairs.
Learning C first is a very bad way to learn C++. One can pick up pointers later, and asm blocks after that.