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.
To run well, it doesn't just need wasm64 (which I worked on btw!) but it also needs the wasm64 memory to not commit until touched, or have a feature that allows Goose to do that. That and larger total memory. I pushed for that a while ago but I don't think it is possible today.
Sadly these memories are accessed thru a constant in the load/store instructions, and Goose would need this to be dynamic (since you can have code that processes pointers coming from multiple different stacks).
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).
Yup that's how it works. Goose runs great on Windows.
Yes, it be very tight to make work on 32-bit.
DLLs definitely possible, most Goose programs only use a fraction of the 64-bit address space.
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.
"Threads that share nothing. A worker is compiled as a separate program with its own memory, and flat values cross typed queues as a memcpy. Data races, locks, atomics and memory orderings do not exist in the language."
Even if you could be trusted to do that, we still need languages like Rust and tools like ASAN and Valgrind. Trust but verify. Trust alone is not enough.
The compiler. That’s the whole point here. Type systems can prove the absence of entire classes of bugs, at compile time. If AI identifies bugs in type systems that can be corrected, then all future programs benefit, including those written by AI.
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...
reply