aapoalas

I believe Zig will always do bounds checks, except maybe in ReleaseFast mode?

I had an HP Mini 5102 and I absolutely loved it! I actually revived it a few years ago and used it for some modern programming tasks. I think I tried to compile rustc on it once and had to leave it on for the night, coming back to it in the morning and finding that it had just frozen fully.

Unfortunately its CMOS battery ran out and when I went in to replace it I had to unplug a few ribbon cables which of course promptly snapped the now-brittle plastic connectors. Its been sitting on a shelf waiting to be revived once again ever since... I miss that little thing.

Really cool to see Zig have strong support and a stable financial status <3

Ooh, cooll to hear you got some uptake on the call for formal methods help! Or did you end up figuring it out on your own? Either way, looking forward to the followup!

Oh, I was just watching this yesterday and got a little re-energised about getting back to more active development of my DoD JS engine! Thanks!

Beyond just quite possibly being slop, this is also sloppy and confused: complaining that C++ cannot remove features because they live in the stdlib forever while listing out a bevy of features that got deprecated and then removed is just oof.

Also, fun fact: Rust cannot remove anything from std once stabilised, presumably forever. Take this with a slight grain of salt, I haven't vetted this thought myself, but it's what I hear from Rust project people and I've just been in the project all-hands for three days.

Rust does partially have an easier time since it eg. does not guarantee the ABI of various std types like Vec (although the size and alignment are probably guaranteed at this point), and with 1&mut XOR N& providing local reasoning and isolation you get to change internal details easier.

This bug was already reported very soon after the merge.

They have a PR (~~closed by GitHub bot as AI slop, ironically~~ this was wrong info, it was apparently closed by Jarred himself as it missed a conversion or some 20 Zig files to Rust) to remove the Zig code.

I guess the answer is "no".

Regarding the architecture documentation you have up on tsz.dev, one thing that jumped out to me was the use of the per node typed side pools. A semi-recent talk[0] had benchmarked this and found it to be a deoptimisation: he couldn't explain it, but an audience member suggested it is likely because an AST is not generally very type-homogenous in its visit order. After a CallExpr node the next node to visit is probably not a CallExpr but more probably an Identifier etc, so storing the node "extra data" in separate pools makes them more likely to be cold in cache rather than hot.

In Nova JavaScript engine[1] I've done exactly as you've done and split objects into typed side pools (I call them "(typed) heap vectors") but in a JavaScript engine my _hypothesis_ is that the visitation patterns are much more amenable to this: an Array, Set, or Map is more likely to be homogeneous than heterogeneous, and therefore a loop over the contents is likely going to hit the same side pool for each entry.

[0] https://www.youtube.com/watch?v=s_1OG9GwyOw [1]: https://trynova.dev/

"They're your feelings and no one else has the right to how you should feel about them."

Remember to be careful with looping lest you create an ikikieriö.

Would kernel huge pages possibly have an effect here also?

I may have not properly read the paper that said "This is not a visa, you should apply for a visa using this paper"...

I have very fond memories of Kansai airport. First time I went to Japan I ... Uhh, I didn't have a visa despite going there for exchange.

The Kansai airport immigration office uttered a lot of "oohs" and "eehs", but they came through and in less than 45 minutes my appeal for deportation was accepted and I was granted a 1 year student visa. Always makes me happy when I pass through there :)

You and me both; never change you beautiful bastard of a language <3

If you want to take a look at some of the "big drivers", the Project Goals[1] is the right place. These are goals proposed by the community and the language developers put together, they are not explicit milestones or must-haves, but they do serve as a guideline to what the project tries to put its time and effort on.

[1] https://rust-lang.github.io/rust-project-goals/

He is the Rust project lead, and the Rust project has been doing quite a bit of user, adopter, and non-adopter interviews over the past few years.

It's also been ridiculously slow for a month or two now :/ not a good time to be working on some relatively intricate performance optimisation with DevTools taking 1-4 seconds to even start the performance recording.

I was sitting behind you as you wrote this comment.

I just wanted to tell you that.

F.ex. they didn't do postgresql and other DBs separately but instead just had a databases room.

Monkey's paw: you get your wish, but so does someone who wants RAII and single-use-malloc to be left behind as a leaky and bad abstractions.

We all happily march into a future where only arena allocation is allowed, and when the arena is overfull it can only be fully reset without saving data. Copying still-used data out if it before reset is not allowed, as that's a copying half-space garbage collector. Reference counting is of course not allowed either as that's also garbage collection. Everyone is blessed...?

I aim to displease!

Author here: to get the compiler to help me as the programmer to produce correct code (not accidentally using handles after GC) without being massively manual, but (at least currently) accepting that it is not a guarantee and thus runtime checks (bounds checks in my case) are needed to retain memory safety.

Preface: I am not a compiler engineer at all, so I'm just spitballing silliness here.

Avoidance of type feedback counters and such. Get LBBV to clean out the redundant type checks (Higgs proved this well, avoiding something like >90% of them) and produce a format, perhaps a high-level bytecode or just an HIR, that can be used as an input to start a method-level JIT compilation.

So, LBBV gives the quick and easy basic block compilation and cleans up the very easy stuff but leaves enough information so that a follow-up compiler can still use it as input.

I'm a little sad to see YJIT go down in favour of a traditional design. (Yes, YJIT isn't "deprecated" but the people working on it are now mainly working on something else. That's hardly a great place to be in.)

I'm personally quite interested in trying out an LBBV JIT for JavaScript, following in Chevalier-Boisvert's Higgs engine's footsteps. The note about a traditional method JIT giving more code for the compiler to work with does ring very true, but I'd just like to see more variety in the compiler and JIT world.

Like: perhaps it would be possible to conjoin (say) an LBBV with a SoN compiler such that LBBV takes care of the quick, basic compilation and leaves behind enough data such that a SoN compiler can be put to use on the whole-method result once the whole method has been deemed hot enough? This is perhaps a totally ridiculous idea, but it's the kind of idea that will never get explored in a world with only traditional method JITs.

This is Oliver Medhurst' project: https://goose.icu/

It has stable funding and a full-time development team of 1.

As a fellow (but way junior) JavaScript engine developer I'm really happy to see the stricter mode, and especially Arrays being dense while Objects don't treat indexed properties specially at all: it is my opinion that this is where we should drive JavaScript towards, slow and careful though it may be.

In my engine Arrays are always dense from a memory perspective and Objects don't special case indexes, so we're on the same page in that sense. I haven't gotten around to creating the "no holes" version of Array semantics yet, and now that we have an existing version of it I believe I'll fully copy out Bellard's semantics: I personally mildly disagree with throwing errors on over-indexing since it doesn't align with TypedArrays, but I'd rather copy an existing semantic than make a nearly identical but slightly different semantic of my own.

Guidance towards correct usage: eg. If you allow `a[10] = 2` and just make the Array dense, the user might not even realise the difference and will assume it's sparse. Next they perform `a[2636173747] = 3` and clog up the entire VM memory or just plain crash it from OOM. Since it's likely that the small indexes appear in testing and the large indexes appear in production, it is better to make the misunderstanding an explicit error and move it "leftwards" in time, so that it doesn't crash production at an inopportune moment.

Author here if anyone wants to throw rotten tomatoes at me :)

Hmm, I at least received a refund on the tablet; I think half of it was paid out and half of it I opted to use as payment for Sailfish X.

An email I have stored from July 4th 2017 mentions "the tablet refund tool", so there seems to have been a concrete system for this refunding process as well. I abstractly remember something like that, though I must say my memory is shoddy and should not be trusted.