4 ms·
The case for a modern language (part 1)
- Someone 5y agoSo far, that’s a case for a better library, not a better language.
- cbarrick 5y agoFundamentally, the argument is that error handling in C is bad. That's both a language and a library problem.
- Someone 5y agoI don’t see that in this post. errno is a library (mis)feature. Rust’s if let Ok(my_number: u8) = &my_number_string.parse() { assert_eq!(my_number, 42); } could, in C, look like this: if(parseInt(my_number_string, &my_number)) { assert(my_number == 42); } That’s fairly similar, and the article doesn’t claim Rust is bad, or that C is bad because it doesn’t support multiple return values or restructuring (which could be used in place of it to make a function returning a struct look as if returns multiple values) (aside: u8 is not the type I would have chosen in that Rust example)
- duped 5y agoThe semantics are very different, even if the syntactic results are superficially similar. In Rust you cannot retrieve the value on success without explicitly handling the error - that's forbidden by the type system. Additionally you can't have an unitialized error result, or force the callee to check the argument for null. I think the example is pretty weak, because the difference isn't that meaningful in an isolated case. Consider something like parsing an HTTP request - it is difficult to even write the toy example without handling the major error cases. The result is a robust program by default.
- petmon 5y agoRust sometimes throws away errors when they would be awkward to handle - close() in Drop and println!() are important examples. A Hello World with a closed stdout will correctly fail in C but "succeed" in Rust because it ignores EBADF. https://github.com/rust-lang/rfcs/pull/1014 https://github.com/rust-lang/rfcs/pull/1014
- tabtab 5y agoI've seen good productivity from domain-specific languages. One-size-fits-all languages end up too convoluted in my opinion (Java, C#, cough). Enterprise/web-scale has different needs than mom-and-pop, and systems software has different needs than CRUD/biz software. One size doesn't really fit all. Thus, what looks most promising to me is a syntax convention flexible enough to bend into a wide variety of languages, static and dynamic. "Moth" is one attempt. It's influenced by the flexibility of XML, and is kind of LINQ-esque. Kits can then evolve that allow component/feature mix-and-matching to build domain-specific languages. One doesn't have to build a parser from scratch, similar to how most major language libraries come with an XML parser. https://www.reddit.com/r/ProgrammingLanguages/comments/ky22dx/simplified_take_on_moth_colonfree/ https://www.reddit.com/r/ProgrammingLanguages/comments/ky22d... https://www.reddit.com/r/compsci/comments/brrzad/universal_programming_language_syntax_proposal/ https://www.reddit.com/r/compsci/comments/brrzad/universal_p... One thing Moth sacrifices to get simplicity is tossing of "Fortran style" infix, such as "x = a + b * c". The Moth equivalent could be something like x=plus(a, times(b,c)); or x=a.plus.b.times.c; In practice, I don't really need such in domains I know. If you do a lot of math, then Moth is probably not for you. Can't make everybody happy, just 2/3, I mean 2.div.3 :-)