The interop is already great via PyO3, except when people want to build the Rust part from source, but are grumpy about having to install the Rust compiler.
This hack is a Rust compiler back-end. Backends get platform-specific instructions as an input, so non-trivial generated C code won't be portable. Users will need to either get pre-generated platform-specific source, or install the Rust compiler and this back-end to generate one themselves.
They are grumpy about having to install the Rust compiler for a good reason. You can’t compile for Rust on Windows without using MSVC via Visual Studio Build Tools, which has a restrictive license.
> When targeting the MSVC ABI, Rust additionally requires an installation of Visual Studio so rustc can use its linker and libraries.
> When targeting the GNU ABI, no additional software is strictly required for basic use. However, many library crates will not be able to compile until the full MSYS2 with MinGW has been installed.
...
> Since the MSVC ABI provides the best interoperation with other Windows software it is recommended for most purposes. The GNU toolchain is always available, even if you don’t use it by default.
USSR once fucked up its agriculture and purged biological research, because Stalin thought survival of the fittest didn't fit his political narrative, and banned genetics for being an imperial ideology:
Internally the compiler tracks what "niches" exist in types, like minimum and maximum valid values, and takes the unused values for enum tags.
One thing it can't use is padding in structs, because references to individual fields must remain valid, and they don't guarantee that padding will be preserved.
> We were pretty "soft" (dislike the term) on the land borders and on immigration
That's absolutely not the impression US gives to the people outside. The visa system is soft only on one specific demographic it deems worthy (educated, wealthy, commonwealth citizen), and treats everyone else with contempt at best.
Getting a visa requires extensive background checks, and an in-person interview in a part of a consulate built like a prison. The green card lottery keeps people on uncertain ground for decades, during which they are second-class citizens and can have their entire life uprooted at any moment.
Claiming asylum via safe modes of transport has been made technically impossible (anyone suspected of seeking asylum won't be sold any tickets, won't be let through any security), and deadly dangerous and intentionally cruel towards everyone desperate enough to try anyway.
Unfortunately, many countries are like that, and the USA is not better than average even on the good side.
How did you manage to somehow twist the green card lottery into something so harmful sounding? It undermines your other points.
Nobody is forcing people to join the lottery. Nobody is in “limbo” against their will. it’s something that has a huge upside if you win, and little downside (apart from the Application fees).
Which country doesn’t do some kind of background check or information gathering when letting you in (except for tourism of course).
It’s extremely onerous to get a tourist visa to the EU if you’re an Indian citizen for example. Or it used to be.
They want your bank balances to make sure you aren’t going to just get on welfare.
Markdown is semantically less expressive than man's markup. man goes into details like explicitly marking up command's arguments.
You can convert man to Markdown easily using full capabilities of Markdown, but Markdown lacks semantic information to be converted back to fully-features man document.
If we had good man viewers that have consistent level of support, then man would be a better data source format.
Unfortunately, there's no way to know what features man viewers support, and AFAIK no good ways to provide graceful fallbacks. This is most broken with tables and links that have dedicated markup, but are not rendered in common setups.
> Markdown lacks semantic information to be converted back to fully-features man document.
Core Markdown, yes. Pandoc has a fenced div extension that can capture the semantic meaning.
::: Warning :::
This is a warning.
::: Danger
This is a warning within a warning.
:::
:::
Not suggesting that Markdown is the right tool, only that it has extensions to capture semantic meaning. Here are example documents produced using Markdown:
But the various man source formats aren't semantic markup of any particular use. Yeah, you can ensure that all of your arguments are typeset as italic or something, but it's not consistent because there are different source macro packages and they do different things.
If there was useful semantic markup, it'd be great, because you could imagine, for example, tools allowing you to generate commands on the user's behalf. But the man source formats are mostly, at core, typesetting for 70's typesetting machines, not intended for modern reference documentation.
mdoc(7), which is the primary macro set used on BSD systems, is a 90s language (as opposed to a 70s language) with useful semantics that support both hyperlinking and featureful search, both on the web and in the terminal.
But the biggest value of manpages to me is somewhat independent of the underlying format: its quality as documentation. BSD systems have a strong tradition of cohesive usability, including good manpages. A lot of the manpage alternatives I see advertised in Linux circles (such as tldr pages or bro pages) are of little use to me, because OpenBSD manuals are thoughtfully written, clear, concise, complete, and have useful examples. The difference is very noticeable when I try reading manpages for programs I’ve installed from packages, which are often incredibly sparse or incredibly verbose, and lack examples in both cases.
The nifty features that come from the modern language and tooling used by BSD manpages are really just symptomatic of the overall care that BSD communities put into their documentation generally. I wish it were more widespread in the free software world.
From European perspective, Russia's latest invasion was a wake-up call that the peace isn't permanent, and diplomacy and economic power may not be sufficient to keep it.
Effectiveness of drones and advanced missiles in the war was also a wake-up call that semiconductors and batteries have a strategic military importance, and the rest of the world is quite dependent on China and Taiwan for these.
I assume that all the talk about trade deficits and unfair competition from Chinese EVs is bullshit, and the US and the EU are having an "oh shit" moment realising they're unprepared for the world where wars are fought with drones and robots.
No, I am not suggesting this. And to my knowledge neither did Russia at any point suggest this. If Russia did, kindly share. The probability that Russia will invade Europe is propaganda propagated by western media. Request you to watch the 2 videos I have linked above.
You are, in fact, either suggesting that or are entirely unaware that Ukraine had a peaceful agreement with Russia prior. The entire point of giving Ukraine official sovereignty was to reduce international pressure on Russia - everyone knew that reneging it would bring war to Russia's doorstep, it's written in black and white on the Budapest memorandum.
You can blame Russia for not knowing their worth, but they did break the treaty and there is no rational justification for doing so.
But that is what you are insinuating about Ukraine. We should not have let the Ukrainian people self determine their path and instead given them the cold shoulder and left them to Russia.
Rust can be optionally compiled in a panic=abort mode, but by default panics are recoverable. From implementation perspective Rust panics are almost identical to C++ exceptions.
In very early pre-1.0 prototypes Rust was meant to have isolated tasks that are killed on panic. As Rust became more low-level, it turned into terminating a whole OS thread on panic, and since Rust 1.9.0, it's basically just a try/catch with usage guidelines.
> Could such bugs be avoided in C using the right tools and strategies
"right tools and strategies" is very open-ended, almost tautological — if you didn't catch the bug, then obviously you haven't used the right tools and the right strategies! In reality, the tools and strategies have flaws and limitations that turn such problem into "yes but actually no".
Static analysis of C code has fundamental limits, so there are bugs it can't find, and there are non-trivial bugs that it can't find without also finding false positives. False positives make developers needlessly tweak code that was correct, and leads to fatigue that makes them downplay and ignore the reports.
The more reliable tools require catching problems at run-time, but problems like double-free often happen only in rare code paths that are hard to test for, and fuzzers can't reach all code either.
Static analysis of arbitrary legacy code is limited. But I do not find it difficult to structure my code in a way that I can reasonable exclude most errors. The discussion of false positives in C is interesting. In some sense, 99% of what the Rust compiler would complain about would be considered false positives in C. So if you want to have safety in C, you can not approach this from this angle. But this relates to my point. If it is acceptable to structure the code in specific ways to make the Rust compiler happy, but you do not accept that you may have to write code in specific ways to avoid false positives in C, then you are already not comparing apples to apples.
Even if you rewrite C code to the same "shape" as Rust, it won't become equally easy to statically analyze. The C language doesn't give the same guarantees, so it doesn't benefit from the same restrictions. For example, pointers don't guarantee their data is always initialized, `const` doesn't make the data behind it truly immutable, and there's no Send/Sync to describe thread safety. You have nothing to express that a piece of memory has a single owner. C's type system also loses information whenever you need to use void* instead of generics, unions with a DIY tag, and have pointers with a mixed provenance/ownership.
Rust checks that you adhere to the analyzable structure, and keeps you from accidentally breaking it at every step. In C you don't get any compiler help for that. I'm not aware of any tools that guide such structure for C beyond local tweaks. It'd be theoretically possible with enough non-standard C language extensions (add borrowing, exclusive ownership with move semantics), but that would get pretty close to rewriting the code in Rust, except using a bolted-on syntax, a dumb compiler that doesn't understand it, and none of the benefits of the rest of Rust's language, tooling, and ecosystem.
You do not get the same automatic guarantees when not using external tools. But you get almost the same results when using tools readily available and having a good strategy for organizing. I do not have problems with double frees, void type unsafety, or tagged unions in my code. I occasionally have memory leaks, which tooling then tends to find. I certainly have exploitable integer overflows, but those are easily and comprehensively mitigated by UBsan.
> If it is acceptable to structure the code in specific ways to make the Rust compiler happy
I think this is a misleading way of presenting the issue. In Rust, there are class of bugs that no valid Rust code can have (unless maybe when using the "unsafe" keyword), while there is valid C code that has said bugs. And here's the difference: in Rust the compiler prevents some mistakes for you, while in C it is you that have to exercise discipline to make sure every single time you structure the code in such a way to make said bugs unlikely. From this, it follows that Rust code will have less (memory-related) bugs.
It is not an apples to apples comparison because Rust is designed to be a memory safe fruit, while C isn't.
The point was that you can not reject warnings as part of a solution for C because "it annoys programmers because it has false positives" while accepting Rust's borrow checker as a solution.
I think the general point of my comment still stands, as you and everyone else working on the project would need to be disciplined and only release binaries that were compiled with no warnings. And even using -Werror doesn't fully solve the problem in C, as not having warnings/errors is still not enough to get memory safety.
I don't really disagree with you, but I was also making a slightly different point. If you need absolute memory safety, you can use Rust (without ever using unsafe)
But you get 99% this way with C, a bit of discipline, and tooling and this also means maintaining a super clean code base with many warnings activated even though they cause false positives. My point is that these false positives are not a valid argument why this strategy does not work or is inferior.
Your claim is that it is inferior because you only get 99% of safety and not 100%. But one can question whether you actually get 100% in Rust in practice in a project of relevant size and complexity, due to FFI and unsafe. One can also question whether 100% memory safety is all that important when there also many other issues to look out for, but this is a different argument.
This hack is a Rust compiler back-end. Backends get platform-specific instructions as an input, so non-trivial generated C code won't be portable. Users will need to either get pre-generated platform-specific source, or install the Rust compiler and this back-end to generate one themselves.