Hemospectrum

Memory safety is not about memory leaks. It's concerned with the corruption of data structures, particularly the stack and the heap.

To elaborate a little, consider security. If your software's only vulnerability is potential memory leaks, an attacker can only get away with denial-of-service attacks. If your software is vulnerable to buffer overflows, an attacker can use return-oriented programming to get arbitrary code execution, exfiltrate all your data, and add your machine to a botnet to perform subsequent attacks on yet other systems.

> The author writes as if part of his drive was that Linus himself showed enthusiasm for getting Linux on Apple Silicon.

Perhaps the author jumped to conclusions after Linus himself started using Asahi Linux on his own laptop for Linux kernel development[0]. Note the praise for the Asahi team in the commit message.

[0]: https://news.ycombinator.com/item?id=32311150

The complexity of natural human languages comes in different forms, but as a general rule, whenever you see something that's built into another language and "missing" from your own, you can express it by using more words. For example, PIE had a lot of noun cases that aren't in English, but you don't need the instrumental case to precisely express its purpose. You can say something like "by means of a forklift."

Some studies actually suggest that literacy systematically pressures languages to use longer, more complex sentences, thus disincentivizing complex inflection rules.

Similarities like these, especially with Latin in the mix, were the clue that originally put early linguists on the scent of the IE language family several centuries ago. Since then, extensive research has been done into how exactly these languages developed from their common ancestors. Some modern dictionaries, like Wiktionary, contain entire family trees comparing the divergent development of these cognates and many, many others.

You're most likely to hear it from kernel programmers and Go/Zig/Odin advocates, but it rarely comes up as a criticism of C++ in particular. Perhaps that's because RAII is merely "distasteful" in that cohort, whereas there are many other qualities of C++ that might be considered total showstoppers for adoption before matters of taste are ever on the table.

There was an HN thread a few months ago[0] debating whether RAII is reason enough to disqualify Rust as a systems language, with some strong opinions in both directions.

[0]: https://news.ycombinator.com/item?id=42291417

> ...and the packager eventually dropped the package

Related HN discussion from August/September: https://news.ycombinator.com/item?id=41407768

Some of them have software controls for hardware behavior (like optical sensor polling rate and scroll wheel clutch mode) that no OS has built-in support for, because these features are not part of the USB HID standard.

Health insurance price negotiation is the primary reason those prices are so high in the first place. An insurance company gets to say it negotiated a 99% discount (or whatever) and the hospitals and pharmaceutical companies still charge prices high enough to turn a comfortable profit.

It's a lot like "Black Friday" sales where retailers jack up their shelf prices in the preceding days and weeks so they can mark them down and persuade the customers they're getting attractive deals.

The documentation is quite clear on this point:

> The returned iterator will panic during iteration if any argument to the process is not valid Unicode. If this is not desired, use the args_os function instead.

std::env::args_os encodes paths as an OsString, which is allowed to contain invalid Unicode. You can then perform your own Unicode validation as needed, instead of the "ASAP" behavior of std::env::args.

https://doc.rust-lang.org/std/env/fn.args.html

Compile times are Rust's single biggest weakness. A lot of work is going into speeding up the compiler, but right now, the biggest wins in compile time reduction come from reorganizing your own code and eliminating overly generic dependencies, particularly those that introduce loads of transitive dependencies for building procedural macros. Clap and Serde are major offenders here. For many projects, eliminating such dependencies can speed up build times by a factor of 10 (and similarly reduce disk usage). Depending on your circumstances, it can be worth the effort.

Zig is safer than C, which is not a high bar to clear. It has safer defaults than C, and makes it a little easier to use test-driven debugging to find memory safety violations, but it has no answer to Rust’s Send and Sync traits or the mutable XOR aliasable reference model. In that sense it’s similar to dozens of other languages older than Rust.

The cute name was Blue Friday, but it doesn't seem to have caught on.

The parent comment was referring to programs running inside the UXN virtual machine, which explicitly supports and endorses self-modifying code. Many of the creators' own programs take advantage of this capability, so any conforming implementation has to find a way to make it work.

> we've known about galaxies outside our own (like the Magellanic clouds or the Andromeda galaxy) for a few millenia

Well, we could see them, but we weren't able to distinguish a galaxy from a nebula until after investing multiple centuries into the development of powerful telescopes.

> Does Rust fundamentally guarantee that if you make a struct, its fields will lay out in memory in the order that you defined them? Can it be used to interact with APIs (really ABIs) who expect a C struct (or pointer to one)?

You have to specify this behavior with #[repr(C)]. Otherwise, the compiler will rearrange fields to try to optimize packing and alignment.

> I always say that purely in terms of design my ideal language is high-level Haskell, low-level C.

That's similar to what I used to say. I was devastated to see the BitC project implode, but then Rust appeared and took up the mantle. It's not perfect by any means but it's influential enough to drag the whole field of PL development kicking and screaming in that general direction.

It's a regional thing. Common in Britain, but sounds strange to Americans, and looks even stranger in writing.

Not sure about other parts of the anglosphere.

I'm not convinced. The UI in early Blender was as arcane as any I have ever seen, worse than GIMP's by a mile. Contemporary commercial 3D software did not have the same quantity or quality of weirdness. (Remember SoftImage?) The commercial version of Blender failed in the marketplace, and after it was open sourced, it was not taken seriously again for quite a few years.

Blender's dogfooding efforts were a powerful force in both proving that the software was good enough (to make movies) and demonstrating how it could be better (for the animators who made the movies). I'm not aware of any such efforts for GIMP. What I have seen is roadmaps of what improvements they know they need, and timelines of years to improve core infrastructure to the point that their actual goals are within reach. Meanwhile, other software projects (both FLOSS and commercial) race past them and move on to more exotic and exciting features.

In the MSP430 family? Not likely.

Increasing profit margins is a reliable way to increase stock prices, which is (at this stage of capitalism) the most powerful force directing the allocation of capital. It's a self-reinforcing feedback loop with far-reaching power throughout the economy.

The truly enlightened are buying MacBooks (in gold, of course) if only to use them as frisbees.

In most English dialects, <foot> is pronounced /fʊt/, not /fut/.

I’m not aware of any specific examples where <foo> and <foot> have the same vowel.

> Half[1] of English is French, just like half[2] of Japanese is English/Portuguese.

Setting aside the difficulty of defending these breathtakingly inflated claims, your phrasing indicates the classic fallacy of defining a language just by its vocabulary. That possible were if, this sentence English in sense make would.

They're repurposing an existing telemetry system that already counts installs and cannot distinguish between a new install and a reinstall. They've been using it for at least five years.

I only know this because they specifically pointed it out when announcing the new pricing plan.

Install bombing is still a problem.

Unity, for all its "clarifications," keeps promising it won't be a problem and then refusing to be transparent about any of the ways it could possibly be less of a problem.

Either they backtrack on this whole lifetime install count scheme or this blows up even more spectacularly when January rolls around.

> The blog sets up to address the "claim by proponents of dynamically typed programming languages" that "once you have unit testing static type checking is redundant". This is a strawman and I'm fairly sure it was a strawman in 2012 as well.

In the past year I've seen at least half a dozen posts here on HN making this exact claim. Now I kind of wish I'd saved a few.

This is about the API, which is no longer free. They are specifically blocking NSFW content from the paid API (and, by extension, from anything that uses it) so that they can charge money for it.

It's the credit card companies.

Showing users nudity for free is fine. Making them pay for it means you're selling porn and the payment processors ban you.

Reddit wants to make users pay for viewing content. They can't get away with that if the content is NSFW.

How far are you prepared to take this stance, exactly? C has operators that are generic over both integral and floating point types. Was that a mistake? Did OCaml do it better?

For my part, I've been persuaded that generic operators like that are a net win for math-heavy code, especially vector and matrix math. Sure, C++ goes too far, but there are middle grounds that don't.

Carbon is sort of a plan B, for working on existing C++ code that would be too difficult to migrate to Rust. It also doesn't really exist yet.