The case for a modern language (part 1) | Hacker News Reader

The case for a modern language (part 1)

jeang3nie.codeberg.page

16 pointskristoff_it6 comments

I'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/ky22d...

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 :-)

So far, that’s a case for a better library, not a better language.

Fundamentally, the argument is that error handling in C is bad. That's both a language and a library problem.

I 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)

The 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.

Rust 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

Reply on news.ycombinator.com