Live data from Hacker News

Civet: A Superset of TypeScript

civet.dev

61–70 of 237 posts

Re: Civet: A Superset of TypeScript

#61

Earlier quoted context omitted.

> CoffeeScript made writing and reading things much easier My point is that it kinda didn't. It looked prettier on the surface, but didn't actually solve any of the deeper problems of writing JavaScript. To write CoffeeScript you had to still know JavaScript and all its oddities. TypeScript solved those problems, and that's why it has taken off and had a meteoric rise to the point that it's practically synonymous wit…

Coffeescript had some great features: classes, array comprehensions, default parameter values, arrow functions, optional chaining. Many of these eventually made it to ecmascript. And then it ruined us with implicit returns, optional parentheses and brackets, and the isnt vs is not fiasco. I worked a lot with Python and coffeescript at the same time back in the day. In Python you mess up your whitespace and 95% of the…

In case you wondered how Civet compared to CoffeeScript in these regards:

* `is not` is the textual equivalent of `!==`. You can use `isnt` if you turn on the feature explicitly (or even the weird CoffeeScript `is not` behavior if you want it, mainly for legacy code)

* Implicit returns are turned on by default. They are really useful, most of the time, and don't get in the way much if you use `void` return annotations (which turns them off). But if you don't like them, you can turn them off globally with a compiler flag.

* Civet's compiler is built on very different technology from CoffeeScript's (PEG parsing, similar to Python), and it is much more strict about indentation. None of those weird bugs anymore.

* We do have implicit parentheses and braces and such, but you're free to use explicit parentheses and braces as you like. We encourage people to rename their .ts files into .civet (which mostly just works without any converison) and just embrace the features/syntax they like.

Re: Civet: A Superset of TypeScript

#63

Civet. Kopi luwak coffee. It's CoffeeScript. I wrote a bunch of CoffeeScript back in the day, and everyone I've spoken to about it feels the same, that it was a bad idea in hindsight, and a language dead end. The language was only syntactic sugar, and by not bringing anything else to the table, was unconvincing for ports and support in other ecosystems. It now seems that most codebases have been decaffeinated though.…

CoffeeScript was great except for a few fatal mistakes. The biggest was implicit variable declarations, which meant that to write maintainable code, you had to reintroduce explicit declarations via iifes. Otherwise, you’d risk a future code change introducing shadowing which would have consequences that were super painful to debug. The other big one, which unfortunately Civet seems to be doing too, is implicit return…

You can also turn off implicit returns in Civet if you don't like them. They also work well with TypeScript annotations: if you annotate a return value of `void`, then there's no implicit return.

I agree it can be easy to make and throw away big arrays if you're not aware of what's going on. But it can also save a lot of time. For loops as arrays are super useful, integrating the equivalent of "map" into the language itself. We also recently added generator versions (for*). JSX is a nice example where for loops as expressions and implicit return are powerful; see e.g. https://civet.dev/reference#code-children

Re: Civet: A Superset of TypeScript

#64
post #62

What's the compilation time impact of that?

Good question! I don't have hard numbers, but for larger files, I find that it can take on the order of a second to compile. It's still fast enough to get real-time feedback from TypeScript in VSCode, but it could definitely be faster. There's lots of optimization left to do; for now, we're focusing on features over speed, but we'll get to speed as well. (I am an algorithms guy after all!)

Re: Civet: A Superset of TypeScript

#65

The JSX seems compelling. You are already doing a non-standard HTML embedding HTML into javascript, why not do it better? https://civet.dev/reference#jsx I am not convinced that all the syntax nicety is necessary, but improved pattern matching is often a great thing. On the other hand their examples seem to be to pattern match on highly dynamic types, which you can avoid 95% of the time with TypeScript.

JSX has a spec. This thing they're doing... I don't know what it is, but it ain't JSX.

The JSX spec hasn't changed for almost 10 years, and I'd guess there will never be a JSX 2.0. On the other hand, ideas for a better JSX are plentiful (check out the issues on the JSX repo, for example). If the spec never changes, how can we improve the JSX experience? Transpilation!

Civet's futuristic JSX compiles to actual spec-compliant JSX, to it's compatible with all forms of JSX, including React, Solid, etc. We'd like to support other DSLs like Astro and Svelte as well.

Re: Civet: A Superset of TypeScript

#66

I know this hasn't been updated, and I know it's a fork of CoffeeScript, but https://livescript.net/ has had a lot of the "magic" syntax here for quite a while.

Yes, Civet has taken a lot of syntactic inspiration from LiveScript. At this point, I think we have most of the good features, but we might be missing some. Let us know what you think!

The big difference, of course, is that Civet fully supports TypeScript, and is up-to-date with the latest JavaScript and TypeScript features.

Re: Civet: A Superset of TypeScript

#67

Earlier quoted context omitted.

CoffeeScript was great except for a few fatal mistakes. The biggest was implicit variable declarations, which meant that to write maintainable code, you had to reintroduce explicit declarations via iifes. Otherwise, you’d risk a future code change introducing shadowing which would have consequences that were super painful to debug. The other big one, which unfortunately Civet seems to be doing too, is implicit return…

You can also turn off implicit returns in Civet if you don't like them. They also work well with TypeScript annotations: if you annotate a return value of `void`, then there's no implicit return. I agree it can be easy to make and throw away big arrays if you're not aware of what's going on. But it can also save a lot of time. For loops as arrays are super useful, integrating the equivalent of "map" into the language…

Yeah those examples are compelling.

What might work well is a lint rule to error if a loop expression ends an actual function declaration (i.e. not an inline callback), and the function doesn’t explicitly define a return type. I think that catches almost every bad case, aside from the odd memory leak in really unusual edge cases.

Re: Civet: A Superset of TypeScript

#68
Things I like:

- Everything is an expression

- Async imports just work without thought

- Yaml-like object structuring

- JSX improvements

- Multi-line string literals without leading whitespace

Things I’m on the fence about:

- Pipe operators (better than .pipe I guess?)

- Pattern matching (love it in Scala and swift, but this doesn’t feel done right)

Things I loathe:

- Signifiant whitespace (removing brackets in general)

- Optional parentheses in function calls (a foot-gun in VB and Ruby)

- Splats in the middle of function definitions (I can’t imagine how this works with overload definitions)

Re: Civet: A Superset of TypeScript

#69
Related:

CoffeeScript for TypeScript - https://news.ycombinator.com/item?id=34962782 - Feb 2023 (135 comments)

Show HN: Civet the CoffeeScript of TypeScript v0.4.20 - https://news.ycombinator.com/item?id=33834312 - Dec 2022 (3 comments)

Civet: The CoffeeScript of TypeScript - https://news.ycombinator.com/item?id=33323574 - Oct 2022 (17 comments)

The CoffeeScript of TypeScript - https://news.ycombinator.com/item?id=33198931 - Oct 2022 (2 comments)

Re: Civet: A Superset of TypeScript

#70
post #5

That looks interesting but imo the syntax is too terse. Coming from Rust and Golang I very much appreciate the use of sigils and syntax sugar in moderation but especially the pipe operators look like they could lead to hard to debug code very easily.

[dead]
Post reply on HN