inventing a programming language and realising you made mistakes must be a pain. can't fix them without breaking old code.
Conversation
Notices
-
Embed this notice
Thorwegian ❄️ (thor@berserker.town)'s status on Sunday, 15-Oct-2023 21:16:02 JST Thorwegian ❄️ -
Embed this notice
翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Sunday, 15-Oct-2023 21:16:00 JST 翠星石 @thor Why would you make another programming language when GNU C exists?
At most one would want to implement more GNU C extensions really.
If one made the mistake of designing an inferior language anyway, the mistake should just be fixed and the breaking change noted, so mistake is gone and doesn't keep haunting you - developers can fix their broken code just fine no matter the seething. -
Embed this notice
翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Sunday, 15-Oct-2023 21:30:25 JST 翠星石 @moffintosh That's an incredible amount of complexity and attack surface, resulting it being impossible to write a non-trivial, secure program in that language.
I don't really get the allure of static linking 1000 libraries, all full of vulnerabilities mainly due to the complexity of the language.
Objects were a mistake and are incredibly slow (the CPU intel made with hardware accelerated OOP was very slow) - you either want a field of x bytes, a pointer or a struct, although synthetic sugar around the former are nice. -
Embed this notice
Moffin'tosh (moffintosh@berserker.town)'s status on Sunday, 15-Oct-2023 21:30:27 JST Moffin'tosh @Suiseiseki @thor RAII + package manager + immutability by default + objects + sum values > C
-
Embed this notice
翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Sunday, 15-Oct-2023 22:08:36 JST 翠星石 @moffintosh >if manual resource management is better, while is in fact worse.
There's always the option to only use stack memory in C and the compiler does manage that for you automatically.
There's also dynamic memory manager libraries, but why would you want that?
Yes, proprietary software developers are unable to write secure programs, as they always write bloated messes that are impossible to secure, who would have though?
If chrome was written in rust, it'd have more bugs, as rust requires more lines to do most things than in sepples and don't forget that more code == more bugs - maybe less memory bugs, but more of other kinds of bugs with the same security consequences.
>assume that somehow you'll be able to correctly reimplement the functionality you need
I don't need to, based GNU hackers have already implemented everything I need in GNU libraries and I just need to call into it.
Those libraries are well debugged and have an error rate far below the usual - sure mistakes are sometimes made, but the bug soon is fixed and then it's a matter of updating the library in the package manager and the issue is fixed, all thanks to dynamic linking.
When there's a bug in a rust library, you don't get the bugfix in any software until the package maintainer updates the statically linked version - which will sure take a while with say 200 packages than depend on a vulnerable library (sure rust has dynamic linking, but it doesn't seem to be used often). -
Embed this notice
Moffin'tosh (moffintosh@berserker.town)'s status on Sunday, 15-Oct-2023 22:08:37 JST Moffin'tosh That's an incredible amount of complexity and attack surface, resulting it being impossible to write a non-trivial, secure program in that language.
As if manual resource management is better, while is in fact worse.
https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues
https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues
https://developer.okta.com/blog/2022/03/18/programming-security-and-why-rust#why-does-it-matterI don't really get the allure of static linking 1000 libraries, all full of vulnerabilities mainly due to the complexity of the language.
You assume that somehow you'll be able to correctly reimplement the functionality you need better than projects which dedicate their all to produce sound code. Prove it.
Also, why don't you also reimplement function calls while you're at it?Objects were a mistake and are incredibly slow (the CPU intel made with hardware accelerated OOP was very slow)
That ain't what all objects are. That's only a kind of object, ie a reference object with dynamic dispatch
-
Embed this notice