But there is also not a lot of money to be made on supercars. A lot of those manufacturers are struggling financially for a good reason. Extremely expensive to develop, hard to manufacture at scale and limited pool of buyers.
Rust is quite complicated but people like it a lot. Python too in a way - it's quite large and complicated but it exposes the complexity in a very gradual way and you can ignore so much of the language and still get things done.
I agree with you about simple languages though. I really like Go - the "there should be only one way to do things" from the Zen of Python actually applies to Go in a way that it doesn't apply to Python at all.
Languages like Go, is how you end up with what appears simple on the surface, while in reality is full of gotchas and boilerplate for what complex languages support out of the box.
That is how you get double nils, exception handling that pretends not to be one, url based imports that requires source code and rewrites when the host changes, generators by code patterns, generics that miss some language constructs,....
While this behavior can be counterintuitive, it's easy to understand once you have the right mental model of interface values. A nil interface is an empty interface. Once p is assigned to i, then i is no longer empty: it holds a nil pointer to an int. Whether the interface is empty or not is one question, answered by comparing it against nil. Whether the value the interface holds is a nil value is another question, answered by downcasting and then checking the resulting value.
I don't blame people for being confused by this the first time they encounter it. However, anyone who finds it persistently challenging to understand is not going to have much luck with the subtler language features of C++, Rust, Typescript, etc.
That seems like the reasoning that given the amount of UNIX and C code in the industry, memory corruption bugs only happen to those that don't understand their job.
Having gotchas is natural in language design, often times they only surface after field experience.
The problem with many Go's gotchas is the initial refusal to learn how other languages approached the same problems, the gotchas they got in the process, only to come up with some patch work afterwards, e.g. pseudo-exceptions with panic/defer/recover, rewriting import urls in go.mod,...
This is just how I've felt writing both Rust and C++. Rust's language complexity often feels like it's there so that I don't have to think about so much complexity when interfacing with the code, whereas C++'s language complexity introduces footgun after footgun and I have to think very carefully about what everything could possibly do (e.g. if destructors even get run in certain instances when I'd expect them to).
Lots of programmers match the right language to the right job, I think the zen of C++ is embracing the ugly as a feature; there are so many subsets of that language you never have to leave it.
> there are so many subsets of that language you never have to leave it.
I wouldn't call it "subsets" as much as support for "Multiple Paradigms" in the same language. They can all be used together to express powerful abstractions. James Coplien wrote "Multi-Paradigm Design for C++" in 1998 (before C++11!). Then people figured out Template metaprogramming etc. and the design space became even more wider.
Today with all the available language features and library additions you never have to leave the language at all whatever be the platform(cpu-arch+OS) you are working on. Add-in trivial interop with C and there is nothing out of bounds.
Exactly, you can code like C devs (Petzold used the C subset in his famous Win32 book), go to the extreme of GUI, ORMs, Web frameworks in 1990's, inspired from Smalltalk before Java and .NET took over that role, go crazy with Haskell style programming, or chose somewhere in between.
On the one hand, almost everyone (including C++ fans) agrees that the language is too big. On the other hand, comtracts just formalize an existing and useful concept.
I was thinking for implementing borrow-checker like rules for C but after I have seen what SMT solver can do I think it is not necessary to constrain the language in this way.
Yeah, the problem with the lifetimes profile vision, is the lack of acknowledgement of how MSVC and clang-tidy have struggled to achieve the Core Guidelines ideas for lifetimes (since 2015), without additional annotations.
MSVC requires SAL and clang has equally added extensions for type annotations.
The WG21 politics killed the Safe C++ proposal with the P3466 paper,
"(Re)affirm design principles for future C++ evolution"
> Do not add a feature that requires viral annotation
However it is quite clear, that without changing language semantics, for the lifetimes profile to be actually useful, as shown by MSVC and clang experience, we would need to have [[profile:lifetime(something)]] in plenty of places.
Not only would that be more verbose than what Rust and Safe C++ proposal, it would still require placing those annotations on the standard library (yet another complaint from the anti-Safe C++ proposal folks), and naturally violate the paper that was voted for as the design principles for future C++ evolution.
However in regards to how to check for C and C++ lifetime issues, at least if the source code is fully available, I have had some good experience with AI tools doing code review, like CoPilot on Visual Studio.
Maybe that is possible way forward, moreso if the code isn't being fully written by humans.
Regarding C specifically, what about having Frama-C's ACSL as some kind of ISO C annex?
Compilers would just ignore the annex and whoever wants to implement it, can already do this. And I also think ACSL is too complex for what is needed and also not well integrated with the rest of the language.
IIRC Rust's borrow checker analysis is more or less a subset of what SMT solving is capable of. It's "just" a question of tradeoffs made with respect to performance, complexity, precision, etc.
It is a really tiny and trivial subset of what model checkers can do. Model checkers can often prove memory safety of entirely unmodified C code. The problem is that this still runs into complexity problems and does not scale to non-toy programs. But this would also really be very far at the other end of the borrow checker that would require rewriting everything into a very specific form a borrow checker accepts.. IMHO a middle ground with some annotations is realistic and would be far more convenient than a borrow checker when supported by good tooling.
> The problem is that this still runs into complexity problems and does not scale to non-toy programs.
Right; that is why Rust's borrow checker was designed to be intraprocedural only. That obviously is a tradeoff of its own: now functions need to be annotated to convey information across function boundaries, and the annotations picked will influence what can and cannot be expressed.
> IMHO a middle ground with some annotations is realistic and would be far more convenient than a borrow checker when supported by good tooling.
I'd be interested in seeing what such a middle ground looks like, particularly in respect to what tradeoffs it makes!
I don't know yet. My current expectation from what I have seen is that lifetime analysis can be done fully automatic for most C code as long as it can be done independently from other program state, i.e. the checker has to reason only about the state of pointers and not also simultaneously about all other variables. I have seen quite promising work on this.
Thanks for the link! That's an interesting approach indeed. If I'm reading the paper [0] correctly the concepts involved look pretty similar to what Rust uses. I think they turn the interprocedural analysis into an intraprocedural one as well by effectively deriving borrowing information from function implementations and attaching that to signatures for use by callers. It's a compatibility hazard, which is why Rust chose to not do the same, but in principle it makes it easier to derive more precise borrowing information.
They globally derive the borrowing information for all pointers in the whole program by classifying the role of each pointer. If there is a way to do this in a way that makes the program safe, this is computed automatically using a SAT solver.
The paper explicitly says that if you use an LLM it is prompted function-by-function.
For the SAT solver I think classification can be done function-by-function if you manually drive the solver in the single-function mode, but I think you're more right in that the whole-program mode doesn't actually do that.
I think my misunderstanding stemmed from interpreting the start of section 5.4 and figure 3 as showing that constraint generation occurred strictly before the verifier was invoked and glossing over the bit at the start of section 6 that said that the process basically works the other way around when using the solver to build the p-model.
Possibly? Though given its outputs apparently aren't completely out there I'd hazard a guess that the inferred context usually shouldn't be too far off of what can be deduced using more traditional methods.
Your background is C as I understand it, and C does not really have issues with temporaries as they are known in C++ and Rust.
My understanding:
C compound literals have invariable and relatively long lifetimes, namely to the end of the local block, and to shorten those lifetimes, one has to put the expression with the compound literal in a new, smaller local block. The advantage of those long lifetimes is that lifetimes are typically long enough for it not to cause issues in C. C also does not have RAII.
Both C++ and Rust have varying lifetimes of temporaries and have RAII. Both C++ and Rust have had messes with lifetimes, C++23 changed lifetime rules for the range-initializer expression of range-based for-loops, and Rust changed lifetimes rules in Rust 2024 such that whether a specific piece of Rust code has a deadlock or not, depends on its edition, and editions are generally not specified per-file but per-project.
Temporary lifetime extension can be tricky for both developers and language designers.
But the borrow checker can make it worse in some situations, for it can push developers towards bug prone designs that have greater risks of deadlocks, just to satisfy the borrow checker. The borrow checker also mostly enabled the language designers to go wild with lifetimes, since they did not have to worry as much about UB as long as they were in the not-unsafe subset, so the issues with deadlocks might be worse in practice than if they had been more careful and restrained with lifetimes.
It can also be very subtle whether Rust code has deadlocks or not. One of these Rust programs has a deadlock, the other does not. The difference is the presence and absence of temporary lifetime extension, as per the "{}".
I guess this must be the fearless concurrency I am hearing about. /s
In general I understand why people like RAII and the idea of not worrying about pesky details such as resource cleanup is appealing, but the philosophy in C is that the compiler should not do such things behind your back and perhaps this is sometimes valuable. I like this more because things are explicit and visible and I rather want to have tools that tell me that what I do is correct rather than a language that does a lot of things implicitly behind my back (especially if this is correct 99% of times but sometimes surprisingly is not). This is why I am not a fan of C++ nor Rust. Thank you for the nice example illustrating issues in Rust arising from this.
I don't like the "fearless concurrency" motto, because it often gets discussed in isolation of all kinds of concurrency and ways to access resources in systems languages.
It suffices that the resource being accessed concurrently isn't inside in same memory space like shared memory, mapped regions, a database connection, where the Rust type system can do very little to prevent other processes, or conflicting SQL queries without proper transactions, to mess up with the data coherency.
But C++ "struct" has many more features than C "struct". Virtual functions aka compiler-generated invisible vtables, constructors (initialization functions) and destructors (automagically called deinitialization functions), the whole templates complex of features...
I view C++ (and increasingly C# and Java) as a test bed for language features. You throw every possible feature into it and people can then see what makes sense and what doesn't. That allows others to pick features and use them for more opinionated and simpler languages.
Why bother? Most systems these days have over commit and so you can never get an out of memory error. The OS will happily give you more and more RAM, and then when you try to use that memory kill a program (may or not be your program). The only out of memory error you can see is if you are trying to allocate more memory than the address space allows. This is so unlikely that nobody considers it worth bother to try to handle.
It is important to try, for a few reasons. Among other things, increasing amounts of Rust written in the Linux kernel itself, and other environments where you need to take more care with memory allocation.
Rust as a language is capable of that. If you don't use the standard library then you can provide that functionality yourself. The standard library is trying to support it, without creating interfaces that are a massive pain to use.
For instance, it's easy for us to support `Vec::try_reserve`, and we do, but that's not trivial for users to use everywhere; it's error-prone, and it's easy to make a mistake and call a method that goes past your reservation. It's painful for us and for users to make `Vec::push` support this (and having a `try_` variant for every function), so we've been working on a better solution. One current possibility is to have a dedicated type for a Vec that has OOM handling, where `push` can return an error, so you know if you use that type you can never accidentally fail to handle OOM.
Sure if you ignore the most popular desktop OS in the world.
Also overcommit (at least how Linux does it) is dumb. It leads to broken OOM behaviour (killing a totally random process, or more often locking up the system and hard rebooting). And some apps do need to handle OOM properly, e.g. formal verification systems which can use enormous amounts of memory. Jasper has to resort to monitoring page fault stats to know when it is using too much memory.
no it doesn't. the broken oom behavior is distros not configuring earlyoom/systemd-oom properly. The problem here is that the kernel doesn't know what software is critical to your OS so the distro needs to be responsible for what processes to protect.
For apps that need to handle oom, Linux is missing something a handle to tell apps to shrink their memory use. Apple does this and it seems to work quite well (and proves that Linux style overcommit works well since it's what they use)
the biggest design wart of rust (well one of them) is that support for custom allocators wasn't built into the type system from the start, with allocation osmething that returns Result
As much as I would love this on principle, I don't think Rust can make it ergonomic without huge changes like bolting on algebraic effects or something.
On a typical Linux box, overcommit and eager or confused OOM killer will ruin your day anyway.
For no_std style work where running out of memory is actually a hard limit, you have two choices:
1. disable the global allocator and use APIs that take Allocator, to force yourself to only consume APIs that can return errors from allocation. (The ergonomics aren't always great, and fattening all types with a pointer to Allocator isn't great; might be able to use a zero-sized Allocator, with trickery. Say goodbye to many libraries.)
2. use static analysis and try to avoid ever hitting a code path like Vec::with_capacity that doesn't return a Result. Make sure the tooling also analyses your dependencies. (Tooling for the static analysis is painful. And still, say goodbye to many libraries.)
I do wish there were more conveniences for alloc-can-fail APIs, like the failable version of Vec::push needs both try_reserve and push_within_capacity (nightly only).
That’s a ridiculously rude and inconsiderate prompt.
reply