After reading all that (ok skimming), he does mention nullable types, but doesn't go into them at all. What's wrong with having the option of defining if something can be null or not? This is how I understand nullable types, don't known about monads. You only have to check if it's null if you have defined that it can be null.
Seem to me that whether or not people will be asked to "come out of retirement" will completely depend on how good the LLM's will be in 20 years.
This seems to happen a lot in the discussions around LLM's. Some people discuss it like LLM's will not get any better, others discuss it as if LLM's will continue to get better forever. But only time will tell.
Diplomacy has been tried multiple times before, even with security guarantees from the usa. Still Putin invaded. There can not be lasting peace without actual guarantees (for which use is not even a trustworthy party anymore). Because Putin will rebuild and invade again as he did after the last time.
This is what Zelensky tried to explain to Vance before the discussion blew up.
The PAL (Platform Abstraction Layer I assume) is just the stdlib that is provided. The stdlib is not the same for all platforms, as can be seen in the documentation. A regex implementation is provided for all platforms, but is not quite the same on all platforms: https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.text/-r...
In shared code you can define interfaces that have to be implemented by any platform you use.
I would like to see that number as well, I actually expect it to be a lot more than a million.
Take 1000 times the clock rate, 4 cores, multiple instructions per clock instead of multiple clocks per instruction. Operations on 64 bits i.o 8 and the Z80 doesn't even have multiply or divide operators and would need to loop and add to do a multiplication/division. And then think about things like ARM SIMD instructions.
Yes, the upside of one language should be that you don't have to write the same stuff multiple times. But if you don't want the downside of having one common denominator holding you back, then you have to write some parts specifically for each platform. That is the option Kotlin gives you. And my point was that this doesn't necessarily mean it will hold the specific platforms back (which seemed to be your point).
There is nothing keeping them from not making some constructs not portable to certain platforms. Mostly they try to do this with standard language constructs (of course), but for example the 'dynamic' type is completely javascript specific.
This only goes for Valhala. The other examples seem to be java playing catch-up to Kotlin (Panama for Kotlin native and Loom for co-routines).
Last night a new version of the vera documentation was uploaded (https://github.com/commanderx16/x16-docs/blob/master/vera-mo...). It looks like the changes will allow for more memory, up to 1mb. Of which the last 64kb seem to be reserved for the registers, so max 960kb.
Constantly copying data to the VERA (chasing the beam/screen), seems unpractical. The 6502@8MHz can never move that much data.