4 ms·
Given that they mention SQL more than other things, and stress SoA and memory intensive applications, I think this makes more sense than it would otherwise
by henrydark 4y ago
Given that they mention SQL more than other things, and stress SoA and memory intensive applications, I think this makes more sense than it would otherwise
- colonwqbang 4y agoSQL null is not like the null of programming languages, it behaves more like "unknown" than "blank". For instance, null != null. Arithmetic on null values is also well-defined so that 1 + null = null. I'm not convinced that implicit nullability is a good idea, either in SQL or in newly designed languages. I don't see the connection between implicit nullability and SoA. If you have a link to some example, that would be interesting to read.
- henrydark 4y agoI'm not convinced so either, just that it doesn't not make sense. As for SoA, I'm thinking of two relatively new formats and applications that have default nullable types, are SoA, and are specifically targeting memory intensive applications: apache arrow and duckdb, both seeing some success and well deserved hype
- kibwen 4y agoEven if you want to allow nullability, you can make it both explicit and opt-in rather than implicit and opt-out.
- runeks 4y agoGo on...
- colonwqbang 4y agoThe subject has been discussed to death here on HN and in other places. If you're unfamiliar, this talk by Hoare (the inventor of implicit nullability) is as good a place to start as any: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/ https://www.infoq.com/presentations/Null-References-The-Bill...