this post was submitted on 21 Oct 2024
199 points (99.0% liked)
Programming
17416 readers
80 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Null safety is orders of magnitude simpler than memory safety. Kotlin is a null safe language by default. Java is infamously not. Anyone who has worked on a mixed-language Kotlin project can tell you how quickly null safety becomes a pain once guarantees break down - and that's in a language where these issues are flagged instantly and you can "fix" the problem in a couple of characters! Mixed memory safe/unsafe codebases would be a nightmare in comparison.
Also, C++'s ecosystem consists of deeply entrenched libraries with ancient codebases. Safe C++ might be useful in a decade or two if library maintainers could be pushed to make the switch (good luck with that, if it's half as much of a paradigm shift as Rust), but by then there will probably be multiple competing language features that claim to solve the same problem. It's the C++ Way™.
As much legacy code as has been written in C++, I'd think a total rewrite might be better ironically, in terms of passing on important institutional knowledge, to the extent large-scale production codebases are concerned. Attacking it bit by bit (pun not intended) might even take longer than just ripping things up and starting anew.