Gankro

Yeah motivation is the bigger factor (why would Mozilla care about the system APIs of an OS, of all things?) but also it doesn't hurt that Apple is one of the richest companies in the world (depending on the day).

It's literally true that Rust tried and failed in the sense that Rust's early design was extremely similar to Swift's, polymorphic compilation and all, and it was thrown out when it didn't seem to work. Swift pushed on it harder, and got it to work.

But it's less so true in the sense that the two teams had different use cases, and simply took divergent paths. Rust took the "easier"* path that limited expressivity in favour of a simple execution model that requires a minimal runtime, which in turn enabled them to focus on more interesting static analyses. Swift took the other path.

* This may sound like a slight against Rust, but both the Swift and Rust folks who worked on this stuff agree that what Swift did is a comically huge amount of work in pursuit of a relatively niche use case (idiomatic-feeling system apis). There's only so much time in the world, and Rust spent its time on other problems.

More accurately I worked on stdlib stuff for both, with a focus on collections. It's just that this naturally pushes you into minoring in language design and majoring in the low-level details of the language. Plus it's hard to not pick this stuff up if you have to hang out with compiler people all day.

Yeah the smearing approach is the only one that merits a callout from my position in the pipeline, because the other approaches are handled by your shaper or rasterizer, which are usually 3rd party libs that can be mostly regarded as black boxes.

I mainly prioritize making my pages work reasonably with different zooms and window sizes, since all I really know for certain is that there's no ideal for everyone.

The font settings are just from a copy of bootstrap from like 6 years ago, because I have absolutely no eye for this sort of thing.

Yeah there's a reason all my examples use the same ~3 languages, and only a few random fragments from them. You just need a few examples that demonstrate that something can happen. Everything actually works pretty uniformly, so as long as you have a few examples that cover the interesting cases and handle those cases in a general way, everything tends to work fine. The actual font formats are much more nasty and corner-casey. (Thank god you don't need to deal with that, eh Patrick?)

Same reason I prefer to use imperfect terms that capture the important aspects of the problem-space from an english-speaking perspective. Are ligatures the right word for how arabic and marathi get shaped into glyphs? Maybe not, but as long as you get that the æ ligature can be synthesized from ae by a font, and that this is super important for some languages, you're on the right path.

I don't even know what the fragments I use mean, lol. I like to assume I'm just copy-pasting Arabic swears around. Apparently at least one is just Manish's name?

To elaborate on the float example, see JSON, where text-based representations of numbers has led to massive incompatibilities among different parsers and generators. The original "spec" didn't even define if numbers were doubles or infinite precision or what. This is much harder to mess up with a binary format.

http://seriot.ch/parsing_json.php

Ultimately it boils down to the fact that there's basically no interesting difference between an immutable reference to a primitive and the primitive itself in Rust. It can't dangle. The immutability can't be casted away. They just have a different ABI if the references don't get completely optimized away. You could do pointer equality checks on them if you really want?

Swift has taken the observation further and is investigating ways to avoid ever having a immutable+shared-reference-to-primitive vs primitive distinction in the language, while still introducing this distinction for types where it is interesting. (e.g. reference counted classes or atomics)

There will only be minimum requirements for GL/DirectX versions. I believe we require GLES 3.1, and then whatever DX version Angle turns that into.

even more clearly:

webrender is "the stuff that works pretty ok and we can run through CI". In principle enabling webrender should get you the ~same results as not having it on, visually, modulo a few known bugs.

webrendest is "everything we're working on, no matter how broken"

It's a pretty big project so there's lots of stuff in tree that's barely functional (especially true with the layers-free pivot).

Yes, let us never forget how many exploits there are in trivial codecs like ICO and BMP, because they're written in C(++): https://bugzilla.mozilla.org/show_bug.cgi?id=775794#c0

Yeah when we do named args it will very likely be based on Swift, but a bit different due to backwards compat and the desire to integrate it into existing methods like Vec::from_raw_parts and ptr::copy.

To clarify: C says it's UB, C++ rounds up to 1.

Do you mean:

* All unsafe operations don't exist.

* All unsafe operations exist, but the literal unsafe keyword and its machinery doesn't exist

The latter is how most ostensibly safe languages work. See Haskell's UnsafePerformIO, Swift's UnsafePointer, and Java's JNI for 3 examples off the top of my head.

The former is just a really gimped language that would have been a pain in the neck to implement libraries for (see other replies for examples).

Re: parameterized unsafe -- I think it's been discussed and rejected, I don't remember where. I think it was mostly a matter of "yes this would be more powerful, but the complexity isn't worth it".

Note that we sort of made a "new" kind of unsafe with the UnwindSafe trait: https://doc.rust-lang.org/std/panic/trait.UnwindSafe.html

That's probably how we intend to solve these kinds of problem in the future.

Re: aliasing -- if it's a serious enough problem, one of two things will happen:

* Someone will develop a version of asan/ubsan for Rust.

* The Rust devs will be forced to reduce the extent to which they apply alias analysis by default (possibly with a flag to opt into it). At least temporarily.

The rust devs have backed off optimizations in the past when they break stuff in the ecosystem (struct layout optimization). But they also work with the affected devs to fix those bugs so they can turn the optimization on.

Note that a lot of these optimizations aren't necessary in Rust -- e.g. list fusion is only valuable in Haskell because mapping over lists is exposed as a one-shot operation that produces a new list. So `map map map list` is conceptually building 2 whole lists of temporaries you don't care about (and you often don't actually care about the last one either, in cases where you just iterate over it and discard it).

Meanwhile mapping in Rust generally takes an iterator and produces another iterator that will apply the given closure to the current element as it's yielded. So the naive codegen for iter().map().map().map().collect() is exactly what list fusion is trying to produce -- no temporary lists.

TL;DR: making "map" having the monadic `T[U] -> T[V]` signature is really expensive. ¯\_(ツ)_/¯

Yeah the only thing that Rust might have over C, in terms of really optimized implementations, is low-level idioms that C declares to be UB, but Rust declares to be defined (generally to be what x64 hardware does).

Maybe something that leverages signed overflow, overlong shifts, or type punning.

But if you have enough control over your codebase to mandate the compiler/flags its built with, then you can generally tell the major C compilers to act like Rust in these cases.

That said, the expected win for Rust over C(++) in practice is that you can be more "reckless", because you have a stronger type system protecting you from messing things up. A production-quality C(++) codebase might rightly do more copies, use more reference counting, and use less concurrency just because the risk of doing otherwise isn't worth the potential performance wins.

Organizations have limited resources to commit to optimizing/verifying code. Rust is intended to get you more bang for your buck.

Yeah dropck is a fun little gem, which has received several post-1.0 revisions due to soundness problems.

I agree the system you propose would be simpler in terms of spec and effort, but I don't know about simpler to use. Much like removing mutable references in favour of `foo(X) -> X` would be a simpler type system, but awful to use compared to `foo(&mut X)`.

This is really ignoring how relevant and affine types interact with different features. For example, unwinding makes perfect sense with affine, not so with relevant. Rust has unwinding, and no effect system to track whether something can or can't unwind.

I also make it very clear that the implementation is mostly free. It's just using tools we already have with minor tweaks. Most of my issues are exactly the pragmatic matters: your standard library isn't built to handle it, nothing in the ecosystem is built to handle it, and it everyone has to opt into support for backwards compatibility reasons.

Literally the only link in the article, on the first use of the Official Terminology, is a link to the wikipedia page that defines all the terms.

Honestly I just think distros and package managers are the busted ones here. LLVM is strongly coupled to your language's semantics, and I'm unaware of any good reason to force every compiler to use the same version.

Ah good point. It could be that the first-preimage attack gets you exactly X, in which case it fails to handle second-preimage. I would expect this to be incredibly unlikely (especially since they seem to generally involve generating some random garbage). I would also expect most first-preimage attacks have a way to "continue" to a third value, eventually.

You seem to be mistaking or misreading something here.

* Collision attack: find X and Y such that hash(X) = hash(Y)

* Second-preimage: given X, find Y such that hash(X) = hash(Y)

* First-preimage: given hash(X), find Y such that hash(X) = hash(Y)

> If you have an encrypted message that you hashed/signed _before_ encrypting, and Eve wants to know what you said, first-preimage would be worse, and second-preimage wouldn't buy you anything.

first-preimage doesn't do anything here. It gets you some text that matches the hash. It's overwhelmingly unlikely to be the original message, and if it's not the exact original message, it won't have any similarity to it. Unless you can enumerate all hash collisions for a value efficiently, which is a much a stronger claim, this isn't any better than brute-force guessing the text.

> Getting the preimage of the document and hashing that preimage just gives you back the original hash---it's like an identity function. It doesn't give you a second document.

The second-preimage attack supposes you have X, the first-preimage attack supposes you have hash(X). If "all" you have is a first-preimage attack, then it's trivial convert it into a second-preimage attack. You hash(X) and feed it into your attack.

The Swift memory model is current incoherent; this is an attempt to fix that. (defining accesses properly, properly preventing conflicting accesses in single threaded ways)

Boring single-threaded swift code can currently be incredibly slow for no clear reason; this is an attempt to fix that.(addressors++)

The details this manifesto covers need to be settled for ABI-stability, which is still one of the primary goals for Swift. (because it enables making it a part of Apple's OSes)

The major holes are: class fields, globals, and captures of escaping (non-scoped) closures (which are basically class fields).

Although this system proposes dynamic checking for these cases, it's explicitly not atomic checking. Atomic checking would be very expensive even though most code doesn't need it. Also there's a general sense that java, which does atomically guard all shared mutable state, has the problem that these accesses are defined but ultimately useless. Part of this is that coherent updates require coarser locks.

The argument for Swift's behaviour is basically: very few things actually need this guarantee, and it's bad for performance (or memory usage) for all the other types to inherit it.

Personally, as someone who has spent a lot of time trying to manage the safe/unsafe code boundary, I'm inclined to agree with you. Unsafe code in Swift has an even scarrier subtle hazard: if the last uses of a value are through an unmanaged handle, the compiler won't know and can free the managed value before those uses. You need to insert a marker saying "please keep this alive". Even worse: returning a value, after inlining, isn't sufficient to establish a use!

That said, your lock handle example doesn't matter in swift today: you really want a lock handle to be a struct, and structs can't have destructors. You also want it to have move semantics, which don't exist yet. This proposal suggests moveonly values that could adopt destructors (like Rust), and if you're already adding an annotation for destructors, it's not out of the question to add another one asking for "true" lexical destructors.

Hit me up with any questions y'all have.

I always mess this up, but here's something from memory: I believe there's ABI things that motivate stage 2. The compiler built in stage 0 has historically had special ifdefs to deal with "features that don't exist in the old snapshot" (we aggressively adopt our own features in the compiler and stdlib, because that's a great way to test them). This implies it can potentially emit binaries with a different ABI from the compilers built in stage 1 and 2. So the compiler that's output from stage 1 can actually have a different ABI from the binaries it produces.

Normally this wouldn't matter, but Rust also supports compiler plugins written in Rust. These link directly to the compiler that compiles them. With the stage 1 compiler's quirky ABI, the plugins it compiles might not be able to interact with it.

The stage 2 compiler, on the other hand, uses the same set of ifdefs that the stage 1 compiler has. So it was built by a compiler with the same output-ABI as itself, and so plugins have the same ABI.

So:

* snapshot: Built with snapshot ABI, produces snapshot ABI (snapshots are old stage2 compilers)

* stage0-output: built with snapshot ABI, emits stage0 ABI.

* stage1-output: built with stage0 ABI, emits not(stage0) ABI.

* stage2-output: built with not(stage0) ABI, emits not(stage0) ABI.

I have no regrets. Everyone should get to know the fear and joy of this Makefile.

Ah good, now the whole world gets to enjoy the greatest Makefile ever. For other curiosities of Rust's history and bootstrapping process, I recommend brson's annotated stdlib:

https://github.com/brson/annotated-std-rs/commit/e50c2b16455...