> I think there were enough attacks already for cargo that one can not call this FUD.
What attacks are you referring to specifically?
> It is also obvious that this way to distribute software is susceptible to supply chain attacks. cargo audit is an attempt to fix this retrospectively, but does not fix this fundamentally broken model.
This is the FUD I'm talking about. If you worry about supply chain attacks, it's not harder to be careful just because dealing with dependencies in general is much easier. You have to vet your dependencies no matter what.
> The Linux distribution model worked perfectly fine for the 30 years I am using Linux.
The xz scandal was a damn close call. Linux is a forest of distributions, and each distribution is a separate vulnerable organization.
> On the other hand, systems like cargo a clearly a supply chain disaster.
I don't think that has been shown to be true. There's a lot of FUD, though. Tools like `cargo vet` and `cargo audit` seem to be pretty good.
> I also think that languages should not have their own specific packaging system. This should be done on a distribution level, which provides curated lists of software. This system works well in the Linux world. The problem is the support for the commercial platforms.
I mean, it works until it doesn't. There are really significant drawbacks to this as well, including the knack some distributors have for thinking they know better than the original developer.
Security is not, and in fact can never be, all-or-nothing. An imperfect solution is better than no solution. Developers have the reasonable expectation that opening a project in VS Code does not upload their home directory to a remote server. Performing a full build of a project is a different operation with different associated expectations.
I think it's pretty obvious they are referring to package management functionality as the radiator fluid in this analogy, and the compiler is the fuel tank.
I'm sorry, I have to address this take every time someone brings it up. The lack of a modern, ubiquitous, cross-platform packaging system is an absolutely terrible thing for C++.
I've worked on many large projects in C++, and every single one of them contains a bespoke, buggy, undermaintained JSON parser, URL parser, configuration file parser, async framework, and so on. It used to be the case that almost every large C++ project started out by defining its own friggin' string type.
Dependency anxiety is a variant of NIH syndrome, and it leads to much, much worse quality software in the average case. Most companies are not in the business of writing a bug-free async framework, and yet here we are. The cost of vetting your dependencies is much, much lower than writing and maintaining all these things from scratch.
I think "build systems" is a too broad category in that argument.
Language-specific build facilities, like Cargo's build.rs and Zig's build scripts, typically have a limited scope - generating a bit of source code, discovering some linker flags, stuff like that. These scripts need to be run by LSP servers when opening the project in an editor to get basic features working, so that's a fairly risky thing.
They are also currently doing things like invoking CMake and other build systems, but you could definitely conceive of a world where that was a separate step in the build process, and that world seems pretty attractive to me.
A common pattern in Rust projects is to have a `*-sys` crate representing the C FFI bindings, and they typically also do something like invoke CMake or similar to actually build the C/C++ library underneath. But if you have a larger project that already integrates multiple build systems, this is really quite inconvenient in most cases.
This approach is harder than you might imagine. LLVM can do a lot of things that don't map to C language constructs. You cannot generally roundtrip arbitrary LLVM IR through some C representation. You can emulate most things, but you won't necessarily get the same LLVM IR in the other end.
Interesting read, even as someone who isn't using Zig.
I wonder, these arbitrary-width integers... Is it actually even really worth it? My intuition is to prefer manually packing/unpacking things instead (in any language, even C that has bit width for struct fields), because it gives me a better mental picture of the code that is actually generated. Particularly for something like an signed odd-bit integer - what kind of code gets generated for sign-extension, a presumably common operation?
Does anybody have other experiences with them, one way or the other?
Ruby has both kinds of operators as well, and it's fine. The thing in Ruby, though, is that the English logical operators have lower precedence than the symbolic logical operators, so you can use them in place of parentheses. Sometimes that's confusing, other times it can be used to make code very readable.
In general, I would expect symbolic operators to be desirable in complex boolean expressions, because "loud punctuation" stands out among English words when reading the code.
Driving in Europe would be completely impossible without them. I have no idea what the Greek word for "no parking or stopping between 09 and 15" is, or the Croatian word for "left".
Where I am, I was taught that activating the turn signals means "I have made a decision to change lanes", so the appropriate reaction from surrounding traffic is to either safely accommodate that choice, or indicate using the horn and/or lights that the decision is unsafe and must be cancelled.
I'm in Scandinavia, and it feels like surrounding regions have similar conventions.
From outside the US, nothing about him has really been predictable, except that he consistently lies about everything.
The only predictable thing about this American presidency is the total chaos that has been inflicted on the world by millions of intellectually degenerate Americans. This is what the world sees. Almost nobody is making excuses for him, everybody is trying to move on without the US.
So yeah, in that sense another war is simultaneously an unpredictable outcome and an unsurprising outcome.
The US is a statistical outlier in almost every single metric. Almost nothing about the US generalizes, not to the world as a whole, and not to other Western countries. Certainly not to functioning liberal democracies.
The important thing is that Rust editions affect semantics and name resolution. In such an analogy, JVM bytecode is the equivalent of Rust code - various semantics are baked in, but stuff like name resolution isn't (at least not completely).
As far as I understand, this is purely a result of lack of maintainer resources. Apparently, nobody has been bothered enough by this to contribute the relevant changes.
Keep in mind that all of rustc and libs development takes place on Github.
It’s just so unbelievably immature, and I know of no other industry where this is common.