3 ms·
> My naive assumption would be that pure code could be adapted for a 1000-core machine with only changes to the compiler and runtime environment. Perhaps for u
by geon 10y ago
> My naive assumption would be that pure code could be adapted for a 1000-core machine with only changes to the compiler and runtime environment.
Perhaps for use cases where current, garbage collected languages are suitable.
For areas where (today) asm/c/c++/rust is a must, you would need a functional language that can give you guarantees about garbage generation, so you can be sure you won't need to collect garbage, at least in specific areas of the code.
Perhaps a stream-oriented language would be suitable? The runtime could spin up more cores as needed depending on back-pressure.
- marcosdumay 10y ago> For areas where (today) asm/c/c++/rust is a must, you would need a functional language that can give you guarantees about garbage generation That's the entire point of the "purity" idea. Pure FP languages give you very strict guarantees about garbage generation. The only question is if everyday code has enough pure code to fill a 1000 cores processor.
- geon 10y ago> Pure FP languages give you very strict guarantees about garbage generation I thought the only guarantee is they don't have side effects.
- marcosdumay 10y agoThey are immutable, there's no implicit cross-dependency between data upper on the calling hierarchy, and any shared data can be recalculated as many times as needed. That's what I get from the top of my mind. There are probably more features that will help. Purity is a very strict guarantee.