Hemospectrum

There's profitability for the business, and then there's profitability for the shareholders. The latter is the bigger problem because it compels all businesses to become increasingly profitable at monotonically increasing speeds. If only we strangled all the profitability out of the stock market (with some really draconian taxes and regulations) we could rein in capitalism and have a more sustainable economy. But that's a pipe dream.

Heads up: As your link explains, "wet bulb temperature" refers to the method by which the heat is measured, not to the threshold where it becomes intolerable for humans. That threshold is around 90F at 100% humidity, but the actual weather conditions can yield a wet bulb temperature much higher or lower than that.

If this change makes moderation more difficult, it negatively impacts all users of the site.

Suppose you could have memory safety in C by implementing a borrow checker for every individual function. It would be suitable for certain industries, but breathtakingly expensive, error-prone, and therefore useless for most kinds of software.

That's roughly the situation today with SPARK. Using Ada does not automatically buy you memory safety on the same level as Rust. You can get a lot further with SPARK, but the annotations are very cumbersome to write.

These are well-known problems in the Ada community. There are efforts underway to improve SPARK's ergonomics by adapting ideas from Rust, with the help of the Rust Foundation. Someday soon, Ada will be much closer to Rust's sweet spot on the safety/productivity graph. In the meantime, there are CVEs to patch.

Your phrasing suggests that this trend is wasteful and will not result in a net improvement in software security overall. The numbers suggest otherwise. Memory corruption exploits currently occur twice as often as all other classes of exploits combined, and disproportionately account for the most severe exploits in the relevant studies. Automating them out of existence means being able to spend more time and attention on everything else.

Well, of course it won't, but it doesn't need to. It also doesn't need to replace Rust. We can all benefit from finding new and improved compromises between ergonomics and safety requirements.

As strange as it might sound, the success of Rust seems to have reopened some doors for Ada. People in both communities are aware of this and already collaborating on various projects to mutual benefit.

Maybe if you're headed for the center of the galaxy...

Memory leaks are bad, but they can't break type safety. Buffer overflows and use-after-free are categorically more dangerous.

> It's not a blaming game. Code written in C has issues because C has issues, but are you then saying that Rust has no issues? Will never have any issues? What's the bar here?

For a given value of "issues," that's an accurate portrayal. Statically verified memory safety at the language level is a central part of Rust's mission statement. This is an essential difference from C in how it approaches that problem space. Rust might "have issues" in the sense that compiler bugs are exposed by particular edge cases, or that dealing with certain problems is needlessly difficult or verbose, but reducing everything to "issues" to portray it as equivalent to C is absurd. You might as well say they both have "syntax" and conclude that all code written in Rust is still written in C.

That’s not correct. Memory safety consists of properties necessary for type safety to be upheld. Leaks alone can crash a program but can’t defeat type safety.

I like to put it this way: C++ was supposed to be a "better C," and Rust is a better "better C" than C++.

The problem isn't novices stubbing their toes in their own homes. The problem is professional programmers beneath your skill level who are making those same old mistakes in government offices and major corporations.

> it's the only one that never fights me on what I want to do

This is the #1 thing I've learned not to like about it.

The problem is simple. How can I trust that code written by other programmers is up to my standards? If the language obediently does anything they want, how am I supposed to judge its quality? Do I have to review every line of code in every piece of software running on every piece of hardware I interact with? Do I have to go around building a complete and accurate mental model of literally any program I plan to use?

I don't have time for that. Nobody does. It doesn't scale.

When other people write software, I want a vigilant, tireless critic to watch them write code and stop them from doing things that are unambiguously stupid. That's the only way to deal with the vast number of programmers with skill levels beneath mine, writing code that threatens to affect my life. If they can't do that with C, I want them to do it with something else.

1. Doesn't the D compiler contain an entire C compiler? Half the point of that section was to say that any C parser is halfway to being a fully functional compiler. That's arguably an exaggeration, but I fail to see how D serves as a counterexample.

2. How does the D compiler handle GCC- and Clang-specific extensions to C?

I don’t see hate here. Just disappointment, from programmers who used to like C and feel like it has let us all down.

> That said, does anyone know if Rust is actually used in any modern embedded devices?

The official Rust website has a page[0] with some quotes from companies using it in sensors and some other things.

Naturally, most companies won't be too outspoken about how they write their proprietary software.

[0]: https://www.rust-lang.org/what/embedded

> Right off the bat

This might not be a deliberate reference to Nagel (as mentioned in the article) but at least it's thematically appropriate.

> Well, that wasn't part of the conversation until now.

Sure it was. You kept saying "this isn't a solution." All I did was point out the converse.

I experienced the kind of "modern" CS education that you consider a failure, and believe it or not, I have about as much scorn for it as you do. I did get some good exposure to serious analysis and low-level programming, but the other half of what I learned was pretty much a waste and I had to unlearn it the hard way after leaving school. So, I'm not here to defend the Java idiom of mile-high towers of superclasses, runtime polymorphism that nobody will ever need, or wild pointer goose chases that accomplish nothing but stalling the pipeline. All that stuff is a waste of everyone's time. I like my compiled code to stay lightweight and close to the metal.

I am here to defend expressive type systems that permit detailed annotations of what should or shouldn't be done with a particular piece of data. I shouldn't have to rely on comments alone to say "the pointer returned by this function must be freed by the caller" or "the pointer returned by this function must NEVER be freed by the caller." I want the compiler to understand me when I say these things, and I want it to enforce my rules.

C doesn't have that, obviously, but I'm sure you already know that it was a huge change from its immediate predecessors, which didn't have types. Even early C didn't have structs. It added these features because they made programming less error-prone. Nobody wanted to manually calculate field offsets and risk getting it wrong.

That was 50 years ago. There have been missteps since then (I think every PL theorist counts OOP among these) but that doesn't mean C has to be the absolute last systems language ever in the history of computing.

> Bad code is the result of bad programming, not a consequence of the chosen language.

You've repeated this many times now. What I haven't seen you talk about is how to fix all this programmer badness. Do you think bad programmers should all be fired and blacklisted from the whole industry? Who will replace them? How do we make sure their replacements aren't just as bad as the ones who were fired? How do we even identify the bad ones before they write bad code? What if they want to become better programmers instead of getting fired? How do they figure out whether they're sufficiently good?

The value proposition of a new language is not measured strictly by how fast it lets you write new code. It also needs to be a medium for communication between programmers. Communicating the intent behind your code helps identify the ways it could be improved. If your intent can be codified in a way that even the computer can understand, that process speeds up dramatically.

Proponents of new languages are winning the debate over how to fix systemic problems in the software industry. The reason they are winning is because their opponents in this debate do not have a coherent solution. If you can suggest one, maybe you'll change everything.

> I remember a project a long time ago that used Objective-C to implemente a genetic solver. It was unusable due to just how slow it was. I re-coded it in C.

Quick question. Why would you do such a thing? How can you square this with your claim that switching languages is never the answer?

I agree with you that a good development process is essential. The thing is, some languages make for a worse development process, because they inhibit automation of important steps in code review. I expect you wouldn't trust the weaker type systems of Forth or BLISS, or the unstructured control flow of COBOL, for a job where you could use C instead. If there are analysis phases that C can automate and these other languages can't, isn't it obvious (given only a moment's thought) that there could be other languages that improve on C?

Systems-level programming is a frontier for language design precisely because higher-level domains are already so well-served by established platforms. If your problem can be solved in Python or JavaScript, you're potentially creating a lot of work for yourself by using a language that's sort of like either of these, but not actually compatible with their libraries. The internet is littered with upstart languages that were made this way and withered on the vine. On the other hand, if you're working in a problem space with tighter performance constraints, and you already can't touch these languages, and you can't even count on libraries written in C or C++, then you suddenly, paradoxically, have a lot more options.

Systems communicate via components. They can create empty "marker" components (and remove them again as needed) or, when applicable, put data in shared singleton data structures called "resources."

Part of the reason for the confusion is that this is a retcon of sorts. ECS was first described (with a different name) in a postmortem of Dungeon Siege, but as far as I'm aware, the modern usage of "system" was coined by Adam Martin during the development of Operation Flashpoint: Dragon Rising.

There are good technical arguments for making systems into first-class values, of course, but this interpretation will always be in competition with the older one.

I wonder if they can be trademarked. If not now, maybe later.

The pressure to grow stems from the massive amount of wealth that can be harvested from growth. The only way to curtail that is with economic policies that punish investors for getting too rich too quick, but almost all such proposals are instantly dead in the water as soon as anybody speaks their names.

> It was basically a lisp syntax for C

It was more like a proto-Rust. The Lisp-like syntax was a placeholder while the developers (plural) tried to solve language problems on a semantic level. Memory safety was their white whale. They never came up with a solution for that. The original author left because he had given up.

There's one other problem with Arthurian legend, and it's a doozy. Arthur's alleged subjects were the Celtic peoples who lived in Britain before the invasion of the Anglo-Saxon tribes speaking proto-English. If you use this as the origin story of England, you're making English people the bad guys. Tolkien must have realized this.

GGP contains a quote from the article explaining why. To summarize, honeybees compete with wild bees for food, and can spread illnesses that they can’t defend against.

CLAP does not need to supplant all other plugin formats to succeed. Its real goal (arguably more ambitious) is to expand the set of features in the "least common denominator" of plugin formats. To do that, it only needs to win a race with one other format, which, as it happens, is officially already dead.

Plugin developers don't just pursue the largest revenue streams. They also try to take the lowest-effort paths to those markets. CLAP is carefully designed to be a low-effort path for porting old plugins to an SDK compatible with modern feature sets, which can then be automatically wrapped in comparable formats such as VST3. There are other such SDKs, such as JUCE, but they almost all require a much larger investment of effort to work with old codebases. The fact that CLAP also specifies a well-defined plugin format further enables developers to write automatic test suites, or adapt such test suites that were originally designed for other formats. In a certain subset of the market, CLAP has already been adopted for these reasons, and as far as its creators are concerned, it has therefore already accomplished its goals.

As you suggest, there is a certain possibility that Apple or Steinberg would somehow prohibit the use of third-party SDKs in plugin development, but in reality this would be an absurd thing to try. It would accomplish nothing, alienate the entire market, and promptly result in a flurry of lawsuits and perhaps even an antitrust investigation.