CryZe

The Yuzu devs banned anyone even mentioning TotK in the Discord. However, they apparently had some private Discord or something where the Yuzu devs shared ROMs between themselves.

Though arguably, the fact that in order to mutate data from multiple threads, the compiler,forces you to use some synchronization primitive, results in you having to think about how you are going to synchronize access, which should lower the chance of race condition bugs overall.

You could compile an actual syntax highlighter to WebAssembly and embed that into the font. That would address all the issues. However, WebAssembly is an off-by-default experimental feature for harfbuzz, so at least for now the current solution is the only feasible one if you want it to work in most places.

new.reddit.com seems to be an older layout than just reddit.com for me, one where most stuff still works (like video embeds).

You definitely also get a lot more thread safety out of Rust than most languages.

Not mentioned in the blog post is the new addition of `size_of`, `size_of_val`, `align_of`, and `align_of_val` to the prelude, which means they don't need to be imported anymore: https://github.com/rust-lang/rust/pull/123168/

No, from a quick glance those are only for moves of individual values. Lifetimes are something different. They are used for relating multiple (> 1) parameters / return values with each other. There is no way to have that without having a syntax for it.

It's important to note that lifetimes are not just for the compiler. They are also documentation / API contracts:

fn add_to_vec<'a>(element: &'a str, vec: &mut Vec<&'a str>) { ... }

This documents that the vec passed into the function can't outlive the element that's passed in. That's because the string (a reference (pointer) to the string data) that's passed in gets stored in the vec. So freeing the string and then using the vec would result in a use after free.

You can't have this power without a syntax for it. You could of course do some global analysis, but now you can't have API contracts like this anymore, which are important for semantic versioning.

An alternative syntax a language could use would be to have arbitrary pre- and post-conditions that the compiler can verify, which would be a whole lot more powerful, but also a lot more wordy than the short lifetime "tags" that Rust uses.

You are right, and whenever we drifted by 1 hour (or whatever is deemed too much) we can just update each time zone in the TZDB to be different by that amount of time going forward. This shifts the problem from a basically unsolved one (with how no OS properly supports TAI) to a solved one, time zones.

You could even align it with a DST transition in countries that have those where you simply skip one to apply the change.

There's Intl.Segmenter now which does Unicode Segmentation to count the amount of graphemes for example: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Though you are right in that I don't know of a built-in way to count Unicode Scalar Values (USVs).

It uses a custom renderer, which seems to just blit its image data onto a canvas. The HTML is just there so you can actually select the text.

> small virtual machine to process tiny code programs

Or even WebAssembly (though more of an experiment than anything): https://github.com/harfbuzz/harfbuzz/blob/main/docs/wasm-sha...

Yeah it's really mostly just a (heavily) stripped down binary JavaScript with basic arithmetic and operations to modify an ArrayBuffer. With Wasm-GC it's a bit more of a binary statically, strongly typed JavaScript. Either way, outside of static, strong typing, the binary representation and SIMD support, it's really not exposing anything fundamentally new.

This is no longer true, there's various high level types that WebAssembly can pass around, such as reference types (opaque objects from the outside world, i.e. JavaScript objects) and all the new GC types. So the only thing stopping you from calling into web APIs is importing them into the WebAssembly, which atm is indeed still a manual process (or automated with some codegen).

Reference types technically already allow for calling directly into the browser APIs as reference types allow wasm to pass JavaScript objects around. So if you import all the relevant web apis, you don't really need any (almost any?) intermediate JS anymore, because you can just forward the JS objects between the individual API calls.

The only real need for JS would be to initialize the wasm module in the first place.

I'd say that those are not actually the minimum. You don't need to detect undefined behavior, you just need to "make it implementation defined", so integers could just wrap around without needing to check for overflow, unitialized memory would just be random bytes, and so on. At least that would be one way to do it. Of course the checks would ensure the program shuts down more cleanly.

> but Hello World consumers TWO POINT EIGHT GIGABYTES of hard disk on my machine.

While yes, that's really bad, it's just temporary build files. The actual executable should be fairly tiny.

It is "const enough", as in, there is nothing preventing it from being called at compile time, in fact with nightly features (and no changes to the async fn), you can call it at compile time just fine. I also put const fn there to emphasize that it really can't do all that much beside constructing the state machine.

> Haven't done too much async Rust yet but I don't think it solved this issue from what I've seen.

In Rust an async function is really just a const fn that synchronously only constructs and returns a state machine struct that implements the Future trait.

So

async fn foo(x: i32) { }

essentially desugars to

const fn foo(x: i32) -> FooFuture { FooFuture { x } }

struct FooFuture { x: i32 } // technically it's an enum modelling the state machine

impl Future for FooFuture { ... }

You have to explicitly spawn that onto a runtime or await it (i.e. combine it into the state machine that your code is already in). So that's actually really cool about how Rust handles async; that an async fn really isn't doing any magic, it just constructs a state machine and never interacts (or spawns) with a runtime at all, so it never starts running in the background, you are always in full control. And by throwing the future away, you are essentially cancelling it, there's no need to interact with any runtime either.

wgpu at least prefers Vulkan over DirectX 12 on Windows.

It does not work for me in browser Safari (iOS) either:

undefined is not an object (evaluating 'navigator.wakeLock.request')

Update: Turns out it's only available behind HTTPS. The PWA bug might be related.

Doing this through the GPU is actually somehow A LOT slower on at least Windows than going through the windowing system.

However, in practice Rust's calling convention does actually depend on the operating system. So on Linux Rust will make use of the stack red zone, while on Windows it doesn't. (Also some codegen in LLVM depends on the operating system)

> mostly feature complete

I just played around with it today again and I immediately ran into like 5 bugs with font matching until I found out that there's not even an implementation for font matching other than "every property has to match 100%" (and if not, it falls back to an emoji font which is another bug), so there's not even the basic CSS font matching algorithm implemented (and the state of the fallback algorithm might be even worse then, as unlike the nicely documented CSS font matching algorithm, the latter is the undocumented hard part).

I just tried it in my own renderer (that uses tiny-skia) to compare performance, but unfortunately forma is still lacking some features to do a proper comparison (strokes, the ability to scale shapes up instead of only down (?????), rendering without clearing).

ABI wise that is not true though. structs have struct ABI, even just a newtype struct around an integer will not use integer ABI unless annotated with #[repr(transparent)].

Often when people say "Canvas" they mean "CanvasRenderingContext2D", which still lets the browser do all the text rendering. With WebGL you need to do all that yourself.

Oh right, I confused the terminology, but the point still stands mostly.

How is this supposed to work? The rotation of the earth is not a constant. So we either scrap UT1 ("the atomic clock") or UTC ("the calendar"). Neither sound like an actual option. The latter would imply that at some (far off) point in the future you wake up at like 10pm as UTC and UT1 are now entirely mismatched (you may as well get rid of all time zones at that point).

Yes, it seems to be.

I don't think I agree. A debug build of Rust code is often like 40x slower or so than a release build. Those optimizations make a huge difference. Binaryen can only do a fraction of them, so I wouldn't expect AssemblyScript to get close to Rust and C++ (and the benchmarks show that too).

> does AssemblyScript allow the same control over memory layout as C, C++ or Rust?

There's no UB, so in a way AssemblyScript is almost more low level than those, as you have full control over the memory and instructions.