Ths survey reminded me of a bunch of awesome features that I forgot were stabilized, many of which I can use in current projects lol. I know that wasn't the intent, but it's a nice side effect of filling it out I guess.

Ah but then you would actually have to use C++ /jk

Nice project!

Only somewhat related, but for myself personally, I've realized that the default UI for YouTube promotes doom scrolling as much as it possibly can. It seems to have a negative effect on my mental health and habits. So I live mostly without YouTube now, with only some occasional (once every few weeks), externally linked videos, that I usually download via yt-dlp or just quickly watch online. For online watching, I broke the page so bad with uBO that the page barely works, and there are no recommendations or after-you-finished-viewing transitions.

This approach seems to work well. I find YT to be a really dangerous place. In one phrase, "sweet death".

Bun uses JavaScriptCore. Deno uses V8.

But yes it would be good to see a comparison to JavascriptCore and V8.

To me the inertia could be measured in time to refactor projects.

How much time would it take to refactor or create a net new replacement of all of the lisp code of 1985 in active production vs all of the c++ in active production today.

I do not know the numbers but I would hypothesis a staggering delta in hours needed from the then to now. Even with advancements in code change velocity of today

There’s many components which could be split out from this JS engine such as Regex.

I’d love to see how it passes all ECMA tests

And Deno

Would be cool to have a comparison with bun.

This is super cool! I love seeing these new implementations of JS. boa is another JS runtime written in Rust as well.

I'm curious how easy it is to embed this. Can I use it from another Rust project? Can I customize module loading behavior, or set limits on the runtime to limit CPU usage or memory usage or intercept network calls? Can I use it from a non-Rust project? Or is this intended to be a standalone JS runtime called from the CLI? I've been looking at Boa as a JS engine for one of my projects, but I'm open to checking out brimstone too if it'll work.

This is interesting.

Compacting garbage collector, written in very unsafe Rust

UB didn’t matter.

There is no such a thing.

If you really must pretend this matters performance wise, look up MaybeUninit. It still requires unsafe{}, but it's a lot less trouble.

Using the sum of C and C++ is a bit misleading. If you use C++20 or later with containers, smart pointers, ... the number of memory safety problems goes down a lot. But if you include all the problems from C and older C++...

Inertia also accounts for time and popularity. The longer something has been around and popular the more inertia it has and the harder it is for something to change it. Back in 1985 things had a lot less inertia then they do today - C and C++ have been gaining it constantly for 30 years since then.

My logic was simply: I need a buffer that is only initialised once no matter how many times the function is called. statics are initialised at program start so they seemed like a good fit. and since I wasn't planning for the function to me called multiple times simultaneously it seemed like the UB didn't matter. (which I think was correct)

Try this one: https://xila.dev/book/get_started/

What made you reach out to a static mut in the first place?

Another commenter already explained why this is unsound, so I'll skip that, though static mut is almost universally unsound.

Note, of course, that main() won't be called more than once, so if you can, I would honestly just make this a stack variable containing a Box<[u8; 0x400]> instead. Alternatively, a Box<[u8]> can make it simpler to pass around, and a Vec<u8> that is pre-allocated with Vec::with_capacity lets you track the current length as well with the buffer (if it's going to have a variable length of actually useful data).

If you want to make it a static for some reason, I'd recommend making it just static and thread_local, then wrapping it in some kind of cell. Making it thread local will mean you don't need to lock to access it safely.

Thanks! That's exactly the answer I was looking for.

The premature optimisation quote at the end of your blog post is very relevant to me. I try do find the most efficient way right off the bat so very frequently the first questions I have in a project are like this one. Which in turn lead me to understand the underlying basics, which make me want to implement those basics myself, which sends me down a spiral to wanting to write my own kernel. All the while the project I started with gets forgotten, until I pick it up a month later and the whole thing starts again.

Maybe I should just try and learn C... or zig. And try and hold myself to the higher quality standard they demand. Especially since it feels like I'm doing that already.

The problem with static mut is that it allows you to create multiple mutable references. And also mix mutable and immutable references. Additionally, it is accessible by any thread. So, as long as you don't do any of that, it should be safe. Maybe I'm missing something.

If this is the entire program, it's not unsafe. But if it is just a fraction of the program, it may be unsafe. For example if 2 threads call the function at the same time. Since you would have 2 mutable references to BUF. Well, not actually unsafe since you don't use the mutable reference, only create it.

As to the other question, static variables are not in the stack. They have their own region of memory. If they were in the stack, they couldn't be accessed across threads, since each thread has its own stack.

EDIT: for completeness sake. For your last question. Yes, using a static buffer is probably more performant, since it doesn't need to be set to 0 each time it's called. However, that's not what statics are for. If what you want is just to avoid that setting to 0, there are ways to get initialized arrays. For example MybeUninit. Which would be way better.

Not really much to do here, but it is good to know. Practically speaking, running Rust in Lambda is exactly the same as it has been for a few years. Only difference is they don’t recommend against it in production. Same runtime, same library.

language popularity can change pretty quickly

according to the tiobe index, in 1985, lisp was the 2nd most popular programming language and c++ was the 10th. fast-forward 5 years and c++ took the 2nd place, while lisp fell down to 7th place. i wouldn't be surprised if something similar happened between c++ and rust

Considering the fact that there are crucial programs all across platforms that are written in Assembly and are still very relevant. This couldn't be more true.

I'm not sure that's a factor here because Google doesn't use CMake or Cargo (at least not the way we all use it).

How do I use this? The getting started link is 404