what we can do with rust is beyond what we can imagine

May I throw in something about Rust (and any "modern" system languages, like Zig)?

The problem with these new languages is that they suffer from a lack of maturity.

I don't know if it's practical to rewrite the FreeBSD kernel just for their perks, like memory safety, but at the moment these languages require you to upgrade your compilers after X weeks. From each upgrade, they may sometimes throw compiler errors that require changes from parts of the stdlib API to a "better renamed" version of them. If you're dealing with massive code bases, these constant API renamings can be a huge and unnecessary pain. Another problem is their third-party library ecosystems. Many developers of popular libraries/modules would constantly change the APIs of their libraries because they always "feel the need to innovate" and would never come to a stability point. This ends up with both library and application developers to selectively pull specific versions of libraries. But this makes it worse when you depend on libraries that would pull in the same libraries repeatedly but with many different versions from each of them. This ends up leading to a more greater dependency hell than necessary. I don't know if the Rust compiler developers even stabilized the ABI of their compilers yet.

With regarding all of this, they are far from being "mature" and ready for production in mission critical sectors or businesses. Any kind of breakages would be unacceptable for them.
 
The signal to noise ratio here is indication for a reloction of this thread into a secondary resource transportation vessel. You have untill tomorrow to prove me wrong.
 
getopt said:
If this vessel is rolling gently in the Black Sea
Click to expand...
I don't think so. More likely is an exothermal size compaction process, also known as dumpster fire. Be careful not to be in the blast radius.
 
stratact said:
May I throw in something about Rust (and any "modern" system languages, like Zig)?

The problem with these new languages is that they suffer from a lack of maturity.

I don't know if it's practical to rewrite the FreeBSD kernel just for their perks, like memory safety, but at the moment these languages require you to upgrade your compilers after X weeks. From each upgrade, they may sometimes throw compiler errors that require changes from parts of the stdlib API to a "better renamed" version of them. If you're dealing with massive code bases, these constant API renamings can be a huge and unnecessary pain. Another problem is their third-party library ecosystems. Many developers of popular libraries/modules would constantly change the APIs of their libraries because they always "feel the need to innovate" and would never come to a stability point. This ends up with both library and application developers to selectively pull specific versions of libraries. But this makes it worse when you depend on libraries that would pull in the same libraries repeatedly but with many different versions from each of them. This ends up leading to a more greater dependency hell than necessary. I don't know if the Rust compiler developers even stabilized the ABI of their compilers yet.

With regarding all of this, they are far from being "mature" and ready for production in mission critical sectors or businesses. Any kind of breakages would be unacceptable for them.
Click to expand...
I like the point, but I think what's getting lost is that API != ABI. You can force the former to be identical, but the latter would get in the way.
 
You must log in or register to reply here.
Back
Top