Not only Trump. Without the rules, Musk or Putin could run as well, the latter even work-from-home style. Also, if justice being blind is so bad before an election, why not after? Figuring out who won shouldn't involve any courts either. The public will just need to figure out who really won for themselves!
I'd rather fix the abuse (the cause of the particular burnout), because it impacts not only the Rust developers, but all current and future contributors, and indirectly us users as well.
You know, people outside the Rust community keep bringing this up as some kind of argument against it. But to me, it's one of the biggest points for it; because the important thing about `unsafe` encapsulation isn't what's inside of it, but what's possible on the outside.
I bring it up because Rust evangelists like to pretend that Rust code with no explicit “unsafe” in it is safe. It’s not safe, though, as long as the dependencies use it.
I enjoy coding in Rust. I don’t enjoy the shit name its community gives it.
Oh yeah you're right that's been stabilised, now that I'm thinking about it, it was probably something like `self: std::sync::MutexGuard<'_, Self>` which told me to enable the feature
From the Linux Plumbers Conference from a couple days ago: https://www.youtube.com/watch?v=Xw9pKeJ-4Bw&t=8040s (Warning: It's a longer stream, but the timestamp should be where the driver is shown. There's a table of contents down in the comments.)
Just tried that command (wanted to give rebellion a bit of a go anyway) on my dual-core 4GB laptop with an SSD:
real 5m18,721s; user 6m22,607s; sys 0m20,515s
So, given that the SSD seems to make a difference, and looking at the build output, and that my CPUs looked rather bored, I'm wondering if it's the local documentation builds.
Have you tried `raco pkg install --no-docs rebellion` for comparison? That completes in around 44 seconds on my system.
Not sure about good solutions though, I only use racket for prototyping at the moment.
Honestly, after running into the phone number requirement it's gonna be hard to get back my trust.
You required the phone number after you got all my account details. You wouldn't let me remove my account without first giving you my phone number. When I contacted your support to get you to delete my data, a simple back and forth like "you're gonna lose all your data!" and "I don't have any data" made them completely fail the Turing test. It's clear they don't really read what I was writing, they're just responding to whatever the first thought is that comes to their head.
I don't know if they're overworked, underpaid, or have quotas. Either way, none of the experience of trying to join an OSS development channel on Discord are in any way conductive towards trust. I mean, I couldn't even copy and paste the phone number requirement error message.
And I guess it’s 2015 edition, because it’ll fail in 2018 edition Rust: where the 2015 edition has ::u8(0u8), the 2018 edition will need you to write crate::u8(0u8) or self::u8(0u8), since only crates exist at the top level now, rather than the contents of the current crate as well.
Yeah it's indeed the 2015 edition because while compiletest watches for // edition:something comments [0] (like this [1]), it doesn't pass any edition flag to the compiler if no such comment is present, and the rust compiler defaults to the 2015 edition if none was specified.
However, the compiler has to continue to be able to compile 2015 edition code, as it is still guaranteed to work and be intermixable with 2018 (and soon, 2021) code in the same application.
For curious people unfamiliar with the situation with this: Rust cares about backwards-compatibility so that you should still be able to compile code from 2015 in 2042 (some libraries are just stable!), but it also wants to allow certain changes to the language that you might think would be backwards-incompatible. Each crate (library) declares an edition, and the compiler follows the rules of that edition, and then you can link all the different crates together without worrying what edition they were written in. Editions are limited in what they can change, because things like traits are shared between crates, so they can’t be changed in editions; it’s mostly syntactic stuff, like the 2018 edition making async/await keywords and making dyn a full (rather than conditional) keyword.
I'm not very knowledgeable with how compilers or language standards work, but would there not be security implications with this approach?
For example let's say a security exploit surfaces in the 2015 edition of Rust, would that not mean all the libraries declared as 2015 edition would have to be updated or abandoned in that case?
Or now that I think about it, is it instead the case that a whole program including all dependencies will be compiled by the same compiler (of which newer editions will have the latest security fixes), just that the compiler will always have to support compiling programs using legacy syntax when it identifies the crate's edition?
It's just syntax differences. The newer compiler supports all previous language editions, you're not using a 2015-era compiler to compile 2015 edition code.
Rust is not ABI-stable, there is no guarantee that you can even mix libs built with different versions of the compiler. The entire Rust tooling is built around static linking and building all your dependencies from sources. So yes, all the crates that go into your program are built with the same compiler, it's just that the compiler knows how to paper over the syntax differences in the different language editions.
> Or now that I think about it, is it instead the case that a whole program including all dependencies will be compiled by the same compiler (of which newer editions will have the latest security fixes)
It's this. Rust doesn't (yet) have a stable ABI for functions that aren't marked `extern "C"`. Any security vulnerability that would affect code in rust-lang/rust would most likely be in the standard library, which doesn't change between editions. All code links to the same libstd. Only the compiler frontend changes
JavaScript had something close, valid on the context level, with "use strict" (which is, I guess, borrowed from Perl), and I still don't understand why they don't repeat that for newer features that would be much simpler if they broke backwards compatibility.
Well, the ability to specify python version by module would've made migration much easier for everyone (in theory). But you're quite right that it wouldn't by itself be a solution -- it would also have required additional complexity to handle interoperability when calling between python versions, both in the runtime and the programs themselves (even a sufficiently smart compiler can't figure out what string encoding a python2 function expects).
(/s just in case)