The tool has a great potential, but I always found it too limited, fiddly, or imprecise when I needed to optimize some code.
It only supports consecutive instructions in the innermost loops. It can't include nor even ignore any setup/teardown cost. This means I can't feed any function as-is (even a tiny one). I need to manually cut out the loop body.
It doesn't support branches at all. I know it's a very hard problem, but that's the problem I have. Quite often I'd like to compare branchless vs branchy versions of an algorithm. I have to manually remove branches that I think are predictable and hope that doesn't alter the analysis.
It's not designed to compare between different versions of code, so I need to manually rescale the metrics to compare them (different versions of the loop can be unrolled different number of times, or process different amount of elements per iteration, etc.).
Overall that's laborious, and doesn't work well when I want to tweak the high-level C or Rust code to get the best-optimizing version.
Apple has reverted to being a regular company. Everything is a potential revenue stream, and decisions are made based on next-quarter ROI. They needed the movie investment to meet the targets, so they've synergized with the Wallet team.
I wish the fact that every company enshittifies in the end would wake us all up to the fact that rampant unregulated capitalism just doesn't work before it's too late to make any changes at all.
Half the news stories about Apple, Google, etc are them being fined or being forced to change their business practices due to regulations. These companies employ hundreds if not thousands of people to make sure they are following thousands and thousands of regulations.
I was snarkily echoing my parent comment’s criticism (sorry!). Of course there’s lots of regulation especially once these companies grow large. My point is it’s capitalism that grew them from $0 to $3T, and it’s capitalism that’ll take them back down to $0 and recycle those assets into newer, innovative companies.
What capitalistic mechanism allows a garage startup to compete with a company worth $3,000,000,000,000 ?
Surely you've seen this in Silicon Valley: the infamous way Google (or whoever) kills your startup by releasing your product for free, waiting for you to die, and then killing the product, just to ensure there's no competition in a field they may want to one day enter.
Or they just buy you. Great for the founder! Terrible for the consumer.
There's no need for me to prove that this can happen because, as I pointed out, it already has happened many times, from Xerox to HP to Dell to IBM. It's happening right now at Oracle. You can see the very earliest stages at Apple and Google.
Apple and Google control the internet, through controlling web search and browsing. One pays the other to ensure this monopoly. And none of the companies you mentioned were worth 3 trillion, and last I checked they all continue to exist and hold reasonable market share, and none of them taking market share from another is a case of a garage startup knocking off a monopolist.
The modern tech company is more akin to Standard Oil, but possibly even more powerful and all encompassing considering Google for example can determine what is true and false for a given population. Standard Oil was only able to be toppled by a State.
So again, what capitalist mechanism exists to allow a garage startup to knock over apple or Google? I completely agree with you that Google is enshittifying - my disagreement is that anything will happen about that unless a State intervenes.
A better system would be one where you never need to rely on one of only a handful corporations to talk to your friends. The way to achieve this is regulations that require interoperability - then companies have to compete on service rather than coasting on their locked in user base.
The minimum amount needed to ensure the basic spirit of the law actually happens.
The less regulation and tax you have, the quicker the wheel of innovation above turns.
OTOH, there are some cheap and easy regulations with a large societal return, like pollution regs. These low-hanging fruit should be picked, as long as the fruit-pickers don’t redirect the whole economy towards ever-taller fruit-picking ladders.
Apple hasn't existed in a time with "rampant unregulated capitalism", whatever that term is supposed to mean. You can argue there weren't enough regulations, but there were massive volumes of business rules regulations in 1976.
It existed today, so, yes it has. Capitalism describes the global mode of production, not just the United States economy. We haven't already forgotten the anti-suicide nets at Foxconn, have we? Without the margins that cheap foreign labor provides, the insanely high growth target required to please investors in a Capitalist economy can't be achieved.
I think we're fixating too much on purity of the word "unregulated." If you'd like to offer a different one I'm open to it - to me, the closest example of "regulated capitalism" is the PRC's State Capitalism, however it's a poor example given the atrocious working conditions there and the massive wealth inequality.
"Unregulated" to me doesn't mean "literally no regulations." To me it means, the owners of Capital have a very large amount of power, to the point that every regulation on them is an uphill, nigh-unwinnable battle. See: pushes for 30 hour work weeks in Europe. Or, see: pushes for socialized healthcare in the USA. I think we can both agree that the USA will never have socialized healthcare so long as the health insurance companies wield so much power and influence!
Apple's primary value driver (when it mattered) was luxury margins on mediocre tech. Without rampant demand, you don't have market stratification. If substantial regulation like the DSA existed in 2014, Apple's business model would look radically different today.
Because Apple under Steve Jobs worked because Steve had full control. Zero chance they become successful run by committee or group ownership or whatever. And they also needed venture capital in the beginning afaik.
I don't think Apple could have existed as it did under Jobs in any other system.
This is a very sensible way to pick a technology for a government.
Having a cool proof of concept, with a bus factor of 1, and having a solution that countless government agencies can depend on for multi-million-dollar decades-long software projects are very different things.
They can't just depend out of the blue on you personally maintaining "Fil's Unbelievable Garbage Collector" for the lifetime of the government's projects. Maybe you believe they could, but it takes way more legwork to give such assurance to a government.
They list TRACTOR under projects they've already funded (and crucially, not among solutions they recommend yet). Apply for funding for Fil-C, and if it gets accepted, it'll probably get listed there too.
The TRACTOR approach also has higher tolerance to being an experimental project, because it's one-time conversion of C to Rust. It only needs to work once, not continuously for decades. The Rust-lang org is set up to offer serious long-term support, and is way past having a critical dependency on a single developer.
> This is a very sensible way to pick a technology for a government.
No, it's not, for the simple reason that the government has more than adequate resources to recreate a Fil-C-like with a team, or even just add people power to Fil-C.
The fact that it only took one dude working in his spare time 1.5 years to make C memory safe suggests that the whole narrative of the OP is wrong. The problem isn't that people aren't using memory safe languages. The problem is that nobody is funding just making C memory safe.
You've made a language that is at least 20-50% slower than C and has a garbage collector.
That's not what people use C for. You're presenting it as a memory-safe C, but you've got a more fine-grained ASAN. That's useful, but it's not blowing away the whole narrative.
For running unfixable legacy C code there are already lower-overhead solutions. They're not as precise, but that's either not necessary for safety (e.g. where there's a right sandbox boundary), or the performance is so critical that people accept incomplete hardening despite the risks.
For new development, where a slower GC language is suitable, there are plenty of languages to choose from that are more convenient and less crash-prone.
There's already CHERI that takes a similar approach to pointer tagging, but they're doing it in hardware, because they know that software emulation makes the solution unappealing.
> You've made a language that is at least 20-50% slower than C and has a garbage collector.
That's not what people use C for.
Says who?
Most software written in C is not perf sensitive. My shell could be 4x slower and I wouldn’t care.
That’s also true for most of the GUI stuff I use, including the browser.
> you've got a more fine-grained ASAN.
The difference between Fil-C and asan is that Fil-C is memory safe while asan isn’t.
This has nothing to do with “fine grained”.
> it's not blowing away the whole narrative.
The narrative is that C is not a memory safe language. That narrative is false.
If the narrative was, “C is only memory safe if you’re willing to pay perf cost” then like whatever. But that’s not what folks are saying
> For running unfixable legacy C code there are already lower-overhead solutions. They're not as precise, but that's either not necessary for safety (e.g. where there's a right sandbox boundary), or the performance is so critical that people accept incomplete hardening despite the risks.
No there aren’t. Fil-C is the only memory safe solution for C code.
Hwasan, mte, etc aren’t memory safe. Asan isn’t memory safe (and probably also isn’t cheaper). Don’t know what else you’re thinking of.
> There's already CHERI that takes a similar approach to pointer tagging
Neither Cheri nor Fil-C use pointer tagging. Both use pointer capabilities. Fil-C’s capabilities are safer (they actually protect use after free).
Fil-C is faster than Cheri because I can run Fil-C on fast commodity hardware. Fil-C in my x86 box is orders of magnitude faster than the fastest Cheri machine ever
Hmm, I take it that the situation is that there are a number of vendors/providers/distros/repos who could be distributing your memory-safe builds, but are currently still distributing unsafe builds?
I wonder if an organization like the Tor project [1] would be more motivated to "officially" distribute a Fil-C build, being that security is the whole point of their product. (I'm talking just their "onion router" [2], not (necessarily) the whole browser.)
I could imagine that once some organizations start officially shipping Fil-C builds, adoption might accelerate.
Also, have you talked to the Ladybird browser people? They seemed to be taking an interested in Fil-C.
Tor wants to move to Rust, and they aren't happy with their C codebase. They want to expand use of multi-threading, and C has been too fragile for that.
Makes sense. But maybe the fact that that post is 4 years old serves to bolster the argument for Fil-C's value proposition. However much people may want to move away from their C code bases, the resources it takes to do so in a timely manner are often not so readily available.
Stack-allocated objects are used very often in Rust, and they're not limited to a strict LIFO usage.
Rust doesn't have C++'s RAII with destructors running unconditionally at the end of scope. In Rust, destructors run only once after the last use of a value, even if the value moves between scopes.
In the article's terms, Rust uses stack allocation wherever possible, but can also pass objects by value to make the complex non-LIFO uses possible (which is easier in Rust, because it doesn't identify objects by their address, doesn't need a pointer indirection to ensure uniqueness, and lifetimes ensure there are no dangling pointers to the old address).
Thread-local arenas are possible, and Rust can enforce that the objects never leave the thread (!Send types).
It's also possible to create memory arenas in any scope and use lifetimes to ensure that their objects can't leave the scope.
However, placing objects with destructors in arenas is tricky. Since the whole point is to let objects easily reference each other, there's nothing stopping them from trying to access the other objects in the same arena while the arena is being destroyed and runs the destructors. That's an inherent issue with arenas, in C too if the arena supports some kind of per-object cleanup.
I like your response the most among your siblings.
A couple more points, based on how the bumpalo crate does it:
- If you don't really need destructors, then it's fine to just not call them. This works for things like strings, lists of strings, objects with references to each other, etc.
- If you do need a destructor, you can create a stack object that references and allocates into the arena, and it will be the stack object whose purpose is to run that destructor (but deallocation happens later). This preserves drop ordering while still getting some benefit of arena allocation.
This makes the language more uniform. Instead of having a special ternary ?: operator for if-else in expression position, you have one syntax everywhere.
It makes generic code work without need to add exceptions for "syntactic elements". You can have methods like `map(callback)` that take a generic `fn() -> T` and pass through `T`. This can work uniformly for functions that do return values as well as for functions that just have `return;`. Having nothingness as a real type makes it just work using one set of rules for types, rather than having rules for real types plus exceptions for "syntactic elements".
What's the threat model? If you're reviewing untrusted or security-critical code and it's incomprehensible, for any reason, then it's a reject.
Syntax alone can't stop sufficiently determined fools. Lisp has famously simple syntax, but can easily be written in an incomprehensible way. Assembly languages have very restrictive syntax, but that doesn't make them easy to comprehend.
Rust already has a pretty strong type system and tons of lints that stop more bad programs than many other languages.
Many modern language designers focus on shaping expressibility rather than providing the maximum possible flexibility because their designers learned from C, Lisp and other languages that made mistakes. Examples lamguages are Java, C#, D, Go... some arguably with more success than others. But language design that gave ultimate expressive power to the the programmer is a relic of the past.
"Expressibility" and "expressive power" are vague and subjective, so it's not clear what you mean.
I suppose you object to orthogonality in the syntax? Golang and Java definitely lack it.
But you also mention C in the context of "maximum possible flexibility"? There's barely any in there. I can only agree it has mistakes for others to learn from.
There's hardly any commonality between the languages you list. C# keeps adding clever syntax sugar, while Go officially gave up on removing its noisiest boilerplate.
D has fun stuff like UFCS, template metaprogramming, string mixins, lambdas — enough to create "incomprehensible" code if you wanted to.
You're talking about modern languages vs relics of the past, but all the languages you mention are older than Rust.
Have you ever seen submissions to IOCCC or Underhanded C Code Contest? That is what too much syntactic flexibility looks like (if taken to the extreme).
If you want your code to be secure, you need it to be correct. And in order for it to be correct, it needs to be comprehensible first. And that requires syntax and semantics devoid of weird surprises.
Eh, I'm not sure I agree here. This feels sort of along the lines of, "well C is safe because someone can review your code and reject it if you try to dereference a possibly-NULL pointer".
The point of a language that is "safe" along some axes is that it makes those unsafe things impossible to represent, either by omitting an unsafe feature entirely, or making it a compile-time error to do unsafe/unsound things.
I will admit that this is something of a grey area, since we're talking about logic errors here and not (for example) memory-safety bugs. It's a bit muddier.
In general, though, I do agree that people should write code that is reasonable to read, and if a reviewer thinks some code in a PR is incomprehensible, they should reject it.
I think these situations are very different, because Weird Rust affects only weird code, while unsafety of C affects regular C code.
The difficulty in reviewing pointer dereferences is in reasoning about potential program's states and necessary preconditions, which C won't do for you. You can have neatly written C using very simple syntax, and still have no idea if it's safe or not. Solving that lack of clarity requires much than syntax-level changes.
OTOH the Weird Rust examples are not a problem you get in your own code. It's a local syntax problem, and it doesn't require complex whole-program reasoning. The stakes are also lower, because you still have the same safety checks, type checks, automatic memory management, immutability. The compiler aggressively warns about unreachable code and unused/unread variables, so it's not easy to write undetected Weird code.
Rust tried having Underhanded Code Contest, but it has been very Underwhelming.
The problem has been created by Docker which destroys all of the state. If this was C, you'd also end up losing all of the object files and rebuilding them every time.
Zope was cool in that you couldn't generate ill-formed markup, and optionally wrapping something in `<a>` didn't need repeating the same condition for `</a>`.
However, it was much simpler imperative language with some macros.
XSLT is more like a set of queries competing to run against a document, and it's easy to make something incomprehensibly complex if you're not careful.
In APNG it's either the same 256 colors for the whole animation, or you have to use 24-bit color. That makes the pixel data 3 times larger, which makes zlib's compression window effectively 3 times smaller, hurting compression.
OTOH GIF can add 256 new colors with each frame, so it can exceed 256 colors without the cost of switching all the way to 16.7 million colors.
It's absolutely possible. Browsers even routinely pause playback when images aren't visible on screen.
They just don't have a proper UI and JS APIs exposed, and there's nothing stopping them from adding that.
IMO browsers are just stuck with tech debt, and maintainin a no-longer-relevant distinction between "animations" and "videos". Every supported codec should work wherever GIF/APNG work and vice versa.
It's not even a performance or complexity issue, e.g. browsers support AVIF "animations" as images, even though they're literally fully-featured AV1 videos, only wrapped in a "pretend I'm an image" metadata.
I wish browsers still paused all animations when the user hits the Esc key. It's hard to read when there are distracting animations all over most pages.
It only supports consecutive instructions in the innermost loops. It can't include nor even ignore any setup/teardown cost. This means I can't feed any function as-is (even a tiny one). I need to manually cut out the loop body.
It doesn't support branches at all. I know it's a very hard problem, but that's the problem I have. Quite often I'd like to compare branchless vs branchy versions of an algorithm. I have to manually remove branches that I think are predictable and hope that doesn't alter the analysis.
It's not designed to compare between different versions of code, so I need to manually rescale the metrics to compare them (different versions of the loop can be unrolled different number of times, or process different amount of elements per iteration, etc.).
Overall that's laborious, and doesn't work well when I want to tweak the high-level C or Rust code to get the best-optimizing version.
reply