Civet: A Superset of TypeScript

I was hoping for something more substantial. (such as list/object/monad/arrow comprehension)

I recognize the effort. The syntax is definitely not my flavor though, all examples in Civet looked less readable than the TS/JS equivalent.

The one feature that I liked was pattern matching, but I wouldn't use such a different syntax just for that.

What I would like the most from a TypeScript superset is additional runtime features, like being able to validate if an object matches a certain type, and a more comprehensive standard library. The first one got alleviated a lot by Zod becoming a thing, and LLMs integrated into your editor being able to generate the equivalent validation code. The second one seems like it will never become part of the language itself, and it's up to runtimes to provide batteries-included APIs if they want to. Deno and Bun are definitely more inclined that way.

The devs seem pretty happy with it though, so I hope they continue hacking and building the language that they would like to use. :)

It's transpilers all the way down...

i used to write ruby, this reminds me of a js ruby

it was about a decade ago and i liked ruby for the implicit nature and minimal looking code— without the curly braces and shorthand notation whenever possible

return true unless false

that line is roughly why i favor curly braces and javascript’s control flow

lines like return true unless false are so easy to write in the moment, but so much to reason about it post.

in all, i’m in favor of systems that bring future code to today’s code, like polyfilling tc39, but probably won’t bet against core javascript semantics again, like other coffee-script adjacent comments, which was the dominant flavor of js for rubyists at the peak.

What a mess.

    switch x
      0
        console.log("zero")
      /^\s+$/
        console.log("whitespace")
      [{type: "text", content}, ...rest]
        console.log("leading text", content)

Yes, looks very cool, but nobody should ever write code like this, especially not in strictly typed code. And it is extremely rare you need to do similar pattern matching. For the object case, you would want to define interfaces and type guards in TypeScript anyway. This feels like poor man's pattern matching compared to Python and Rust.

    items = for item of items
      if item.length
        item.toUpperCase()
      else
        ""

If JavaScript has always required statements to end in semicolon, I'm 100% for this. But it's not. So "standalone expression" as return value will only cause chaos.