cwzwarich

Rosetta does support executing 32-but code in alternate code segments created in a 64-bit process, used by CodeWeavers’ Crossover: https://www.codeweavers.com/blog/jwhite/2020/11/18/okay-im-o...

To be fair to people using 'a/'b-type variables:

1) They are used pervasively in the standard library and its documentation.

2) Due to lifetime subtyping and implicit bounds, descriptive names may be inaccurate. For example, if I have an Ast that contains slices with a lifetime of the source code, I might decide to write Ast<'source>. However, what do I do if I then have a reference to such a thing? Do I add another lifetime parameter, e.g. &'ref Ast<'source>? If I am not going to be returning any of the 'source-lifetime slices, this additional parameter may be redundant. In such a case, do I write &'source Ast<'source> or &'ref Ast<'ref>? Both of those names are incorrect. Do I keep around an extra lifetime parameter to get the correct names (and be more future-proof), or do I just suck it up and use 'a?

The closest thing to Swift’s approach to polymorphism in the academic world is intensional polymorphism:

https://www.cs.cmu.edu/~rwh/papers/intensional/popl95.pdf

Number of distinct mnemonics doesn't really determine ISA complexity. As an extreme example, how many AArch64/RISC-V instructions are there corresponding to an x86 MOV?

It's pretty sad that C/C++ finally accepted that arithmetic on contemporary computers is twos-complement but kept UB on signed overflow to ensure that compilers can continue to optimize loops with signed indices. If everyone used unsigned indices as the default for loops, then the UB could be eliminated with no real performance consequences.

I am the creator / main author of Rosetta 2. I don't have a blog or a Twitter (beyond lurking).

You could say the same thing for any abstract mathematical construct, e.g. metric spaces. There's no theorem (that's not itself about metric spaces) that can only be proven using metric spaces. It's always possible to make new abstractions (simply take the antecedent of any theorem), so whether you adopt a new abstraction is a matter of taste and fashion.

In Grothendieck's early work on abelian categories, categories are themselves the objects of mathematical study, and nontrivial results about them are established.

Which of the results mentioned in the article are proven by applying some result of category theory to another field, and which are just stated using category theory (with the real mathematical insight lying elsewhere)?

I used to be a religious devotee to Lisp, but then I started programming for a living and realized that static type systems (even of the simplest variety) are so helpful for preventing bugs. Unfortunately, I never found a typed variant of Lisp that I really liked; the uniform Lisp syntax doesn't collide well with the stratification of types and values.

> The way a function is declares looks just like a variable assignment for instance, but in a compiled language it pushes the wrong paradigm on me, since that's pretty much immutable.

I think one of the problems with the syntax is that colon (ordinary used for type ascription in ML-family languages) is being used for... something else. For example, in

  foo: (x: int) -> int = (expression using x)

the introduction of the 'x' binding is in the type position of 'foo', whereas in OCaml it would be

  let foo (x: int): int = ...

Here the binding of 'x' is associated to 'foo' rather than first appearing in type position. I think this is more readable, and the component parts are more easily parsed by humans. One could argue that visually, using an arrow as in

  let foo (x: int) -> int = ...

is more readable, but the OCaml syntax captures the fact that the RHS of the binding is defining an 'int' rather than a function value.

> I must admit that I'm mostly writing Python and JS these days, but the way the colon is being used feels grossly inconsistent and confusing. Why not say std.vector for instance now instead of std::vector?)

One potential sensible distinction would be to use one for statically determined paths and the other for dynamically determined paths (including the separate dynamic phase of compile-time constexpr evaluation).

> We're often told that Rust is hard because the underlying problem is hard, but I've encountered many cases where that's not true, it really is just the borrow checker. And unfortunately, most of them are problems that Polonius won't fix.

Out of curiosity, what are your favorite examples?

This phenomenon is actually another example of the phenomenon he mentions. In strict precedence parsing, operators are assigned meaning rather than productions of a grammar (which would could those operators in distinct contexts), so once you've decided a comma indicates a tuple, it's easier to just allow this syntax.

Facebook Infer is now just an ordinary unsound static analysis tool where some of the original analyses are inspired by separation logic. It doesn't actually prove any facts about the program being analyzed using separation logic.

You're reusing some components from rust-analyzer, so is there any reason you didn't go with a more query-based/demand-driven architecture, e.g. by also using salsa?

> it's encouraging to me that Rust's semantics allow borrow checking to keep getting better without breaking changes

Just to be clear, these are breaking changes. If the new borrow checker didn’t break existing code, they would have removed the old one long ago. They’ve just decided that the observable effects of the breaking change in the ecosystem are small enough (especially after warning about them for years) that they are okay making the breaking change without a semver-incrementing Rust 2.0.

To be fair, the reason for the breaking changes is generally to fix soundness issues (of course, not every example of code now banned will exhibit unsoundness), but that doesn’t cover all of them. There were some completely sound (albeit useless) examples of partial initialization that broke with NLL:

https://github.com/rust-lang/rust/issues/21232#issuecomment-...

https://github.com/rust-lang/rust/issues/54987

Strict adherence to semver would require still accepting this code.

From https://support.apple.com/en-us/HT208909:

The True Tone technology in Mac computers, Studio Display, and Apple Pro Display XDR uses advanced multichannel sensors to adjust the color and intensity of your display and Touch Bar to match the ambient light so that images appear more natural.

One of the most well known is Igalia: https://www.igalia.com

> 2. Contention is resolved by adding the blocked thread into a wait queue. The queue is allocated/discovered via a global hash table, keyed by the address of the mutex. The mutex keeps a stable address while locked, as the lock holds shared ownership and so the mutex cannot be moved for the duration.

Wouldn't this break any platform-specific priority/importance donation mechanisms, or does Linux have a way to work around this?

What’s an example?

Unless they've made a recent radical change, data races on multiword values (e.g. interfaces and slices) are unsafe in Go. In other GC languages (e.g. Java and C#), data races don't compromise memory safety, but Go made different implementation choices.

> So it’s not statically memory-safe. That’s not hugely attractive I have to say.

Ref-counting with mutable data (which this seems to be replacing?) works the same way in Rust. You need to take an Rc/Arc of RefCell, and calling borrow/borrow_mut on RefCell can fail at runtime.

> So it's not too much of a mark against Rust that it doesn't have proper documentation for those aspects either.

There is obviously the benefit that this generally only affects unsafe code (as opposed to C/C++ where the scope is less clear), but Rust just passes the buck to LLVM and inherits the partially baked solutions being used in practice for C++. And if Rust ever changes this, it will involve either splitting the language into distinct versions or breaking strict backwards compatibility.

> But there is much, much more to a large programming language like Rust than those things, and Rust is missing documentation (of the sort that intends to be complete and correct) in many important areas that don't have that sort of excuse.

As somebody who has contributed to both rustc and LLVM/Clang (and would probably rather program in Rust than C++ at this point), I think it would be much easier to implement C++ from scratch than Rust for this reason. The C++ spec is incomplete and some portions are internally inconsistent, but at least there's a real spec. When you hit one of these problems you can just look at what other implementations do in practice. Rust doesn't even have anything resembling a spec.

> first-in-first-out rules in Sweden

I don't know anything about Swedish labor law, but wouldn't it be LIFO rather than FIFO?

> What I find funny is that Pratt's parser was never really a theoretical result and was never properly covered in popular compiler textbook.

The theory behind precedence parsing was studied a decade earlier by Floyd (who is cited in Pratt's paper). Pratt's own paper is more about the justification of considering operators to have semantic importance rather than productions of nonterminals.

> My brother is a pharmacist, and is constantly shocked by the prescriptions that healthy people bring in to get filled.

While I definitely agree with your general point, how does your brother know that they’re healthy or don’t need to take the medication? I’ve never had any discussion with a pharmacist (in the US or Canada) where I’ve revealed this information.

> Rust's popularity is certainly helping that, though I wish they hadn't repurposed the existing word "enum" to serve as a new synonym for a concept with an existing name ("algebraic data types").

What keyword would you prefer they use instead, "datatype" like SML?

That doesn’t stop “Google engineer says…”

Here’s a paper describing a simulator that worked by similar means:

https://dl.acm.org/doi/10.1145/384265.291063

It’ll help, but still won’t get you down to the 10-20x cycle overhead range that you need to claim success.

It’s probably not even possible to emulate the Pentium Pro (or any other out-of-order x86 CPU) in a cycle-accurate fashion at the original speeds on contemporary hardware. Just attempting to match the original behavior for instruction scheduling, cache models, branch prediction, etc. would blow your CPU budget.

> I remember wanting to ask a rabbinical scholar if the product would count as unleavened bread.

It would (almost certainly) count as leavened bread. Jewish law defines chametz (leavened bread) as a combination of one of five species of grain and water that has been left for a short period of time (usually 18 minutes) without cooking. Maybe they could get the autoclave time down low enough to make it work?