McAfee wasn't always this shit, and ads on non-porn sites weren't as malicious.
8,244 karma · joined March 28, 2012
And yeah, using a faster but safe language could help immensely.
> Zig's value prop is different and closer to a modern C: it fits in your head and it maps fairly closely to assembly.
This can't be correct for the simple reason that it has both a modern optimizing compiler (LLVM) and UB.
A modern compiler will try to autovectorize your code, so you don't really know what the assembly will be.
UB gives compiler license to rewrite your code however it sees fit.
I'm pretty sure you can't just do a precise 128 byte align, if one of the element is an image blob or varchar(1000).
Just because you expect people to behave like X doesn't mean they will. In this case people will automate packaging of artifacts.
NPM was a third party manager (it's not part of EcmaScript nor was it part of Node.js at start) and so is Maven. Reputation matters more than origin.
Those who do not know history are doomed to rediscover it.
Batteries also don't help if dependencies don't replace them. Arrayref functionality has been part of Rust std lib for a while now.
If Odin gets moderately successful someone will probably reinvent it.
Just because you don't develop a package manager for your language, doesn't mean someone else won't. See NPM.
I meant zipping colloquially as in compressing an archive format. But you seem to get the gist of it ;)
> in Blizzard games, those were "zips" of heavy data files, notably read only data blobs. The game would read them, unpack in memory, and serve appropriately.
Not just game files but also the map format for Warcraft 3 was a glorified MPQ (source: https://867380699.github.io/blog/2019/05/09/W3X_Files_Format).
So whenever you edited a WC3 map, you were zipping the current map into an archive. Much like the GIMP example. Of course, WC3 didn't use as many XML files, though SC2 changed that.
And Starcraft 2 data is just bunch of XML files.
EDIT: Narrowed the date.
Better Zipped XML than whatever monstrosity Adobe files are. PDF/PSD... shudder.
Wachowskis just don't know any better. You think it's air your breathing now? Oxygen? More like plant waste product.
Also no ecosystem is in perfect harmony. It's basically jenga tower where you pull a piece on a long enough scale it looks eternal.
> Executing code compiled with target features that the current thread of execution does not support
I.e. calling AVX512 on Neon architecture.
You need to wrap it in target attributes to even dream of it being safe.
> # How does this relate to the "pin ergonomics" initiative?
> This work is an alternative to Project Goal 2025H2: Continue Experimentation with Pin Ergonomics, which includes the following extensions:
> A new item family pin in lvalues, e.g. &pin x, &pin mut x, &pin const x.
> A one-off overload of Rust's Drop trait, e.g. fn drop(&pin mut self).
> A new item kind pin in patterns, e.g. &pin <pat>.
> Notably, this work does not solve pin's duplicate definition problem, meaning that even with these extentions we still end up with Trait and PinnedTrait variants of existing traits. The Drop trait being the exception to this, since the initiative is proposing to special-case it using a one-off overload.
Latest batch of LLM's Linux had 423 vulnerabilities. Out of which 10 were Rust*. Would you prefer more or less CVEs?
But it's like seat belt analogy. It's a helper not a panacea.
* Granted Rust isn't in the entire kernel yet. D
Presence of worse bugs won't make memory bugs disappear.
No. I said borrow checker allows unbound lifetime. I didn't disagree with you. I noted you didn't read the argument.
> If you know what I meant, then what's up with your snarky comment about "So much for effectively disabling stuff"?
Because your original code looked like trying to cast mut u32 to pointer.
> you did effectively disable the borrow checker in safe parts
So this code (https://play.rust-lang.org/?version=stable&mode=debug&editio...) runs now?
Effectively means achieving the goal in satisfying manner.
Writing unsound code is less of effectively disabling borrow checker and more of a hack.
Think about it, if using Java unsafe I gain access to underlying HashMap array and do weird stuff to the HashMap invariants am I effectively turning HashMap into Array or am I doing a hack job?
Edit: By that logic since there is so much unsafe in the code base isn't borrow checker effectively already disabled? You can argue semantics but no, borrow checker isn't de facto or de jure invalidated by unsafe blocks.
It's invalidated by unsound unsafe and that's on code writer to fix.
You just listed examples of unbounded lifetimes.
> I said "effectively disable". For example:
Not sure what you meant by this example since it doesn't compile. It seems the borrow checker caught your mischief. So much for effectively disabling stuff :P
You haven't effectively disabled anything; you just (tried to) wrote unsound code that washes one mutable ref as another. This stuff is allowed provided shared refs are never accessed at the same time (for example, panicking upon reading reference_b).
What you probably meant is https://play.rust-lang.org/?version=stable&mode=debug&editio...
But you know what? If you're dabbling in unsafe, you have this big button called Tools in the playground. Choose Miri, then run your code; it will display large Undefined behavior. It even highlights the `trust_me_bro` function.
Hell, run this with UBSAN, ASAN, and other C tools. They will probably catch any such behavior.
As for the actual unloaded question, "What's the point of unsafe in Rust?" it is to contain and make it easier to identify sources of UB.