That's basically exactly what Go's `go` keyword does. Good design in my opinion.

this project is pretty interesting, although i'm wondering how they're planning to address the "easy sandboxing" design goal in a compiled language with raw pointer arithmetic and clib interop... in that regard i think lua would have been a lot easier to sandbox, despite the author's concerns.

(also, they might want to look into lua userdata, since that would address their concern about the overhead of converting between native and lua data structures. the language is designed to be embedded in C programs after all)

The operation is slightly more complex yes, but has there ever been an x86 CPU where SUB or XOR takes more than a single CPU cycle?

I wonder if you could measure the difference in power consumption.

I mean, not for zeroing because we know from the TFA that it's special-cased anyway. But maybe if you test on different registers?

I may have missed something when skimming the paper, but it sounds like Xor filters are constructed offline and can't be modified efficiently afterwards, whereas Bloom filters can be inserted into efficiently. So they don't seem to be an exact replacement

No, you are correct. I misremembered with cuckoofilters.

I wonder if the reason the escape analysis fails could be that, for small enough types, the concrete value is directly inlined inside the interface value, instead of the latter being "a smart pointer" as the author said. So when the compiler needs to take a reference to the concrete value in `vs.chunkStore`, that ends up as an internal pointer inside the `vs` allocation, requiring it to be on the heap.

Either that or the escape analysis just isn't smart enough; taking a pointer to an internal component of an interface value seems like a bit of a stretch.

I'll have to disagree here.

Leaking resources in Rust is pretty trivial: create an Rc cycle with internal mutability. By contrast, in languages with a GC, cycles will be properly collected.

And there is nothing preventing GC languages from tying their non-memory resources to the lifetime of a value like Rust. See Python files, which are closed when the file handle is collected (ie. when all variables holding it go out of scope), and if that's not explicit enough, there's the "with" keyword to explicitly introduce a scope at the end of which the file is closed.

> Leaking resources in Rust is pretty trivial: create an Rc cycle with internal mutability.

It's trivial to do on purpose, but difficult to do accidentally.

> See Python files, which are closed when the file handle is collected (ie. when all variables holding it go out of scope)

That's a CPython implementation detail.

https://docs.python.org/3/reference/datamodel.html

> Do not depend on immediate finalization of objects when they become unreachable (so you should always close files explicitly).

In Rust, the default behavior when using resources like any other type is correct. You have to introduce a specific type to leak them.

In Python, you need to handle resources differently and introduce a language feature to not leak them.

That's the difference you're pointing out.

In Zig's case, you do what Rust/C++ do implicitly and create a table of function pointers

I think "packaging" here refers to the process of putting the silicon die in its plastic casing and connecting the die's pad to the case's pins, see https://en.wikipedia.org/wiki/Integrated_circuit_packaging

The author claims that mmap is exposed by glibc whereas memfd_create is not, so they reimplemented it with syscall, but looking at the man page, did they just forget to #define _GNU_SOURCE?

When I originally wrote this, it indeed was not

Ah, you're right, I didn't see it's a more recent addition.

in what way is unicode similar to html, docx, or a file format? the only features I can think of that are even remotely similar to what you're describing are emoji modifiers.

and no, this webpage is not result of "carefully cutting out the complicated stuff from Unicode". i'm pretty sure it's just the result of not supporting Unicode in any meaningful way.