malkia

Btw, there is HOMM Olden Era (google it) and it's great!

How would this work in wasm land? It's a bit badly put question, because this leaves out a lot of context - wasm - where, how, what implementation, but from my simple understanding most of the wasm is 32-bit running in a browser. For this to work, it'll need true virtual 64-bit (or 48-bit) address space. The host, being the browser, or something else, may provide it, but....

If the host needs to load several of these .wasm, compiled with goose, then it'll have to run them in separate (browser) instances too (or maybe that's how wasm works by default - not sure).

It just got me thinking - the languge is prepared to translate into javascript workers, because it's really single threaded by nature with communication between threads (or put in the dart languages term "isolates"), which makes them perfect for the browser, now the only question is the memory layout.

For Windows, these N data stacks would probably just RESERVE the address space, and as it grows COMMIT it, right?

I guess there would be some penalty to be paid here for smaller pages, but being mostly contigous might also help some.

That to be said, such language seems to require 64-bit virtual address space in order to function reasonably, right?

Also a .dll written in it might not be the best suited, for example if loaded in the middle of fragmented virtual address space it may need to find itself hard to allocate N contigious data stacks (do they absolutely have to be contiguous, what if they are simply ropes or deques or connected chunks ... obviously if some data structure requires to be contigous that would be a problem, but maybe this can be expressed somehow.... or maybe I'm overthinking here).

Super excited about this!

I was going to ask the same, but I guess it may also not be good fit for some kernel programming, given that the heap is shared along with other code.

But sounds great for 64-bit user space, with enough (48-bit, or more) virtual addressing available. Obviously one can hit some snags if for some reason quite large allocations has to be done, but maybe one has to rethink that too.

I'm starting to fall in love with this approach ;)

He is not "selling" anything. I don't see a price, quite the opposite - it's on the user to evaluate it's points, not on the "seller" (that he is not). Obviously if this becomes paid, or paid through support product this would be one of the first points of the table - "what are the limitations, what should we be aware of sorts".

Probably kernel code, or cases where allocation randomization is important. Seems like with goose you may end up executing more deterministically (but still it can randomize where these N data stacks start), but because it's single threaded workers (in essence), all data construction would follow the same pattern, hence an attacker (something snooping your memory) would know easier where things would be.

and what stops AI from "accidentally" writing code with such bugs?

I read the "imagination" as prelude to "Jevon's paradox" for AI. It might be that we simply don't know yet what using AI fully means, and where else it can be used and how. Electricity was initially just for lighting, but now it's everywhere...

NVIDIA and layoffs - Are you sure? I mean there are probably some, but from what I'm hearing from friends working there - it's not typical....

Reminds of what happened in Iceland and their bank/financial restruction since 2008 and how humans had to understand again how finance works.

My son has developed this with Claude as lighter version of Spotify's own player. It requires paid spotify accounts and written in Rust + Tauri. Completely LLM coded.

It says for Windows only, but I think he works on supporting Linux / OSX too.

This is like piano makers being really bad at playing. I mean it does not relate directly.