I use C when I believe in memory safety
gavinhoward.com
gavinhoward.com
I feel I have to develop an economy of effort in C because there usually isn't a dumb and easy way to do things - this pleases me.
C has a mental model that seems relatively simple - I feel I can reason about what's going to happen to a greater degree than higher level languages.
C++ is the worst IMO because it has lots of abstractions but they don't make programming simpler because you pretty well have to understand the low level aspect of what they're doing to get performance - so the complexity is much greater.
Rust seems to put a lot of difficulty up front which is of no value in the kind of typical short program I write most of the time. I just didn't enjoy it. If I had something complicated to do I might eventually appreciate it.
The more high-level the language the less one tends to understand it and that's unsatisfying.
Having said all of that though, I tend to "just write python" whenever I can. If it's a throwaway program one doesn't need more and if it turns out to be necessary to interface to some library or other I know C well enough to sort that kind of thing out. I use threading.....never - at least never by choice.
Overall this is way better than writing everything in Rust.
In re Rust: I feel one of the mistakes most people make is taking Rust to be a general purpose "default language" for everything, like C and C++ used to be. But like you wouldn't write C++ for most stuff even if you were magically granted the ability to never ever write unsafe code, writing web services in Rust just means making your own life harder. It's a great tool, I'm happy it exists and I follow its development, but we must accept it exists in a different space than, say, Python or Ruby or Javascript.
I feel physical pain as I say this, but most stuff should probably just be Java.
This has been on my mind a lot lately, causing similar anguish.
I'd note that, from what I hear, C# would also fit the bill, but be as unappealing to me.
I really wish that there was a language with the productivity, ecosystem and ergonomics of Python, with the speed and efficiency of Java and C# and a type system that increases productivity rather than word count.
Go seems... fine, but, I dunno, slightly regressive. I'll probably use it where performance and scaleability matter.
That would be.. Java :D While I’m quite a big Java fan, for the other parts some other JVM language can easily fit the bill and you even get a choice. Scala, Kotlin, or maybe even Clojure if you don’t mind dynamic types.
The others look like really really nice languages and I'd love to use Scala for a solo project.
However I guess I need something that's a) truly general purpose b) not going to scare away collaborators or potential hires c) going to be around for a long time d) not going to require evangilization at, say, a start-up.
Kotlin... I guess I'm wary of it being the new Coffescript - i.e. that it spurs Java into improving to such a degree that it removes the need for Kotlin in the first place.
And yes, having just spent a long time transitioning a project from JS to TS, I'm not sure I want to start anything serious without at least half-decent static typing - a major reason I'm looking for an alternative to Python, which is just not quite there.
I think that's unlikely. The key difference being that Coffeescript was always dependent on JavaScript because it compiled to JavaScript! Whereas Kotlin doesn't compile to Java, it compiles to JVM bytecode the same as Java does.
Scala is another alternative with more scientific approach.
Both enjoy JVM quality and consume Java libraries.
Java is improving as well, but not on par with those languages. Worth checking out though.
I've never touched android development in my entire life.
https://en.wikipedia.org/wiki/List_of_JVM_languages
Kotlin has its future assured thanks to godfather Google, stagnating Android Java on purpose (only recently they decided to finally move to Java 11 LTS subset), while promoting Koltin as its replacement for everything besides core platform.
So no wonder that people usually say that.
Unfortunately, when I use Dart, it's on Android, where the SAF exists, which kills my enjoyment, despite Android/Flutter otherwise being probably my favorite platform.
Try OCaml or F# then.
Nim has that except for the ecosystem. And it's also kind of janky, enough that I got so frustrated I stopped trying to use it. But you might have better luck than I did; check it out if you haven't.
That's a terrible recommendation!
If they made iterators work how they seem they should work, I would come right back to Nim. It does so many things right but this one thing is a dealbreaker for me. The UFCS is practically begging me to chain lazy iterators together but actually trying it is like stepping on a rake.
Lazy iterators and generators are something I've missed in Rust. Haskell has them just by nature of everything being lazy and I love that. But I've become too familiar with Python, and unless runtime performance is a bottleneck, Haskell hasn't been the path of least resistance for most of my practical problems.
Just Python and shell scripting. All this stuff is for hobbyist programming not my day job, so I just shelved the stuff that need performance and dusted off some projects that don't. I'm learning Rust at the minute but it's slower going, I'm not at the level where I can make the stuff I want.
Probably influenced by the fact that I hate debugging in production and last times I wrote some serious Python code, I ended up doing just that.
YMMV
I don't hate Java, I work with it every day and as you say it's a practical language that gets stuff done with minimal hassle.
The reason why it's hard to stomach is that it's the infrastructure of the future with the programming techniques of the past. Java the environment is like living in 2050, Java the language is like living in 1990.
Things are slowly getting better, but everything feels clunky and bureaucratic. The type system manages to be simultaneously ultra-verbose and not expressive enough to represent useful properties. It's a complete travesty that I need to codegen my own Tuples and write my own Either<T1, T2> as a literal Bohm-Berarducci construction. No value types (they're coming, but not yet stable). Didn't have Records until Java 18. Useless semantics for "final". Getters and setters. Nulls aren't even funny.
The language design feels at odds with the broader goal of providing a safe, efficient, solid programming environment.
It's still a fine choice for most applications, I'd venture to say it's actually the best choice, but that's because the language itself actually matters very little, unlike us nerds would like to think. But it doesn't have to be that way. I'm hopeful it'll get better.
Wonder what are the examples of 'short programs' where you'd just zip out raw C as a default language, and it would be simpler/faster to implement than in Rust?
Using C for anything is just rare for me and C++ and Rust even more so because they don't add anything that I need usually.
I've found myself thinking, time and again, is Rust exposing, to the programmer, what have traditionally been details handled to varying degrees by sophisticated compiler optimizations? If so, a great optimizing compiler might deliver binaries as performant as a Rust expert could, but with less programmer effort?
(I can't answer that, only haven't found a counterexample as a one time optimizing parallelizing compiler person.)
- who owns what
- how long things live
- which values might be null or missing
- which functions might return errors
- how strings are encoded (https://twitter.com/timClicks/status/1450943515635056648)
- which types are thread-safe
There are some performance gains to be had in that list, but for the most part it's about asking the programmer to be explicit and avoiding convenient-but-risky defaults that lead to lots of bugs.
I learned Rust over the last 6 months. I'm not sure I'll ever go back to C. I still love C. But Rust is the future. I'm pretty sure of it. I don't have to worry about undefined behavior unless I opt into it, and I usually write more performant and powerful code in a shorter amount of time.
I've gone down the road of trying to bolt on checkers and verification to C to achieve a better DX when writing safe C. C compilers just aren't extensible enough right now though (Clang would require some serious upgrades to the attributes and tablegen system in order for it to work well).
Rust's compiler is already extensible today, and the language has most of that built in.
It's not really something I want to bring up again. I was asked my opinions on Zig, I gave them. The PR might not have been the 'best' solution but the vulnerability was left unaddressed - Andrew seems to insist I misunderstood something, but has failed several times to explain why.
I hope it's since been fixed, but panicking on UTF-8 decoding errors had the potential for massive damage in my opinion.
There's clearly nothing more I can say to you; I'm tired of the emotional and childish responses to my attempts to reach out. I've expressly avoided using your name and have tried to keep my critiques civil when discussing Zig the few times I have. However, you seem to find the comments every time despite this.
I wish you and Zig the best of luck.
---
andrewrk — 04/02/2020 there's no such thing as security vulnerabilities until post-1.0, which is why nobody should be using zig in production yet
Neat article, always interesting to take a peak at some ones highly idiosyncratic process.
> "The next reason is that during my time with C, I have developed a custom software stack designed around memory safety."
Oh ok then. Again goes to show how C is deficient in some areas
I get something being fun, but C ends up needing to worry about a lot of details where you could be actually improving the code in other languages
Also if he already has a framework that solves that problem for him, then it's not deficient in that areas, for him, right?
Also to gp, title perfectly matches, pointing out why he believes in memory safety when using C, everytime also pointing out the flaws with his thinking, and why this only applies to him in his completely owned projects. Not sure what's wrong with the critics here.
It's also fun to write data-structures yourself instead of being a mere user all the time. In C you can tell yourself that your take on how to do datastructures is worthwhile and unique (might be a slight stretch) but in other languages almost anything you can do is redundant.
Only if you manage simple buffers and do shallow processing with them
String management, network connections, data structures, this is simpler literally everywhere else
> It's also fun to write data-structures yourself instead
True, but it's more fun in C++, warts and all. And not when time is money
There is no theory.
It's really simple, actually:
If you have a mine-field with an uncountable number of mines, knowing the locations of 200 mines won't help you cross the mine-field safely. If, instead, you learn how to spot areas which are known to be safe, you can, assuming you don't make a mistake, at least attempt to cross it safely (and if you fail to cross it, you can go back and learn how to spot other areas which are known to be safe).
That is the difference between your claim that you need to know all the documented instances of UB and my claim that you just need to know enough defined behaviour to write your program.
It has nothing to do with security assessments or pentests.
It's not just the API either. So once you've got your "nice" error handling API, you have to manually handle resource clean up - no branches that exit for you; every function call is accompanied by a result check and a goto to cleanup code (so your pointers need to be defined properly prior to any calls and initialised to null). Honestly, I don't know I ever lived with this mess. It was a painful and laborious experience to get to something that was just about ok.
> So once you've got your "nice" error handling API, you have to manually handle resource clean up - no branches that exit for you; every function call is accompanied by a result check and a goto to cleanup code (so your pointers need to be defined properly prior to any calls and initialised to null).
I have a stack allocator that will release everything allocated in the function on exit, and I have macros to replace my use of the return keyword that also deallocate everything in the stack allocator before returning.
So my code actually has code cleanup on return.
C does not have to be laborious. Maybe the fact that I have done things like that is part of why I like C?
Basically, you tell the stack allocator to store a jmp_buf, then you setjmp() on it. Then keep going.
For a function, a special destructor is used as a marker. Same with scopes.
The same is also true of a setjmp() destructor, which is actually what activates longjmp().
The stack allocator should have three functions to unwind itself until it reaches the end of the next scope, function, or jmp, respectively.
Then, when you need an exception, or to exit a function or scope, you call the correct stack allocator function to clean up everything to that point. Then you return or whatever.
This can run arbitrary code on cleanup for an item if you write a "destructor" with that arbitrary code. For example, one idea I had was to use the stack allocator to ensure a mutex or other lock was always released. This would be done by storing a pointer to the mutex and writing a "destructor" that unlocks the mutex when given a pointer to the mutex. Boom. Scope-based mutex unlocking.
Makes sense?
Not really. The author describes he put together a framework for C that implements memory safety features.
Isn't it intellectually dishonest to criticize the adoption of libraries that provide features that other languages may or may not have built in?
What's the end goal exactly? Use safety features to write safer software, or attack anyone that hasn't mindlessly jumped onto a particular bandwagon?
Of course you can augment a language with libraries. But you are one developer and everyone else will make different choices.
Sure, you are free to make this sort of claims. But they are besides the point, aren't they?
The cliche being discussed here is C's hypothetical ties with memory safety issues, and here we are commenting on a discussion on how someone writes C using a framework focused on memory safety and thus providing "some guarantees" about their whole ecosystem. Yet, we're still seeing comments mindlessly parotting myths in spite of the facts that are being dangled right in front of their nose.
More importantly, it goes against the cargo cult narrative that the choice of programming language is the one and only factor determining memory safety, and consequently any use of languages such as C automatically leads to security issues.
It's not a coincidence that we have people in this discussion coping with that concept by spinning the use of frameworks focused on memory safety in C applications as somehow representing writing code in an entirely different programming language.
Despite the authors borderline obsessive efforts to write memory safe C code, it's interesting to note that his implementation of "bc" prominently contains a file documenting memory issues in previous versions. If that's what borderline obsessive gets you, how are us normies who are only programming to pay the bills, who have to work with other people who also just want to finish what they are doing or interact with blobs of code written by other people with less exacting standards supposed to write memory safe code?
It's a framework. It's a set of C macros and C code. It's not a new language. Please stop.
> The final reason is the only one that justifies my decision: my code will be rewritten in a memory-safe language.
> No, it won’t be Rust. It’s my own language. It’s called Yao.
If you wanna write your hobby programs in C because you think it's fun, then fine, you do you. But this seems like a pretty good indication that basically no C written by anyone can realistically be truly safe.
If the author's reason is "because I can get the same features as Rust with much more effort" they've failed to justify it and thus that reading.
Even malloc | free aren't vital as memory is preplanned and can be retrieved from an RTOS in a single block at startup.
> Using glibc in avionics software is insane,
As I said above .. there's no need for glibc et al.
> I feel like you are missing the point.
We seem to be in agreement here.
> In other words, it’s asinine to pretend C is somehow more reliable because ...
What most people call "C" is (preprocessor) + (actual language) + (stdc function library).
What I call C (and hey, maybe that's just me) is just the language component, the "below the fold" library spec in the ANSI Std is easily disregarded .. it's more of a dated "proof of concept" of (for example) one of many ways of handling strings.
C is a nice language - the preprocessor and stdlib have issues.
Christ, I wrote it as an absurd notion in the first place. This is honestly like writing “go ahead and wear underwear on your head” only to have someone tell repeated tell you that isn’t necessary. Well, no shit.
Language doesn't matter.
The next reason is that during my time with C, I have developed a custom software stack designed around memory safety.
[...]
In other words, I am not using C; I am actually using the partially memory-safe Gavin D. Howard dialect of C.
> I can write C that frees memory properly...that basically doesn't suffer from memory corruption...I can do that, because I'm controlling heaven and earth in my software. It makes it very hard to compose software. Because even if you and I both know how to write memory safe C, it's very hard for us to have an interface boundary where we can agree about who does what.
So like Lisp, C might end up being a solo programmer’s tool too. But not because it is a breeding ground for DSLs but because everyone is adhering to different conventions in the absence of the compiler enforcing one.
What you said is:
> I can write C that frees memory properly...that basically doesn't suffer from memory corruption...I can do that, because I'm controlling heaven and earth in my software. It makes it very hard to compose software. Because even if you and I both know how to write memory safe C, it's very hard for us to have an interface boundary where we can agree about who does what.
And I stand by my point. Single-responsibility principle will get you covered, yes, even in C.
> I actually am not asking for your opinion --
You could show some respect.
> I'm asking for a link to the implementation itself. The details here matter
B-tree btw is a silly example which particularly is not among the hard design problems out there and there are dozens of implementations laying around. Obvious examples to look for would be in transactional database systems implemented in C.
> (and indeed, that's the whole point).
... and the point not being quite clear, even after politely asking for a clarification, so perhaps next time you don't try to play the authority but try to provide an actual example to support your otherwise questionable claim. I'm sure Rust community will profit from individuals like yourself.
All this is a reflection of the so-called Lisp curse, the fundamental problem with Lisp -- its great strength is simultaneously its great weakness. It is super-simple to customize Lisp to suit your personal tastes, and so everyone does, and so you end up with a fragmented ecosystem of little sub-languages, not all of which (to put it mildly) are particularly well designed.
[1] http://blog.rongarret.info/2023/01/lisping-at-jpl-revisited....
The author adequately defends their predilection for C, which was never doubted; they don’t produce a great argument for why C is good (which, perhaps, they didn’t intend to). Most of the defensive programming techniques covered in the post reflect this: asserts, for example, only catch the bugs you know about.
There are all sorts of valid arguments for not immediately porting over the huge legacy of C/C++ code bases to something less likely to blow up in your face. However, the amount of valid arguments for starting new code bases in those languages is rapidly declining. I'm sure there are some corners where you just have no other valid choice and that's fine. But increasingly it's just a matter of people being stubborn, rigid, and unwilling. Half the success is just understanding your own limitations and mitigating those. The rest is just dealing with the inevitability of people messing up.
> they don’t produce a great argument for why C is good (which, perhaps, they didn’t intend to)
Never intended to.
But yes, I am one of those weirdos that use C for their personal projects, and yes I find it "fun" to fire the debugger to look for my own mistake, see my code run magnitude slower through Valgrind to find my memory errors, and yes I know that my code will be riddled with UB and other kind of "fun" error, but again that is expected because (well) it is C. And I do it on my commute while ssh-ing with my phone.
And while I am very impressed by the progress of Rust over the years. There are two aspects that kind of put me off.
The community does come as very preachy and the language sound very close to the Ada language ( as in "not fun to work with"). And so far those two haven't been disproven.
So maybe the day that I would have to write life critical software as a hobby I would consider writing in it in Rust. Or maybe in order for Rust to succeed it would have to make the other languages far less fun.
There is something magical about wri5ing code that is as fast as C++ but with a fraction of the bugs and effort.
Seconded. After you use it for a few months it begins to click and makes sense.
I use C and C++ when I have to work with legacy code, but choose Rust for new projects.
It takes a while to get to the point where writing Rust feels easy, but when you do it's so much fun. That's why Rust users love the language so much.
That said, writing an ultra performance program in Rust is easier than using any other language in existence rn.
Arguably, you don't. The big difference is whether your compiler enforces and tracks your documentation, assumptions used by your code, often critically important for correctness. Unfortunately, Rust is far from being perfect in this regard (e.g. SPARK probably does a better job here), but it significantly improves on C/C++ in this regard.
>I Work Alone
Unfortunately, even if you are the only soul touching the code, it often quickly becomes false. On a big enough project, "alone" inevitably becomes "me and that guy who wrote this part of the code". This also can be formulated as "me and 2-years-ago-me". In other words, we quickly forget a lot of context used for writing a piece of code.
>Rust is too big for my small brain, unfortunately.
I think the lack of hubris, the understanding that small human brains are not enough to keep track of all necessary context required for writing correct software is the key element for liking Rust and similar languages. Rust is not about building ivory towers of abstractions for the sake of it (though some people try to walk in this direction), but about offloading as much as possible of the context on compiler. Unlike humans, the compiler does not get tired, it does not forget. Yes, it's limited and because of those limitations it requires to restructure our code and sprinkle it with additional information, but more often than note it's a good thing.
As sel4 and other formally verified software demonstrates, it absolutely can be done in C. But one could say that C used in sel4 is not a C language anymore. After all, you can not take a random C library and use it in sel4.
1) Why are we explicitly directing a loop forward or backward most of the time when it's not necessary. The compiler should direct the loop unless we want to explicitly do this for the body of the loop. My thinking is that there may be performance reasons to reverse a loop or even split it into separate threads. (unlikely)
2) In C++, I've always wondered how template types get instantiated for POD that is represented the same at the bit level. Does the compiler duplicate the templated code or is it smart enough to say "this std::vector<int> is the same as that std::vector<intalias>". Rust prides itself on zero-cost abstractions, I have wondered if they reduce binary bloat in this area. (as a naive C++ person)
2) It duplicates, and the standard even comes with asinine "guarantees" that actively sabotage deduplication, such as requiring all functions to have different addresses. Which means the compiler can reuse the same function, but only one function label can start right at the code and the others need to NOP-slide or JMP into it. Which unduly pessimizes precisely those functions that are most likely candidates for deduplication: Those that themselves only consist of 2-3 ALU instructions.
And this goes without even mentioning LTO, which has been explicitly designed for optimizing the code layout and size during the linking phase.
So, code deduplication is a real thing and happens regularly with your code. Templates are no much different than the non-templated code written for the same purpose.
But without LTO, it's impossible for the compiler to know whether a non-inline function with external linkage will be called or have its address taken, so the compiler must ensure that it has a unique address.
The point stands. Compilers cannot merge equivalent functions in cases when it makes sense to even think about this optimization, which is when it actually has to export an externally visible symbol for the function.
for (i = 0; i < length; i++)
for (i = length; i != 0; i--)
As for why you sometimes do one over the other. I think it is true that computers branch on zero more easily than other values. That said, I'd be a little surprised to know it makes a difference that can be measured in any meaningful program.
int i,n;
for (i = 0; i < length; i++)
n = something();
return n;
int i,n = 0;
for (i = 0; i < length; i++)
something(n++); /* Compiler will merge the n and i variables */
return n;
int i, n = 0;
for (i = 0; i < length; i++)
n = i + 1; /* A very roundabout way to say "n = length" */
return n;Loop inversion, unrolling, and splitting. The compiler can do so much with a loop to make it run faster on 'this machine' to optimize for speed, memory use, or binary size.
I love that Rust has eliminated the egoism around "you should know at all times when something is allocated or deallocated". We're trusting the compiler to do that better with zero cost to us. So take it to the extreme: Only specify the loop direction if you have a true requirement to do so.
This is my Ted Talk, thank you.
For #2 - LOL! I had no idea it was essentially aliasing those functions to get around a requirement for uniqueness.
> I’ve written code in so many languages:
[omitted list of a couple dozen languages]
> and many more.
> When it comes to the enjoyment of programming, I hate all of them. With a passion.
> Except for C.
I get the sense that this is the real reason, and the rest of it is justification that they understand the risks involved but choose to do it anyways. And honestly, I think this it's fine? I'd argue that it's a little inconsistent with their statement above that avoiding C/C++ in lieu of memory safe languages and should be followed by default, but they subsequently admit to being hypocritical about this, so I'm not really concerned that they don't understand the benefits of memory safety. When it comes down to it, I have middling confidence that I would be able convince someone who still at this point doubts that Rust is safer than C, but I have absolutely no illusions that I can convince someone to change a personal preference. If anything, it's a bit refreshing to see it freely admitted, given how often it seems to be the real reason for a lot of choices of what language to use (and I don't just mean this for C/C++, but for any language, including Rust).
Lots of people have pointed out flaws in his arguments here. There are always at least two collaborators on a codebase: you and you in two years time. You can enforce your own documentation best practice, but it's always possible to make mistakes unless you have a probably correct way of enforcing those best practices. I'm sure there are other very valid criticisms.
But in the end, there's a good chance that 100% guaranteed memory safety actually doesn't matter for the software that write. If you told me this person writes software for pacemakers or ABS systems or something similarly safety critical I'd take issue. But beyond that it's a sliding scale from merely irresponsible to an inconvenience.
My monorepo (the "current project" linked in the post) has or will have:
* A compiler library (replacement for LLVM).
* A programming language.
* A build system.
* An init/supervision system.
* A VCS/project management system.
And maybe more.
I CAN code in a lot of languages. The only one I have no interest in ever revisiting is PHP. I rather dislike java's bytecode but the language itself is somewhat ok. But I prefer C. Not just due to "bare metal", but also because it's fairly easy to communicate with other hardware.
I'll note - when multiple different hardware is involved, you'll never get "safe code". Not unless the hardware is "safe" too. I think the thing I'm wary about rust about is how much its claims depend on the underlying hardware being consistent, reliable and stable. But - I'll use whatever tools employers or contractors need. I think the hardest language for me is C++ - as above - because it's so "flexible" (and hides so much under the water) that it takes rather a lot of investment to learn every new stack.
I use C on my own projects. I've yet to see a good argument to explore another option and still maintain consistency with communicating with disparate hardware.
I argue that for certain applications, the ability to work directly with memory is paramount. I shaved 35ns off of a critical routine the other day with a clever memory hack. And in another example, I doubled the speed of a critical loop simply by rearranging variables within a struct so that the CPU had more efficient access to them by avoiding page cache faults.
Mind you, this code already runs hundreds of times faster than anything written in Go or any other garbage collection language can do.
It's hard to justify the effort to write fast code nowadays without talking about cost or revenue.
Rust is harder because it imposes constraints on the programmer in order to enforce memory safety. These constraints don't magically disappear if you are trying to write memory safe code in C.
Thing is, if some system/concept/abstraction/model is memory-safe, more often than not it directly translates to Rust concepts via lifetimes and the such. If you've done it a number of times, you will find it very easy to map the former to the latter. In the rare cases when it doesn't fully translate, you can always dip into unsafe (usually at the lowest levels of your abstractions), same as the Rust's standard library does, and test/fuzz that part extensively.
We have all been there where we have written code based on a faulty mental model which resulted in bugs. Yes. And more often than not, Rust would have prevented those bugs or made them less severe. But we have also all been there where we have had a solid mental model of what a system is doing and written correct code.
Rust helps in the former case, but it makes the latter case harder.
And no, it's not the case that "more often than not", if you need one const reference and one non-const reference to some data, your code is wrong. In fact, almost all code in almost all mainstream languages end up with multiple references where at least some are non-const, and it's fine most of the time. In Rust, all of those situations require type system and borrow checker gymnastics.
I'm not against Rust. I think it's a fine language. I also think it's significantly harder to write than most other languages if you don't want to just punt and use Rc<RefCell<T>> all over the place.
The same cannot be said for C++.
https://github.com/Apple-FOSS-Mirror/Libc/blob/2ca2ae7464771...
> The final reason is the only one that justifies my decision: my code will be rewritten in a memory-safe language [which I wrote and designed].
Oh look. Haven’t seen that conclusion before.
In the 90's it was very common that big shops that did some programming would have their own languages, which continued into the 00's in the form of everyone rolling their own C++ standard library. I had the "pleasure" to work with both. Invariably, this stuff was so much worse than off-the-shelf stuff and yet the authors believed themselves to be geniuses.
I mean, there's a chance this guy did something outstanding and actually improved something about C, but so far I've seen so many fail to do that in such a predictable patterned way I just don't want to see any more of that.
My favorite C code is the one that has no macros, as few of typedefs as possible, no acrobatics with alloca() or any platform-dependent stuff. I think, FIO is a good example of what I'm talking about.
The whole thing just sounds like "yeah, it's a swamp, but it's my swamp and I like my swamp!" kind of thing.
I know this. The only reason the custom stuff works for me is because it works for me. I accept no outside contributions, and this is one reason why.
It sounds like you're talking about using libraries as if it was a bad thing.
> had the "pleasure" to work with both. Invariably, this stuff was so much worse than off-the-shelf stuff (...)
Where do you think "off-the-shelf" stuff comes from? It sounds like you're trying to mistepresent the adoption of subjectively sub-optimal libraries as somehow the issue caused by using libraries and frameworks.
> mean, there's a chance this guy did something outstanding and actually improved something about C, but so far I've seen so many fail to do that in such a predictable patterned way I just don't want to see any more of that.
You're showing a tremendously naive and misguided belief that libraries are somehow bad.
Languages such as Rust flourish with the adoption of third party libraries,some of them euphemistically described as "not stable". Languages such as C++ flourish with third-party components like Boost and POCO. But applying the same principle to a language like C warrants an automatic and mindless putdown like blindly accusing anything of being bad? It makes no sense.
Many people that go off the beaten track often fall into the same ditch.
Third-party libraries were not born out of the thin air but because of different parties having different and very much often disjoint requirements so it's not particularly NIH syndrome.
You're somehow trying to imply that libraries are not reusable if they are not widely shared, which makes no sense at all.
The best argument you could make is regarding stability, but you simply cannot lay any such claim just from the library's licensing.
Accusing internal libraries of being half-baked, badly designed, or bug-riddled is just a cheap blanket putdown.
I don't see the relationship... how do you make such a leap?
> Where do you think "off-the-shelf" stuff comes from?
I worked on proprietary projects that eventually went public domain. So, I can tell you where off-the-shelf comes from from personal experience. Proprietary in-house tools have the benefit of not having to deal with many things that an off-the-shelf tool would have to deal because they can choose the kind of hardware to run on, the kind of supporting libraries, their versions and combinations to use, the kind of developer tools to support and so on. off-the-shelf tools, in order to be successful must cover a much wider area of ecosystem in order to be relevant.
Here to give you a better example: C doesn't have its own concurrency primitives, no concurrency model etc. But, you could build an extension, let's call it CC to have some sort of concurrency based on pthreads library. If, for your internal needs, you only use CC on Linux -- you are golden and everything works fine. Once you try to make CC into off-the-shelf product you have to do something about pthreads missing from other platforms.
Off-the-shelf products are typically born as in-house products, but they need an extra step to become what their name implies.
In the specific case of what OP described as their own extension to C, I can vividly imagine a language that doesn't cut it as an off-the-shelf one. Making an off-the-shelf language would've also guided OP to a much larger departure from C because memory safety is only one of the big problems with the language. And this is what happened to a bunch of other languages which already walked a big chunk of that departure journey. This is why I would've been frustrated having to use the language like OP's: it would've felt like not enough change and too much headache to adjust to my target environment than could be had by using actual off-the-shelf languages.
> You're showing a tremendously naive and misguided belief that libraries are somehow bad.
I have no idea where you get this from. If anything, I say the exact opposite...
You've just outlined a perfectly good subset of C. I'm pretty sure people who write C extensively even to this date mostly end up there. The beauty of using C these days is that one gets to control every single byte without going through hoops and loops. Also, any C code can be reliably integrated into other languages using FFI, which is quite universal. So, yeah, no need to create dirty hacks.
No, not even close: Struct padding, compiling switch as if-else vs. jump, implicit arithmetic promotion to int, stack layout of local variables, and many other issues.
If you want to control every byte, write in assembly language.
Quite literally.
The F-35 software is C++ code:
- It’s their subjective opinion (the author makes that clear)
- The author works alone
So there’s no risk that one would have to work with this dialect.
Don't worry; I do not accept outside contributions, so this code will not be imposed on anybody but myself.
But it works for me. It fits my brain really well.
However, it has nothing to do with commercial software development, where system architects should think not only about the "coolness" of technology, but also about people who will support the final product. And team leaders think about how hard it would be to hire people who know how (and are willing!) to work with the said "cool technology", and since we are talking about statements like "I have developed a custom software stack designed around memory safety", i.e. non-standard solution with no documentation, (while there are alternatives, where memory safety assumed to be as a pre-requisite, not as an implementation artifact), actually, "close to zero".
I was writing in C and classic C++ for 17 years, and I admit it is fun and challenging to design and implement systems using these tools. However, when in my team we have a library that we're expected to develop and write in C, I rewrite it in modern C++17 (I don't say "in Rust" exactly because of the second reason, but modern C++ is safer than old C by an order of magnitude), and the process rarely takes not more than 1 week. As a result its source code usually becomes about 10 times smaller, implementation faster in 80%, and the team is spared of wasting their time exploring undocumented solutions written decades ago.
Specifically, I do not think I'm smart enough to violate the Chrome team's Rule of 2: https://chromium.googlesource.com/chromium/src/+/master/docs...
> The Rule Of 2 is: Pick no more than 2 of untrustworthy inputs; unsafe implementation language; and high privilege.
I do know of a few C programmers I'd trust: DJB, many of the OpenBSD team, the Dovecot maintainers, and a few others with long track records of security.
But I don't trust myself because I've used fuzzers on my Rust code, trying billions of inputs. And I've found DDOS bugs that would have been potential exploits in C.
What's more damning, the most careful C code I ever wrote has an enormous, sneaky test suite. It was tested with every sanitizer I could find. It used carefully designed error handling conventions. Still, in the last 20 years, it has been the subject of several CVEs. You see, I relied on a high-quality 3rd party XML parser, and that parser had a handful of bugs.
Out of 7 billion people on this planet, the number that I'd personally trust to reliaby write CVE-free C code is in the low triple digits. I'm not one of them.
Understanding Rust is a cakewalk compared to understanding "undefined behavior" in the C standard, or to making sure a large C program never overflows an addition, or accesses memory out of bounds. But Rust is not the only option. Use Go or Java or Ada SPARK or a functional language or WUFFS. Any are fine.
As an industry, we need to stop making the same endless security mistakes. It's not OK.
At that point it's hardly the fault of C. Even in supposedly "memory safe" languages like Java, XML (and json) parsers are often riddled with bugs and design problems that can be exploited for remote execution. It's a joke, but these parsers are still somehow considered "best in class" because many supposed "programmers" are willing to trade security for the ability to write annotations.
I'd say that what you describe in your software is exactly what i like about C. You know it's dangerous, so you take precautions. You then discover that those precautions maybe aren't enough and you go looking for something more stringent (like rust). There's learning there. If we cargo cult Rust as "what people should learn instead of C because it's secure" bad programmers will go write poorly designed rust code that's as unsafe (if not more so) as any C code, except now they won't be careful because "the language is safe".
What level of cope is this? "Bad language is better because we know its bad so we become better!" Every time someone argues for C or C++ I replace them with assembly and C respectively. The argument makes about the same amount of sense.
But none of that is an argument for learning C and then stumbling into a safer language after doing that, since then you have to learn (say) Rust as well as unlearn your C (or whatever unsafe language habits) as well.[1]
[1] https://www.reddit.com/r/rust/comments/10rnymj/my_reaction_t...
What we learn from history is mostly "holy shit that was fucking awful thank god we stopped doing that!". Except for programmers it seems. I have no objection to learning or using C but we don't ride horse caravans around anymore.
Why do we think this is OK, even for a moment? For how many decades will we accept massive vulnerabilities everywhere? We can't rewrite everything, but why isn't Chrome's "Rule of Two" a minimum professional standard for new code?
This isn't just a Rust thing. For example, why don't more languages allow me to say, "This XML parser is forbidden from talking to the network or file system"? Why could log4j load code without being granted special permission?
If there were some syntax, then you could even specify the particular network endpoints or file system paths allowed.
It is sort of old fashioned, a sort of dynamic scoping of access context, but would be better than you call a shared library which starts up some threads with network connections all invisible to you.
There would be some idea of the main function and spawning threads or green threads would also need to specify what that thread can do, a subset of what the creating thread can do.
There is no sheriff to enforce this guarantee. There's nobody come to save you (us) from ourselves. You can try to build walls around things, but meanwhile other people are building ladders (or digging tunnels).
It gets worse though. Virtuality, whether via literal VMs or COWbuilder-style containers, means that defining what is means to access certain resources is hard to do. For the most part, this resolves nicely (i.e. you almost always have less significant access to "the real world" than you might believe), but it's not trivial to determine.
The point is that the code, at runtime, cannot determine what context it is running in, and it may be entirely appropriate for it to do certain things, or highly inappropriate, depending on that context.
It has nothing to do with language.
Maybe we need a different OS/process model?
The tldr being a very powerful and lightweight sandboxing mechanism complemented with a OS mediated ipc layer wrapped by language idiomatic libraries.
Unfortunately fuchsia is taking it's own sweet time to play out.
My language will have some sort of what you are talking about.
(In old LISP stuff, you used to be able to do like:
(with-stdout-redirected-to-printer (whatever-func etc))
and all the stuff whatever-func called would print but it would be redirected to printer.
In my language, there are packages. You might have a left-pad package, for example. (Okay, it's a bad example, but whatever.) The programmer/user gives permissions to packages at the package level, so you might give the left-pad no permissions at all except for allocating memory (for generating a formatted string), which means something else will need to do the output.
These permissions can include anything, like being able to use other packages, network access, filesystem access, etc. Static dependencies will be the first line of defense, but if something need dynamic access, say access to specific files such as `/dev/urandom` or `$HOME/.config/<program>/config.txt`, there will be a dynamic way to give permission.
This dynamic way will probably serve a lot of the use case you suggest.
This will be at the compiler IR level, by the way. The build system of dependencies might otherwise be able to get around it. But with IR, you can tell the dependency's build system to generate the LLVM-like IR for its code, and its build is done and can have no more influence.
Then without using any of the dependency's code, you can then specialize the IR while inserting permission checks.
You can even use this to generate cross-platform "binaries". The "binaries" would just be a tarball of IR. Most IR would be used for any platform, but some would be platform-specific. If you include all of the platform-specific IR with the platform-independent stuff, you can then ship that tarball to any machine, which, on trying to run it for the first time, will realize it needs to be specialized for that machine. This includes inserting permission checks based on the policy for that machine.
Yes, it will be that powerful. My main concern is that it will be too powerful and thus have bad user experience or a steep learning curve. UX matters.
I don't have it solved yet, but I'm trying.
If we did electrical engineering like we did software every gadget would come with a fire extinguisher. If we did civil engineering like we did software engineering we would have daily bridge collapses.
In the dawn of modern civil and electrical engineering indeed many catastrophes happened, and they did happen till culture changed and had an inpact on the education of future engineers. This point has not been reached at all with software engineering outside of safety critical applications.
And, really, this is no different than anything else. Just in an odd "reverse" direction. Lets say someone makes brake pads for your car that have an antenna and compute on them. How would you keep them from communicating your location to anyone else? You can work on detection, of course, but for the VAST majority of vehicles out there, this would be silly at that point.
Same goes for why you use locks that can typically be unlocked with a toothpick in bathrooms. Privacy locks are vastly different from security locks. Even though they look roughly the same on paper. And this is clearly ignoring every other thing that makes you vulnerable outside. Why do we allow satellite imagery of people in their backyard? Mainly because we don't have a realistic way of disallowing it.
Because that's not up to the programming language to decide. In which context a particular piece of code is executed is out of scope for the design and compilation phase of your program -- that's part of the application deployment, and that deployment is usually not written in the same language as your program.
What you're asking for is basically the microkernel approach applied to applications: each microservice has its own capabilities and data access, and control is passed through RPC. This exists, and it can be implemented in any language (though more readily in some than in others), but this is not a programming language feature: it's a runtime feature that must be provided by the environment (whether JVM, Linux, Docker, SeL4 or browser) in which your code is deployed.
There's actually a lot of really neat research in this space, including:
- "Row types" for effect systems, which allow the compiler to cleanly keep track of what code has access to what parts of the outside world.
- Capability systems, where you essentially need "handles" to access things in the outside world.
- Strong-typed unikernals, which use either of the above approaches to replace the process boundaries in a regular microkernel.
Admittedly, none of this is exactly ready for the mainstream yet. But there are plenty of ways to help address these issues at the programming language level. And I think this is worthwhile, because as the Chrome team has pointed out several times, trying to stick every parser in a seccomp-isolated process is a lot of hard work. And it rarely gets done in practice.
Given the sheer number of dependencies many projects have the days, and the growing number of "supply chain" attacks against libraries, I think this is worth all the effort that's going into right now.
Maybe in 10 or 20 years, we'll see some commercially-acceptable languages that explore this space.
The huge benefit of having a strict compiler like Rust's is that it massively raises the quality floor for every single library in the ecosystem. This is especially true if a library doesn't use unsafe (which is true of many Rust libraries including the most popular XML library https://lib.rs/crates/quick-xml).
> bad programmers will go write poorly designed rust code that's as unsafe (if not more so) as any C code, except now they won't be careful because "the language is safe".
The whole point of the language being safe is that you can't write code as bad as C code (e.g. contained RCE vulnerabilities) without going massively out of your way by using an `unsafe` block or doing something obviously stupid like passing an unsanitised string to `exec`. It won't compile. I would absolutely trust carelessly coded safe Rust code over carefully coded C (unless that carefulness is taken to the extreme as in MISRA-C or similar).
I suspect most C programmers just wouldn't like the constraints, or would be concerned with performance degradation, and that's the real problem.
Edit: another avenue is to also use Frama-C to check your code.
You end up with something that resembles the set of programming requirements from Rust (if you leverage lifetime annotations) or you end up with something resembling a refcounting GC (if you demand the use of shared_ptr everywhere).
This cannot really be "attempted properly" at scale. To implement this with C you need to both superset and subset the language. To implement this with C++ you need to harshly subset the language. Both communities hold backwards compatibility as a huge goal, making it impossible to move in this direction. A project like Carbon seeks to incrementally move in this direction, but required breaking off from the C++ community. Projects like Rust just rip the band-aid off entirely at the beginning.
The "don't worry, C is fine if you just don't suck at programming" folks don't tend to push for these extreme changes.
Edit: one example of a pattern, whose name I can't remember, was to switch from returning pointers to data structures, to returning pointer offsets as handles. Using these handles you can then track more information about validity and handle "null pointers" more sensibly rather than it introducing undefined behaviour. In superscalar processors the offset calculation basically costs nothing, but the additional safety can be considerable. I believe I read about this pattern in game engines, let me know if you know the name of it!
Edit 2: I think this is it:
https://floooh.github.io/2018/06/17/handles-vs-pointers.html
But you can still see important limitations. Chrome, for example, has custom smart pointers (miracle_ptr) and still has UAFs galore.
Does Rust help with integer overflows? AFAIK it is as unsafe as C w.r.t. that.
You also have access to `checked_mul` and friends, so manually writing `i.checked_mul(j)` will add checks[1], without needing to use undocumented vendor specific builtins, like in C/C++[2].
[0] https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html [1] https://doc.rust-lang.org/std/primitive.u32.html#method.chec... [2] https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...
Overlow panics in debug mode. And in release mode, overflow is defined to wrap (2's complement) instead of invoking undefined behavior. One of the big dangers in C is "nasal demons", after all: https://en.wikipedia.org/wiki/Undefined_behavior
But I've fuzzed a gnarly parser written in Rust, and actually found overflows. None of those overflows were exploitable (as more than a DDOS), because safe Rust also does bounds-checking on arrays and slices.
Rust isn't perfect here. But in practice, it manages to mitigate almost everything anyways, because of boring ancient techniques like bounds checking. And the excellent fuzzing tooling makes it super easy to test parsers aggressively.
Quiet overflow was sort of defensible on 4 MHz machines, but now Costco has desktops with a dozen cores each a thousand times faster. Moore’s law has more than paid for bounds checking and overflow exceptions (or even bignums) and we should be using them by default.
My number is zero. I do not believe it is possible to build a truly safe C program of any meaningful complexity.
I simply don't write only C, or these days much C at all. What I write mostly is Python, and if I can't optimize that enough then I write C; or call C. Of course when you're calling somebody else's libs, all bets are off; and I don't think it matters what language the lib is written in.
The last time I needed a serde that "went to eleven" I wrote it in Rust using PyO3. I'm not saying it was good Rust. I wouldn't know. The compiler is a bitch. It's too hard to reason about the machine. Luckily, I wasn't asking it to do much except some byte hacking in a buffer.
Reasoning about the machine is becoming more problematic as exotic architectures proliferate and compilers unceasingly do increasingly weirder optimizing shit. Dunno if it matters what the language is.
We use rust and zig in house for our development and while rust is preferred for complex projects, we prefer zig when we need: super portable code, code that will work with a static memory buffer or datastructre that are hard to use in rust (like self referencing).
We still have some chips that requires C because they have proprietary compiler, for those, we are very eager for the zig->C compiler that should be coming some day.
I mentioned that I hate Zig. I've tried it. I do not like it.
More power to you, though.
* I don't like how compile-time code can be mixed with runtime code. The idea is nice otherwise, but it confuses me.
* I spent a long time trying to understand Zig's async ([1]) and came away with more questions.
* I don't like the async model in general; I prefer structured concurrency. I think this is a mistake in Zig.
* The Zig community has put me off, though some of that is my own fault.
This is just a sample. I've written more other places, but I don't have access or can't remember where right now.
[1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...
I agree that async is peculiar, but I think it is still too early to decide if this works or not.
I feel bad that my brain doesn't work with it.
You have copy-paste operators like `inline for`, `inline while`, and `switch (x) { inline else => {} }` that focus on generating code given a value known at compile-time (think of it like running a C program to print out the code within a `for` loop then inlining that in your code) and are great when you need to unroll a loop or loop over the fields of a struct (e.g when printing it). If you find those difficult then try printing the code they inline to get a feel for how it changes your program or writing what they'd inline manually.
For the more template style `ArrayList(T)` style you can follow the logic yourself by writing the struct it would result in when you substitute the parameters (again a copy paste but with slightly more going on) and any more calls with the same parameters will always return the same struct back.
Branching at compile-time is like having a smarter `#ifdef` for the most part where you use `if`, `switch`, and other control-flow to decide which code should remain in the program as long as the condition is known at compile-time. This logic can be applied to the copy-paste operators too depending on the condition.
Async is very experimental and not complete so it's currently difficult for most. It can be thought of as a fancy way of creating a state machine with `.nextState()` being the `resume` keyword making it not a function but by having the compiler perform a little magic at compile-time it's possible to write code which doesn't care about this until you get to function pointers as then the difference starts to matter. If you want a C equivalent have a look at https://c9x.me/articles/gthreads/intro.html which covers it pretty well and it's almost what zig does for you with the `suspend` and `resume` keywords. `async` and `await` should be understood in terms of `suspend` and `resume` as they exist at a much higher level and can be a bit tricky. Another way to get a quick overview of what it's doing is to have a look at generators in python with `yield` and their equivalent with writing the state machine yourself as a class as it's equivalent.
If you feel like trying it again, don't be afraid to reach out on the zig room on matrix. I'll be happy to help with comptime and related things as it can be a bit difficult to grasp.
Oh and don't give up! The best parts about learning is the rewarding feeling when it finally clicks after all the hard work.
Thank you for the offer, but Zig really doesn't fit my brain. Nothing against Zig, either.
At least this one isn’t incoherent because of this kind of transformation, that happens sometimes.
What @steveklabnik said is correct. I knew this and actually added the "Why" back in manually after posting.
Then someone came along and removed it, along with my title case, which makes me sad.
You can put guards on a razor blade, but it's still going to slice your finger.
> Yes, actually, but please hear me out for the rest of the post. I have reasons, I promise.
This is the kind of honesty that I live for.
so it's not just me
Basically, the author says that he feels unproductive in other languages so he's better off doing a good job in C than not finishing in other languages, and he enumerates techniques to reduce memory errors, freely admitting that other languages give that by default.
I agree that that's a good title. I have a thing against long titles though...
Your comment is also a good summary of the post.
It's in my current project at https://git.yzena.com/Yzena/Yc .
Code is at https://git.yzena.com/Yzena/Yc/src/branch/master/src/alloc/s... , and header is at https://git.yzena.com/Yzena/Yc/src/branch/master/include/yc/... .
I didn't read anything past that, because this is very much a "only way to win is not to play" kind of situation.
Once my own licenses have been looked at and adjusted by a lawyer, I'm going to drop the other two.
Until that point, the other two licenses are meant to make my code radioactive. This is so I have breathing space as I work on the code.
And because I own the copyright on most of that code free and clear, I am well within my rights to license the code under all three.
There won't be pointers, and I think everything will be passed by value.
I'm not sure that compilers can optimize this and "move" returned data. But the goal is to greatly limit side effects and improve cache locality by encouraging the coder to use more functional habits instead of oop.
There are grey areas because I'm not sure the design is sound, but even if it's not, it can be safe and fast enough.
I didn't say it's a good idea… Isn't that how PHP started off?
But, we need to recognize the size and coverage of the test suite involved with this product... I would be curious if any maintainers of SQLite have some commentary regarding the impact of unsafe programming on the extent of the testing.
They sort of do, yeah
One thing I LOVE about C is the offline documentation for standard libraries. Beej’s guide to network programming is amazing but also reproducible with “man socket” and then wandering down the rabbit hole. (Ref: https://beej.us/guide/bgnet/html/split/)
C++, the sprawling beast that it is, you have no choice but to consult some web page to get decent documentation. The same goes for Rust (Please let me know if I am wrong here, I have not used Rust in several years).
Maybe it’s just a personal quirk, but when programming I love to shut off Wi-Fi and focus on whatever it is I want to get done. It is not always feasible of course, but it is definitely my preferred way to work. And C is the most amenable language to being offline.
* offline documentation for the standard library and other things, via rustup
* the ability to generate full documentation for your project offline via “cargo doc,” including any dependencies
This has been in place basically forever, so you must have just missed it last time.
If we gradually destroy all semblance of individual thought and discretion and replace that with something that essentially approaches rule-by-machine, what remains is not far from an authoritarian dystopia in societal terms. Even more so when you realise the direction Big Tech is taking. Jailbreaking and rooting are an escape hatch that they're certainly trying to close with all the "memory safety" stuff.
C also has an advantage of being simple enough that a single person can write a compiler for a nearly full subset of it. The same can't be said of many other languages.
I'm not saying I can write 100% correct code, although I certainly try (and IMHO it's not too difficult to get close.)
"Freedom is not worth having if it does not include the freedom to make mistakes."
"The road to hell is paved with good intentions."
Apparently the road to hell is paved with vague slogans...
C is actually a fantastically complicated language, both syntactically and at the semantic and abstract machine level.
i am not sure i understand, are you saying that c and rust have the same semantics ?
Treating C like a “high level assembler” needs a rule like the cryptographic doom principle: it will inevitably lead you astray, and “astray” for C generally means memory unsafety.
you are right. however, i think c does a better job at being a model of an abstract machine than rust. if we restrict semantics to that, and the developer accepts that they need more knowledge than just c, i think the semantics are simpler than rust's. in the same way, dont you think that rust can create a false sense of security to those not completely understanding what protections it provides? if we see programming languages as a hci problem, then i think c by default offers more freedom, and consequently more unsafety. amyway i dont want to come off as hating rust, i think it is a good language, but more importantly its community seems fantastic and i wish it success
No: the entire point of Rust's design is that you don't need to know the abstract machine semantics to write Rust safely. The compiler enforces the semantics for you, rather than pushing them onto you.
If we are being honest with ourselves the truth is that even a language as nightmarishly complex as C++ is preferable to C. And whether or not you agree with that the fact is that the world marches on regardless.
Am I dreaming?
The ability to write your own compiler for a language... that's related to the above?
except... Forth or Pascal, perhaps?
If they were, things wouldn't be the way they are today. Perhaps you're saying that they are, but can only express that position in the form of subtle exploits (which seem to be decreasing over time)? No, I think the majority of engineers are overwhelmingly complacent and obedient, and won't oppose.
As for why Rust, that's because the amount of prosletysing of that language seems to be far more than all the others.
Rustacean Abraham Lincoln might quibble on what freedom means in this context: https://news.ycombinator.com/item?id=34620164
To put it in other words, I want my tools to do whatever I want them to do and not the other way around.
Rust just says "This is an engineering project, not a philosophy paper, or science lab. It is not the time or place for experimentation, new ideas, and individual discretion, or for trusting each other or ourselves, we want reliability at all costs".
Which is exactly the attitude I want to see, when failure means I lose important notes, money, or get lost because GPS crashed, or my battery runs down because everyone was too afraid to optimize their brittle bug heaps, or a self driving car murders me, or we return to 1970s level tech due to nobody trusting software.
I'm rather fascinated that you put this in these terms, because I've seen the exact opposite (specifically the philosophy paper). The few times I've seen rust tried out, it seemed to turn into a competition between devs about how clever they could be with category theory. Then an abstraction stack grows until logic errors creep in because nobody understands what the thing is actually doing anymore.
I don't want to blame rust specifically for this, because the same thing happened with scala. Not sure what it is, possibly just a lack of dev discipline. I can't help but view this category of languages (rust, scala, haskell, etc) as competitive philosophy because I have to spend several hours sitting around pondering the nature of things before I can make minor changes from my jira ticket.
End result ends up being that someone usually re-writes an "interim" solution in java/go/etc, over a couple of sprints and then nobody ever gets back to the long term solution written in the elegant language because they don't have time to understand it.
They're all plenty skilled, but I'll give you the pragmatism one. A certain style of dev seems to have a compulsion to violate Kernighan's Law.
Eventually that abstraction hierarchy collapses on itself. I don't want to pin this purely on rust either, since I've seen it in plenty of languages (including java), but I see it happen often enough that I'm reluctant to trust my co-workers with rust at this point.
Or maybe they all can and I'll retreat into my little abstraction-minimal kingdom where the code's not very elegant, but I can figure it out, and I can onboard people in less than a month.
>> "Freedom is not worth having if it does not include the freedom to make mistakes."
>> "The road to hell is paved with good intentions."
Having a smarter compiler that prevents errors does not reduce individual thought or hinder creativity.
It incorporates best practices and discipline that should be followed anyway into the creative process to prevent errors at the source.
"Freedom isn't free."
"The price of freedom is eternal vigilance."
Can confirm :(
> I even run Clang with -Weverything
This isn't "discipline". Those warnings themselves aren't all tested and often don't work. There's no point in conforming to a broken check like -Wstrict-aliasing or one that could be arbitrarily hard to fix like -Wdeprecated.
There's a link in the post. It's at https://git.yzena.com/Yzena/Yc .
P.S. I see in realtime, reloading the post, the number of downvotes received (the score goes up and then ways down with the downvotes). Another problem is the Rust community. It has a very peculiar way to stay in this world.
But when you start composing things together and juggling the lifetimes of various things, the complexity balloons and it becomes a lot harder to understand "spooky action at a distance"-type things. You might argue that with good structure and discipline it's still not difficult, but the assumptions are all implicit and you have to get into the mind of whoever wrote it in the first place to understand it. And I write a lot of C and still find it tricky when I have to go look at some random C codebase!
Absolutely. C Code is not necessarily easy to understand. Not at all.
But the C parts itself are? In C you seldom wonder what C does, you wonder what the C code does.
If you work like OP likes, single person projects, small enough to keep almost completely in your head, I can see how C is especially charming. You never wrangle with C, only with your own code.
You do realise that C and C++ are among the languages (there is also Perl) having anual obfuscated writing contests, right?
Being self evident is certainly not something I associate with C code.
But usually the most controversial features are:
- use of exceptions
- use of RTTI and dynamic_cast
- use of stdlib types which allocate memory under the hood
- ...or even use of any stdlib types
- has boost or similar complex dependencies
- use of 'modern C++' features that explode compile times (like the range stuff)
...etc etc... when you look at C++ libraries written in the game development or embedded hemisphere, those usually use an entirely different C++ subset than the more academic "modern C++" crowd.
* core, whose only dependencies are six symbols (memcpy, memcmp, memset, strlen, rust_begin_panic, and rust_eh_personality)
* alloc, which layers on top of core, and adds the ability to allocate memory
* std, which includes all of the operating system specific things
But most importantly, you can declare that your code doesn't require std and alloc with an annotation, and there's a way to tag these crates in the package manager as well. Additionally, cargo has a "features" feature, so you can say "please give me the no_std version of the library" and get what fits within your needs.
My team at work is working purely in the 'core' subset, and we're able to easily find and evaluate open source projects that will work for us, because of this.
Oh, I should also mention: while Rust doesn't have exceptions, there's also a way to compile your program so that panics abort instead of unwind the stack, similar to -fno-exceptions being passed when compiling C++ code. There is also a setting you can include so that, if, for some reason, you require the unwinding semantics, if someone tries to build a project with abort semantics and your program, it will not allow it and let you know why. I don't think I've ever seen this annotation on a package in the wild, because since they're not used in the regular course of programming in Rust, virtually every open source library does not use them for important semantics and so therefore works with either setting.
Thoses are really bad footguns.
It's definitely fair to argue that Rust is complex. But this doesn't compute.
You don't like Rust because you're less productive with it so you write... C? Rust is so much more productive compared to C it's not even funny, even with its limitations and extra complexity that are necessary for memory safety. Things that take pages of code in C can be done in a single line of code in Rust.
This starts at fairly fundamental data structures. Need a hash map? In Rust you have one available, out-of-box, with state-of-art performance. In C? Implement one yourself. And good luck getting even a fraction of the performance the Rust one has.
Then there is dependency management and a huge ecosystem of libraries. Do you need to, say, encode an AVIF image? (Something I personally had to do.) Easy. `cargo add ravif`, and two lines of code later you're done.
I can keep on going, but I'm sure you get the idea.
I really honestly don't see how anyone can in good faith argue about productivity and say that C (out of all things!) is more productive than Rust. That Rust is more complex, sure. That you don't like it for aesthetic reasons? Fair enough. But not as productive as C? No way. Perhaps this is where the downvotes you're complaining about come from?
The libraries that make C more productive are out there, they are just harder to find than in the Rust ecosystem.
IME C programmers (including myself) separate a language and its stdlib much more strictly than (for instance) the Rust, C++ or Python crowd, mainly because the C stdlib is pretty much useless for anything that's not a simple command line tool (and because of such restrictions, C programmers also often use a whole language toolbox instead of attempting to write everything in C - Python and C go very well together for instance, right tool for the job etc...).
No. I also mean that the language itself is more productive, even without the standard library and the tooling. (Although, indeed, to a lesser degree.)
Sum types. Pattern matching. No need to bother with header files. A module system. Proper generics. AST-based hygienic better macros. Procedural macros. Stronger type system. RAII. A proper string type which knows its length. A proper array type which knows its length. Unicode support*. Async + await support. Support for closures. Ergonomic error handling (with the '?' operator). Proper abstraction for iterators.
Do you want me to keep going? Because I can keep going. (:
Again, this is more complex than what you have in C. And it is harder to learn. But that's not what we're talking about. We're talking about pure productivity here, so I'm assuming on one side you have someone who has mastered C, and on the other side you have someone who has mastered Rust. There's just no contest that the Rust person will get things done significantly faster than the C person, because the language itself is so much more powerful. (But of course it's a lot harder to master Rust, so the calculus might be different if you don't want to master your tools.)
* - part of Rust's core so also available in `no_std` contexts, so I don't see it as part of the stdlib but part of the language.
I would still argue that none of those language features really move the productivity needle a lot into one or the other direction. A good library ecosystem on the other hand does make a difference.
All in all, I would probably add fewer features to C than I would remove from Rust to get close to what I expect from a performance-oriented systems programming language (Zig is actually pretty close to that ideal, but that's a different discussion).
Ah yes, I won't disagree here; macros get very complex very fast. It's one of the more undercooked parts of Rust.
> e.g. I don't really see the usefulness of async-await in a systems programming language
This really depends on the task, but honestly it is genuinely useful. Even in places you wouldn't expect, e.g. in embedded: https://github.com/embassy-rs/embassy
And AFAIK there are plans to use async Rust in the Linux kernel.
> This starts at fairly fundamental data structures. Need a hash map? In Rust you have one available, out-of-box, with state-of-art performance. In C? Implement one yourself. And good luck getting even a fraction of the performance the Rust one has.
I've implemented a hash map in my code. I loved the experience, and I know more about computers and hash maps now that I've done it.
And my hash map was faster than the one in the C++ STL last I checked. I haven't benchmarked it against the Rust one, though.
Yep, everyone at least once should implement a hash map. Hash maps are so fundamental and so often used that it really pays off to understand what makes them tick.
> And my hash map was faster than the one in the C++ STL last I checked. I haven't benchmarked it against the Rust one, though.
The one in C++ is very famous for being really slow, so this is a low bar to clear. (:
Not sure if someone directly compared Rust's hash map to C++'s, but Rust's hash map is based on Google's SwissTable, so you can probably assume it performs roughly the same. Here are some graphs: https://youtu.be/ncHmEUmJZf4?t=2093
There's nothing wrong with the C++ hash-map. It's a different trade-off which makes perfect sense for something that is part of the general-purpose toolbox. See my response above for more details if interested.
Last time I checked, benchmarking hash-maps, or FWIW any other data structure, in the vacuum did not make much sense to me. Microbenchmarks cannot mimic or predict end user workloads well enough, at least in the cases where it's worth it.
That said, each implementation has its own trade-offs and in particular the one from C++ STL opted in for the pointer stability. For that reason alone, which I think is quite worthy, open-addressing conflict resolution is out of the question because it cannot give such guarantees.
With that in mind, if you're ok that a pointer to your key-value pair can all of the sudden be _invalidated_ by the mere operation of inserting or erasing yet another element from your hash-map, then of course, you can trade robustness for a more cache-friendly conflict resolution algorithm. But then again, this says nothing about the potential performance improvement unless you're able to measure it.
I pretty confident that this would go away if you write Rust for a few weeks.
I remember when first learning C, I struggled with some things too, but then they just clicked. It's probably similar when learning any new language (especially if they add something novel)
Just a random recent example: call an async function for a side effect without caring what its result is, Rust yells at you that the result must be handled "`#[warn(unused_must_use)]` on by default", so you'd think I would just annotate with `#[allow(unused_must_use)]`, but no way, you must store the result in a _ variable: "let _ = my_async_fn().await;". It's a great language, it's just ugly, sorry, not sorry.
[1] https://www.youtube.com/watch?v=rAl-9HwD858&list=PLqbS7AVVEr...
[1] https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html
Fun fact: Google-ing "syntax ugliness" gets as first result "Rust’s Ugly Syntax", https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html
In that case, yes, let _ is the usual pattern. But it’s rare that I ever actually want to use that. Typically I either return the error upwards or just unwrap. But if you truly don’t care about whether the operation was successful you can indeed ignore the error.
There are plenty of pain points with Rust but I don’t really think this is one.
Btw, the article you linked argued against the claim that Rust’s syntax is ugly, and instead claims that Rust’s noisyness is due to its semantics, largely in service of performance (which is why production C++ code is often similarly ugly).
For me Zig looks like something that could become a new C. They aim for great C binary and source compatibility (both ways - called and callable from C). It’s planned to be small and lean. And avoid preprocessor and UB as much as possible.
C++ is not a bad language at least because lots of amazing soft already written on it, but some people accept it with all of the myriads of complex rules with their own subset and some people totally disagree with this and just want Better(Modern) C with plain and simple rules without hidden complex things which happened behind the scene, and counterintuitive features.
About Rust is everything cool except sometimes it doesn't allow you to write correct code and push you to do things in ways that you don't like. But we are programmers and some part of us is a painter :)
Here's why. In spite of having quite a bit of experience with many functional and imperative languages before, and picking up new languages used to be a seamless experience. But Rust turned out to be an extremely frustrating experience. I was feeling like I couldn't tell the compiler to do what I wanted it to do any more. I took it as a challenge, didn't want to give up.
And when the first non-HelloWorld app actually got to compile and work (it was probably IPTrap 2, that implements a userland TCP stack), there was this feeling of accomplishment that I couldn't help myself sharing with the rest of the world.
Fast forwarding a couple years... I don't enjoy Rust any more. I still maintain Rust code, but it's a pain, not something I'm having fun doing.
First, memory safety in Rust is overrated. What it actually brings over GC'd languages is that two threads can't share the same pointer at the same time. Nothing else. If I'm not using threads, it doesn't matter. It's not any safer than PHP, Go or JS, but is far more complex. I won't provide memory leaks nor deadlocks either. To some extent, it actually encourages them (I'm often blindly adding Arc, Box, and Mutexes just to silence the borrow checker, not because they are actually needed).
Next, readability is not great. Too many sigils, and the language got more and more complex and less and less readable over time. I'm frequently having a hard time reading my own code after a while. Even more with other people's code. It often feels like people try to maximize the number of language features being used, so that the source code looks impressive, rather than keep the code basic and simple.
Finally, the ecosystem is very unstable. 3rd-party crates (even essential ones such as for error handling, due to limitations of the standard library) are constantly deprecated, abandoned, or having braking API changes. I gave up maintaining some projects, and keep using abandoned (even with security issues, such as old versions of hyper) with others, because the maintenance cost is too high.
After using almost exclusively Rust, choosing Go for a new project (dnscrypt-proxy 2) was enlightening. There were probably runtime bugs that Rust could have detected at compile-time, but overall, productivity was way higher. Making a change is straightforward, I don't have to think about the implications on the borrow checker. The compiler is fast. Performance is fine, and I can spend more time optimizing the actual algorithms than fight the compiler. Go tells you at runtime, not at compile time, if locks have been forgotten. But otherwise, memory safety is comparable to Rust. The runtime gracefully catches out of bound accesses to slices, null pointer derefs, etc.
I also still enjoy writing C code. It's good to have some freedom and control. But C also has rough edges. UBs, portability, minimal standard library.
Zig fixes many issues that C had, and is the language I really enjoy the most now. It's fast, portable, easy to learn, easy to read, has proper error handling, strong typing, catches out of bound accesses to slices and does checked arithmetic, and, overall, is a joy to use. Not to mention its seamless integration with C.
It doesn't have temporal memory safety, but, like Go, Zig's simplicity helps me reduce logic bugs, and focus more on algorithms than their implementation, overall resulting in better code.
Rust profits from "rewrite it in Rust", since it is more fun. But so does Zig.
Still, I am worried about the ecosystem, since every time I pull a bigger crate through cargo, I have to think of npm and the sad state of JS ecosystem. Also, I have a small, rewrite from python project at work and I am also worried whether it will be easy to upgrade in 2, 3, 5 years? If I write it in Java, it certainly will...
Fully agree on readability. It is not that Rust is unreadable, but a lot can happen in the background and you have to look hard for small sigils, presence of semicolons and blocks.
Otherwise there is Go, Haskell, OCaml, Java, Kotlin, Scala, Clojure, Lisp, Scheme, F#,...
If Redis works then the proof is in the pudding, I guess. But as an average/below average programmer I’ll stick to something more modern when I need that level of control.
Another possible conclusion is that your program design is just not as simple as you thought it was, and Rust is pointing out why. This drives you to make it even simpler, which is arguably good.
I like C as well, but I never kid myself into thinking that discipline and documentation can replace compiler restrictions. I've written large codebases in C, sometimes alone, sometimes in a team, and despite DECADES of experience and meticulous attention to detail, I STILL find the same old memory errors in my own code.
C cannot be made safe because you are not a god.
I mean this is demonstrably untrue: SEL4 is written by mere mortals, in C. It's safer than rust, there are formally verified security guarantees that include and go beyond the memory safety of rust.
It is the case though that c is an incredibly shitty language to do this sort of static analysis on because for example it's easy to do shenanigans like lexical macros that make the static analyzers job much much harder.
But fine. With that kind of dishonesty I could claim that the Linux kernel is written in nothing: I have compiled it and deleted the source code. Look ma, it’s no-code kernel.
[1] Kind of a bummer though that you cannot change any of the C code any more now that the verification code is gone.
If you used something else, you'd need to trust a lot more code.
There's CakeML, which is a formally verified subset of Standard ML [0]
Funky macros can still make static analysis more complex by introducing layer(s) of indirection of course.
But that's not a safe language; that's a safe work. ANY programming work - regardless of language - can be made safe via such expensive means, which puts this square into the space of "argument ad absurdum". You could argue that brainfuck or assembler can be made safe via these means, but everyone would rightly ridicule you for it.
Fuzzing wasn't mentioned in the article but the author does at least to some extended in their project, from what I could tell at a glance.
Fuzzers frequently also use instrumentation to try to figure out inputs that will hit more code paths in a more intelligent manner.
I fuzz religiously. I use it to generate lots of my test suite. I love fuzzing.
I've added a note about it to the post.
People arguing that "you can not ever write safe C" might also come to the conclusion that one "unsafe" somewhere in your Rust code potentially means that the whole code base is immediately at the same level of implicit memory safety as C.
No, the forced use of "unsafe" in Rust for some kinds of safety mechanisms to be disabled makes the code to audit easier to locate and reason about.
IF the code in the "unsafe" block does not actually isolate the "unsafe"-ness THEN conclusions can be drawn about the rest of the code.
Contrast that to C where the code introducing unsafeness, UB and unsoundness could be basically anywhere instead of a convenient "rg/grep unsafe" away.
I was just pointing out that, in the case of the particularly diligent OP, he is probably getting an equivalent level of safety - for much more effort though.
Even with just static analysis and some sane coding conventions you can get C on the same safety level of Rust. I see Rust as a huge waste of everybody's time and resources and far too opinionated in many regards.
Either way, x86_64 assembly code is a high level language that gets interpreted by the CPU at runtime, so not sure how relevant it is to anything low level anymore.
Not a perfect test suite, but the one for my bc [1] is pretty good.
For instance, I worked in a company that rolled its own coroutines in a way very similar to how they work in Go on top of many other things they did to the language runtime. Valgrind couldn't "understand" what was happening in that runtime at all and if you tried to run it would spew millions of warnings (similar problem you'd have if you used Bohem GC with your C program).
There was a way to "teach" Valgrind to understand what was going on in that runtime, but and even though we tried, at some point we realized that it would take too much effort to do so.
I'd bet that OPs home-made alloca() would have a similar effect on Valgrind too.
I was only trying to defend the article author from the accusation of hubris. If all of these tools are indeed used until they show no errors at all, not even false positives (as the article claims), and if the test suite used to run them is non-trivial, then they are likely far more secure than a typical program written in Rust or even something like Go or C# or Java (which all allow and internally use raw pointer manipulation for things like interop).
Oh god yes. That should be tattooed on everyone who thinks otherwise. “Ha! Unlike all those other people, who are clearly not as attentive as myself, _I_ never make this type of mistake.”
> The final reason is the only one that justifies my decision: my code will be rewritten in a memory-safe language. [...] It’s my own language. It’s called Yao.
> This is the only reason I could justify that decision. All of the other reasons above are excuses. This is the real reason.
> You can bet that I do not want to accept liability for a project written in C. It will be rewritten as soon as possible.
I love the idea of Rust, but find the syntax to be just awful, and the entire thing just overly complex. I'm not saying that Rust isn't the way it is for good reasons, but the code is often hard to read. Some of the syntax choices are in my mind questionable and serves only to have Rust programmer appear smarter than the rest of us.
Rust shouldn't try to accommodate people like me, because it will make everything worse for everyone. Instead I should look elsewhere, may not to C, I'm not that clever, but to languages like Go, Nim, Crystal or Hare. It's important that we have choices, because even the best designed language, and I do consider Rust a well designed language, will fail to appeal to everyone.
Nobody SHOULD use Rust.
Some may use it, but nobody should.
And because of this "should" many will not use it, especially when you consider that the language is conceptually overweight and there was already one "very popular" conceptually overweight Scala language, which now only the old people remember (laughs).
Getting hung up about the choice a single word in a comment is a little weird and makes you appear rather annoying.
You can use search for the next criteria: why you should use rust
This informational noise is very disturbing and forms a somewhat distorted perception of reality, because it profanes the choice of a very complex instrument (which is just a small part of the huge instrumental set). And thanks to this noise, the obvious boundaries between the apparently different "must" and "can" are lost.
I only talk about this and nothing else.
Because very little of what people complain about is actually syntax and is actually semantics.
But closure syntax is awful
Overall, it feels like a nice combination of Pascal and Python. At least, reading Nim code is usually easier than Rust.
On the other side, I'm still interesting in learning Rust. There are some open source OS kernel projects written in it.
To be clear, I don't mean to disparage the author's decision. Programming can be an artistic endeavour, where personal enjoyment trumps most concerns. If programming C is what keeps you motivated, go ahead and use it! Just be aware that this may make your software risky to use and rejected in many real-world situations.
If that was remotely true how do you explain the Actix episode?
Except that this was not a Reddit problem, was it? This was a problem created by the Rust community that showcases exactly the "Rust Evangelism Strike Force" behavior we're talking here.
Would it made it a Mastodon problem if the Rust fundamentalists opted to use that to drive their relentless attacks? It wouldn't, would it?
I mean, it surely wasn't a GitHub problem when these Rust evangelists started harassing the maintainer through bug reports, which was the place where it all actually took place.
People threw a fit, and it got patched.
Then afterwards it seems maintainer didn't accept any (unsafe?) patches and was harrassed by Rust Reddit community to the point of leaving.
By "people threw a fit" you mean the Rust community put up a relentless harrasment campaign targeting the project author, even to the point where they involved their employer, and ultimately forced the maintainer to give up on FLOSS and abandoned the project altogether.
I mean I saw it on Reddit, guy got panned for abusing unsafe and bunch of unsafe were patched out. That's it as far as what I am aware of.
> Rust community put up a relentless harrasment campaign targeting
Don't judge community (especially one you don't know) by their worst member.
Rust community didn't all agree and made a pact to harass/dox that guy. Few assholes did.
Trying to generalize this behavior to entirety of Rust community is disingenuous. Imagine if I started saying all programmers were wife killers, because some programmers killed their wifes.
The community was massively represented in that harassment campaign targeting Actix. We can still read the threads and the bug reports that fueled that shit show. Things got so bad that distinguished members of Rust's core team felt compelled to put on their PR hat to work on salvaging Rust's reputation and do limitation.
It was not bad apples. It was a hallmark of Rust's community.
Also, sure Rust people care overwhelmingly about Rust crates.
Any large enough community will statistically have some percent of "bad apples". You're arguing as if those bad apples are a majority. And not a statistical footnote.
You mentioned Reddit. Rust's subreddit had at the time over 80k subscribers. The subreddit massively piled on the maintainer of Actix. This harassment campaign was so massive that core Rust members felt obligated to write public declarations how Rust should invest in community building and, with the Actix case as an example, whether they could actually reject contempt culture.
It was not an isolated bad apple. Rust's community is renowned for being toxic, hostile and abbrasive. This topic is underlined time and again even in HN. It's not possible to hide this fact.
First. Rust community != Rust Reddit community.
Second. You haven't made an argument, why should we judge 30k or 80k people on basis of how many harrassers?
Third. What other incidents were comparable?
Fourth. Rust community can be toxic but so can HN. HN has a huge Rust hate boner. Any Rust thread on HN will have people repeating tired Rust tropes.
The Rust community just picked it up. as self-deprecating humor.
This. So much this.
Moreover, Rust is extremely complex, similar or worse than C++. A programmer has to learn a lot of alien concepts that they don't need when using Java, Go, or similar safe languages.
And unless you are writing a few specific types of code, using unsafe usually isn't ever necessary at all.
The complexity is also very much not an issue in practice. If you rub up against complexity in C++, you might not even know it. UB could be silently ruining things. If you rub up against complexity in rust, you were either just saved from yourself, or you are hitting part of the language that is probably undergoing improvement. But you never have to worry about complexity silently making things worse.
In practice, people find otherwise. It takes a steep learning curve to use Rust compared to Java, for example.
In fact, many people still avoid C++ and use C exactly for this same issue, C++ is too complex to use. These people who use C will justifiably have the same argument against Rust, it is too complex, and migrate when needed to something else like Go.
But the way I think the higher complexity of rust over c is also not a big deal in practice, for much the same reason as I gave for rust vs c++. But that is also irrelevant here.