Re:The search for easier safe systems programming
by ctxcode on Wednesday May 08, 2024 @02:33PM
(#40301450)
If you change the language, you have no ecosystem. You cant say, it has a big ecosystem "if everyone ports their code". By that logic all languages have a big ecosystem. Anyhow. JS has much unexpected strange behaviour, i really would not recommend such a language in 2024.
Re:The search for easier safe systems programming
by prmph on Wednesday May 08, 2024 @04:55PM
(#40302638)
So let's take out the "unexpected strange behavior", that's what all I'm saying
Re:The search for easier safe systems programming
by 63stack on Wednesday May 08, 2024 @08:27PM
(#40304075)
With so many sweeping changes you could take any currently popular scripting language as a base.
Re:The search for easier safe systems programming
by knighthack on Thursday May 09, 2024 @06:24AM
(#40306771)
> It has a huge ecosystem; it shouldn't be hard to port many high-quality packages to a similar language
...Spoken like a person who's never coded anything meaningful or serious, if you can't even gauge the complexity and man-hours needed to create (much less port) high-quality packages between programming languages.
Re:The search for easier safe systems programming
by prmph on Thursday May 09, 2024 @06:43AM
(#40306861)
No need for that flippant response. You do not know the work I've done, so don't assume I don't know what I'm talking about.
Talking about "man-hours" tells me you think of software engineering like an assembly line, which it is not.
There are whole lot of factors that might influence the time needed for such porting; the keyword in my comment is "similar". If the new language is a superset of the original language, minus a few warts, I'm not sure what should take so much time. For one thing, the architectural design of the packages (which probably took most of the original effort) remains the same.
- It has simple, straightforward, and pleasant syntax/semantics. Except for a few tweaks here and there, there is no need to re-invent the wheel here.
- It is pretty functional, all that's needed is to add everything-is-an-expression
- It supports multiple paradigms (functional, imperative, OOP)
- Since it has no types currently, a _modern_ type system can be feasibly added, supporting concepts like result/error instead of exceptions, maybe/option, pattern matching, etc.
- It has easy-to-reason about async features
- It has a huge ecosystem; it shouldn't be hard to port many high-quality packages to a similar language
Now, the lower-level features are another matter entirely, but it shouldn't be too difficult to retrofit what we want, like multi-threading (maybe building on top of workers), utf-8 strings, and so on.