C is Lindy. People will be writing C code in 2072.
new code or maintaining legacy code?
C isn't a hangover and Rust isn't a cure
11–20 of 20 posts
Re: C isn't a hangover and Rust isn't a cure
#12The reason why Rust and other languages have bounds checking that approaches C’s speed is less to do with the compiler being able to prove away bounds checks and more to do with those languages making the bounds easy to carry around. Bounds checks themselves aren’t that expensive, if you already have the length to check against in a register or some other convenient spot. And - if the bounds are convenient to find an…
You'll have to enlighten me on how Rust makes passing bounds any easier. Spans and views are pretty common in C++ and C codebases these days.
Like many things in Rust vs C/C++ comparisons, it’s about defaults: Rust has dedicated syntax and everyone uses it, in C and C++ it’s more manual and not everyone does.
Re: C isn't a hangover and Rust isn't a cure
#13Re: C isn't a hangover and Rust isn't a cure
#14The reason why Rust and other languages have bounds checking that approaches C’s speed is less to do with the compiler being able to prove away bounds checks and more to do with those languages making the bounds easy to carry around. Bounds checks themselves aren’t that expensive, if you already have the length to check against in a register or some other convenient spot. And - if the bounds are convenient to find an…
You'll have to enlighten me on how Rust makes passing bounds any easier. Spans and views are pretty common in C++ and C codebases these days.
Spans and views make it easier, too.
But C/C++ pointers don’t. You can add bounds checking to all C/C++ pointers and there are many projects that do that (CCured, SoftBound, CHERI, Fil-C, CheckedC, -fbounds-checked) but they all come at cost (new hardware, language changes, or reduced perf).
Re: C isn't a hangover and Rust isn't a cure
#15Feels like most people reacting to this think it's about C vs Rust. And part of it is, but the bigger conclusion is: If you're starting a new programming project, you probably shouldn't be using a systems language at all. Go, Java, C#, Swift, Python, or Ruby are probably better choices for most projects. Go in particular has a lot of the advantages of C/C++ and Rust--fully-compiled binary, easy access to system calls…
I work for a huge company which acquired two startups in the same domain. One was using exclusively Go and the other Rust. They merged them together to create a unified product. To this day, the codebase is still using these two languages.
The rust part of the product is significantly better, the code is much saner and the team velocity is also much faster.
Re: C isn't a hangover and Rust isn't a cure
#16Rust is safe only with tree-shaped structures, so using a good old C and static+dynamic analysis might be a significantly less overhead.
I know what this comment is getting at, but I think the details matter a lot: https://jacko.io/object_soup.html
For comparison "C++ shared_ptr is only safe with tree-shaped structures" would be getting-at-the-truth-but-kinda-weirdly-worded in some similar ways.
Re: C isn't a hangover and Rust isn't a cure
#17Feels like most people reacting to this think it's about C vs Rust. And part of it is, but the bigger conclusion is: If you're starting a new programming project, you probably shouldn't be using a systems language at all. Go, Java, C#, Swift, Python, or Ruby are probably better choices for most projects. Go in particular has a lot of the advantages of C/C++ and Rust--fully-compiled binary, easy access to system calls…
I've been meaning to turn this into a proper article, but Rust has some really nice advantages once you get comfortable with it, even in programs where performance/embedding isn't important:
- enums
- const-ness without immutable types
- no null
- no iterator invalidation
- no surprising captures in closures/lambdas
- no "spooky action at a distance"
- Cargo
Re: C isn't a hangover and Rust isn't a cure
#18Feels like most people reacting to this think it's about C vs Rust. And part of it is, but the bigger conclusion is: If you're starting a new programming project, you probably shouldn't be using a systems language at all. Go, Java, C#, Swift, Python, or Ruby are probably better choices for most projects. Go in particular has a lot of the advantages of C/C++ and Rust--fully-compiled binary, easy access to system calls…
I work for a huge company which acquired two startups in the same domain. One was using exclusively Go and the other Rust. They merged them together to create a unified product. To this day, the codebase is still using these two languages. The rust part of the product is significantly better, the code is much saner and the team velocity is also much faster.
That seems more likely to be company culture related and only slightly influenced by the language.
Re: C isn't a hangover and Rust isn't a cure
#19"Academia stopped teaching C++, moving to Java and then to Python." There are a lot more practical and lucrative skills for a young programmer to focus on than C or C++. Many will be able to have good careers without going that low level. What impact will that have on the economics of legacy C/C++ code bases in the 15-30 year time frame?
I guess C++ will be new COBOL.
Re: C isn't a hangover and Rust isn't a cure
#20Zig is probably not so much popular as go or rust. But it seems like a great middle ground. It interops with existing c code. Even has it own compiler for c. Bun project is one of the major projects using it.