441–450 of 1001 posts
Earlier quoted context omitted.
> It would make Macs more attractive as developer machines, and I don't see how it would disadvantage them. The only development they want is development inside XCode. Anything else is a hard no.
Are there a lot of dev tools that run on linux but not on Macs?
Earlier quoted context omitted.
Agreed, supporting apple devices is going to be a maintenance nightmare as it goes against the wishes of apple. At best, apple involuntarily makes reverse incompatible changes which breaks the drivers and at worst apple specifically sabotages the drivers to keep people in the walled garden. This may be controversial but you also don’t have a right to merge in code to the kernel. If the maintainers don’t want rust cod…
> Agreed, supporting apple devices is going to be a maintenance nightmare as it goes against the wishes of apple. At best, apple involuntarily makes reverse incompatible changes which breaks the drivers and at worst apple specifically sabotages the drivers to keep people in the walled garden. Apple explicitly chose to provide a way to boot third-party operating systems when designing how the M-series SoC boots. Their…
Two HUGE roadblocks were self-inflicted: adopting a hardware platform that doesn't care about external development (Apple silicon) and a programming language that has almost zero support in the Linux kernel (being the first ever to try to achieve multilanguage Linux kernel development). The odds were set against the Asahi Linux project from the beginning.
Apple makes great hardware (I have an M1 laptop I use away from home), but if I'm intending to run Linux as my primary OS, I'm buying from a company that is more open to it.
Earlier quoted context omitted.
What do you mean? Rust 1.0 can compile Rust 1.0. Rust 1.1 can compile Rust 1.1.
C99 isn't a compiler version. It's a standard. Many versions of GCC, Clang and other compilers can compile C99 code. If you update your compiler from gcc 14.1 to gcc 14.2, both versions can still compile standard code.
Earlier quoted context omitted.
If you watch that YouTube link, you'll see the same guy Ted Tso'o accusing the speaker of wanting to convert people to the "religion promulgated by Rust". I think he apologised for this flagrant comment, but this email shows he hasn't changed his behaviour in the slightest.
[flagged]
This is an unfortunate typo because your meaning is completely lost.
If your claim is that individuals are being hypocritical then you may have a point. Especially if you can produce examples.
But if you mean community vs community then you have simply bought in to the religious debate which isn’t interesting.
There's an awful lot of money and power associated with operating systems and programming languages (obviously), and the resulting "realpolitik" of situations like these seem to get swallowed up in these discussions.
It makes sense for technical people to think that the technical debate is what essentially matters, but it usually never actually is.
I've found the way Linux has approached Rust in the last couple of years to be a tad confusing. Always cutting a hard line, suddenly Torvalds' opinion is quite wishy washy. Oh, we'll try it, who knows, what's the worst that can happen, type thing? What induced this change, one wonders.
[0] Well-written blog posts on the subject are very welcome, please share if you know one!
Reading this I cannot help thinking about what Linus Torvalds said more than 20 years ago[1] in an interview. When asked if he feared competition for Linux his answer was that few liked writing device drivers and as long as no one "young and hungry" came along that could write device drivers and liked it he'd be safe. There you have him, Hector Martin, young[2] and hungry and loves writing drivers. No surprise he cla…
Earlier quoted context omitted.
I think we're mixing 2 things here: language backward-compatibility, vs. standard practices about what semver means for Rust libraries. The former is way stronger than the latter.
> language backward-compatibility, vs. standard practices about what semver means I've read and re-read this several times now and for the life of me I can't understand the hair you're trying to split here. The only reason to do semantic versioning is compatibility...
I'm not aware of semver breakage in the language.
Another important aspect is that Semver is a social contract, not a mechanical guarantee. The Semver spec dedicates a lot of place to clarify that it's about documented APIs and behaviors, not all visible behavior. Rust has a page where it documents its guarantees for libraries [0].