HN user

rnentjes

57 karma
Posts0
Comments24
View on HN
No posts found.

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.

To me this sounds like a solved problem, for example like how it's done in kotlin: https://kotlinlang.org/docs/null-safety.html#nullable-types-...

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.

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).

With the 1.1.4 version they have added a dead code eliminator which really helps with the resulting javascript length. In the example above the resulting javascript file is 440 KB (zipped 113 KB). Which is not bad if you take into account that the included libraries are more than 2MB (the standard library and static html builders being the biggest ones).

I haven't measured runtime performance, but I haven't noticed anything being slower than plain javascript yet. A clean compile in this example takes ~8 second, incremental compiles takes 3-4 seconds.

The jvm doesn't play a role when targeting javascript so I am not sure what you mean with JVM variables and I don't know much about GWT. But you can debug the resulting javascript from intellij and step through the kotlin sources if you want.

I don't know how easy it is to integrate with react.