4 ms·

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

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. Civet looks like it adds a little more, but the things that aren't just syntactic sugar are just a grab bag of TC39 proposals. I'm a big fan of language proposals in general, and having a language that adds all of them for research purposes seems like a nice thing to have. Haskell did this well with GHC language options. Is this a research language though? It seems not. What's the benefit over Typescript? A few less characters? Faster TC39 proposal integrations? What happens if a proposal is rejected, does it get removed from Civet? What's the cost? What happens as Typescript and Civet diverge? What if the TS tooling doesn't support Civet features?

lgas 2y ago
I think everyone mostly agrees that CoffeeScript was a dead end, but I think it drove at lot of innovation at the time. Hopefully Civet can do the same, even if it ends up being another dead end.
- bhouston 2y ago
  CoffeScript was really good at driving innovation in JavaScript. The arrow operator, string literals, and for...in/for...of seemed to be driven specifically from CoffeeScript's innovations.
  - int_19h 2y ago
    Almost all of these were features of other mainstream PLs at the time, so it's questionable whether JS really borrowed them from CS or directly from those others. Especially since the latter is clearly true for some other features such as async/await.
- danpalmer 2y ago
  What makes Civet more likely to drive that innovation than TC39 proposals themselves?
  - Yahivin 2y ago
    We ship
reissbaker 2y ago
Considering it's not just a grab-bag of TC39 proposals (e.g. removing braces), I suspect rejected TC39 proposals will just... linger. I agree a research language feels potentially useful — and in fact that's what CoffeeScript's real legacy is (arrow functions, splats, destructuring assignments, and ES6 classes among others are direct ports of CoffeeScript syntax features, and many of the original JS class proposals that CoffeeScript-style classes replaced were quite bad) — but I'd be similarly leery of using this to ship much.
arp242 2y ago
> 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 I don't think it was a bad idea in hindsight. JS of the era was a pain to use; CoffeeScript made writing and reading things much easier, which is the reason it took off. Since then things changed and many "CoffeeScript features" are now "JavaScript features". Only with knowledge of that future would it be a "bad idea", but it was absolutely not clear that was going to happen back in 2010 and in alternative universes we're all writing CoffeeScript today. I also think CoffeeScript was probably helpful in getting some of these features adopted in the first place. The same applies to TypeScript – maybe typing will be added to JavaScript, and TypeScript will become redundant – I think there was some proposal and who knows what will happen. In 15 years we can say the same about TypeScript, but that doesn't mean TypeScript wasn't useful today, with the current state of JavaScript and uncertainty what the future may or may not bring.
- danpalmer 2y ago
  > 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 with JavaScript. > I also think CoffeeScript was probably helpful in getting some of these features adopted in the first place. This may be true, but if so that suggests a benefit as a research language not a production language.
  - dgoldstein0 2y ago
    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 time it's an indentation error. In coffeescript it's a valid program that means something completely different than what you intended. Combined with the optional punctuation, which the community encouraged leaning into, it was far too easy to write ambiguous code that you and the compiler would come to different interpretations of.
emmanueloga_ 2y ago
CoffeeScript was not only a great idea but also successful beyond its adoption. It influenced and inspired many features that JavaScript later incorporated, such as arrow functions and destructuring assignments. Over time, JavaScript evolved to the point where the few quality of life improvements offered by CoffeeScript no longer justified learning an entirely new syntax.
- MajimasEyepatch 2y ago
  I sometimes wonder if Kotlin will end up on the same trajectory. Java has added a lot of pretty good features since Kotlin first came on the scene, and the gap has narrowed considerably. The one thing enormous thing that Kotlin has that cannot be replicated easily in Java is null safety. But lately, most of the other features in Kotlin either make me long for something more powerful like Scala or shrug and just fall back to Java. Admittedly, I don't do much Android development, and that was a big driver of Kotlin's adoption early on. So maybe it has more of a foothold there than on the server.
  - pjmlp 2y ago
    It will, because that is the fate of every guest language since the dawn of times. The "systems" language of the platform, evolves with the platform, is designed alongside the platform. The guest languages might be better than the platform's "systems" language, on the day of the release, eventually it is bound to diverge with its own library ecosystem built on top (because "ugh" we're not using the platform libraries directly), its own IDE tooling, its additional debugging layer due to platform interop, its own abstractions not native to the platform,..... Eventually it naturally diverges as the platform takes incompatible decisions,... C and C++ on UNIX, JavaScript and anything compiles to JS, Java vs Groovy/Scala/Clojure/Kotlin/jTCL/Beanshell/jython/...., C# vs VB.NET/F#/C++/CLI/IronPython/IronRuby,... The guest languages that are survive, are those that move beyond the platform that gave them birth and create a platform of their own. In Kotlin's case that is definitely Android, because Android team is doing everything at their disposal to make Java a 2nd class language on Android, rewriting Jetpack libraries in Kotlin, requiring Kotlin for Compose, showing off Kotlin code samples against Java 8 examples(!), I bet they only starting updating Java support, because Android was starting to lose too many Java libraries as the Java ecosystem adopts new versions. Still, Android 15 being released one year later from Java 21 LTS, is still catching up with Java 17 LTS, introduced in Android 13 and not yet fully implemented, kind of proves the point of them not being in a hurry for proper Java support on the platform.
edemaine 2y ago
One of the Civet devs here. To me, the main benefit of Civet is the ability to rapidly add useful features to the language, while preserving all the benefits of TS (tooling, etc.). We're constantly coming up with ideas — from TC39 proposals, other languages, or general brainstorming — and implementing them quickly. For example, we recently added pattern matching when catching exceptions, which took just a couple of hours of development; or Python-style from ... import ... for better autocompletion of imports. All of these features are optional; you can write well-formed TypeScript as usual, and just choose to use the features you think are worth the learning curve for readers. The plugins for VSCode, Vite, esbuild, Webpack, eslint, etc. aren't perfect, but they let Civet code enjoy most of the tooling out there. I personally use Civet for all my coding projects, as I'm devoted to it continuing to flourish. But if you ever don't like what Civet is offering you, you can eject at any time by replacing your code with the TypeScript compilation, which we make as close as we can to your input. What happens if a TC39 proposal is rejected? That's actually the good case for us, because it means we can keep the feature as is. Civet already transpiles all features to TypeScript, so they can live here forever if we think they're good. The trickier part is when Java/TypeScript changes in a way that's incompatible with Civet. Then we plan to change Civet to match Java/TypeScript, so that we don't diverge (though compiler flags allow us to also support the older form with explicit opt-in if we think it's worth doing so). JavaScript and TypeScript move slow. Largely that's a good thing; they're a stable foundation, and we don't want to mess them up. But it's also exciting to be on the bleeding edge, explore new ideas, and obtain new features as quickly as we can design them, instead of waiting a decade. Many features are also too niche / add to much complexity for the general JavaScript language, but they're still fair game for languages that transpile to JavaScript. See also the recent JS0 vs. JSSugar discussion.
- lifthrasiir 2y ago
  I think you need to drop or at least weaken an inspiration from CoffeeScript if that's a goal, otherwise everyone will immediately draw a connection to that and overlook any other aspect of Civet. (I personally hate CoffeeScript especially for its indentation and that contributed to my initial reaction.) You can't solve this problem with simply supporting two radically different coding styles---the front page seems to prefer one over another anyway.
mistercow 2y ago
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 combined with “everything is an expression”. You can have one of those, but not both. With both, it’s far too easy to write loops intended to be statements, and which accidentally turn into gigantic multi-dimensional array returns which can’t easily be optimized out by the compiler. Fortunately, this would be only mildly inconvenient to work around with a lint rule that forces explicit return in all functions.
- edemaine 2y ago
  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 https://civet.dev/reference#code-children
  - mistercow 2y ago
    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.
- scotty79 2y ago
  You can have shadowing with explicitly declared variables. And there are languages that allow that, Rust to name one and I love that I can do that every time I use it.
Myrmornis 2y ago
That's a really mean / uncharitable take. As others have pointed out, coffeescript did a great job of moving the language in a good direction, and that's presumably exactly what's intended here.
Yahivin 2y ago
Something interesting I've found while designing Civet is that TypeScript actually mitigates in a lot of the downsides of CoffeeScript. Types help quite a bit with implicit returns so you don't accidentally return an iteration results array from a void function. They also help reduce the downsides of terse syntax, just hover over things in the IDE and see what they are. Missed a step in a pipeline? The IDE will warn you if there's a mismatch.
acjohnson55 2y ago
CoffeeScript was great. It was vastly more pleasant to code in than ES5-era JS. Once ES6 came out, we simply migrated to it and moved on.
- scotty79 2y ago
  I still use CS for prototyping. It's easy to write and what's most important it's easy to read due to lack of visual clutter of JS. Once I have something decent I just take JS output and annotate it with types and work on it further debugging and optimizing.
usrusr 2y ago
> What's the benefit over Typescript? A few less characters? Faster TC39 proposal integrations? Getting hands on experience with those proposals could be an argument, learning how they feel, learning how their availability changes the way people write code. Could this be called a research language? Sure, but that categorization would certainly influence the outcome of the observation. I'm not disagreeing with any of your points though. Perhaps some mitigation could be provided by making their equivalent of decaffeinization a true first class citizen, intended to be run whenever a proposal gets rejected (or implicitly rejected by the language taking a different direction). This would have to be fine grained, and the language/tool would have to make "rolling preview of whatever proposals are currently in consideration" the code of its identity, not any particular set of language features.
mirekrusin 2y ago
CoffeeScript was very successful, the main win was that it could become irrelevant because so many constructs were adopted upstream.
scotty79 2y ago
It was a wonderful idea that got 90% assimilated by the underlying language thus becoming successfully obsolete.
root_axis 2y ago
CoffeeScript was amazing. It was only a dead-end because flow and subsequently typescript made an offer the ecosystem couldn't refuse. Unfortunately, I doubt that Civet will have much future momentum because even though typescript is the state of the art for front-end dev, it's a much less stable foundation to build on top of than ES was for CoffeeScript.

lgas 2y ago

I think everyone mostly agrees that CoffeeScript was a dead end, but I think it drove at lot of innovation at the time. Hopefully Civet can do the same, even if it ends up being another dead end.

bhouston 2y ago
CoffeScript was really good at driving innovation in JavaScript. The arrow operator, string literals, and for...in/for...of seemed to be driven specifically from CoffeeScript's innovations.
- int_19h 2y ago
  Almost all of these were features of other mainstream PLs at the time, so it's questionable whether JS really borrowed them from CS or directly from those others. Especially since the latter is clearly true for some other features such as async/await.
danpalmer 2y ago
What makes Civet more likely to drive that innovation than TC39 proposals themselves?
- Yahivin 2y ago
  We ship

reissbaker 2y ago

Considering it's not just a grab-bag of TC39 proposals (e.g. removing braces), I suspect rejected TC39 proposals will just... linger. I agree a research language feels potentially useful — and in fact that's what CoffeeScript's real legacy is (arrow functions, splats, destructuring assignments, and ES6 classes among others are direct ports of CoffeeScript syntax features, and many of the original JS class proposals that CoffeeScript-style classes replaced were quite bad) — but I'd be similarly leery of using this to ship much.

arp242 2y ago

> 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 I don't think it was a bad idea in hindsight. JS of the era was a pain to use; CoffeeScript made writing and reading things much easier, which is the reason it took off. Since then things changed and many "CoffeeScript features" are now "JavaScript features". Only with knowledge of that future would it be a "bad idea", but it was absolutely not clear that was going to happen back in 2010 and in alternative universes we're all writing CoffeeScript today. I also think CoffeeScript was probably helpful in getting some of these features adopted in the first place. The same applies to TypeScript – maybe typing will be added to JavaScript, and TypeScript will become redundant – I think there was some proposal and who knows what will happen. In 15 years we can say the same about TypeScript, but that doesn't mean TypeScript wasn't useful today, with the current state of JavaScript and uncertainty what the future may or may not bring.

danpalmer 2y ago
> 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 with JavaScript. > I also think CoffeeScript was probably helpful in getting some of these features adopted in the first place. This may be true, but if so that suggests a benefit as a research language not a production language.
- dgoldstein0 2y ago
  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 time it's an indentation error. In coffeescript it's a valid program that means something completely different than what you intended. Combined with the optional punctuation, which the community encouraged leaning into, it was far too easy to write ambiguous code that you and the compiler would come to different interpretations of.

emmanueloga_ 2y ago

CoffeeScript was not only a great idea but also successful beyond its adoption. It influenced and inspired many features that JavaScript later incorporated, such as arrow functions and destructuring assignments. Over time, JavaScript evolved to the point where the few quality of life improvements offered by CoffeeScript no longer justified learning an entirely new syntax.

MajimasEyepatch 2y ago
I sometimes wonder if Kotlin will end up on the same trajectory. Java has added a lot of pretty good features since Kotlin first came on the scene, and the gap has narrowed considerably. The one thing enormous thing that Kotlin has that cannot be replicated easily in Java is null safety. But lately, most of the other features in Kotlin either make me long for something more powerful like Scala or shrug and just fall back to Java. Admittedly, I don't do much Android development, and that was a big driver of Kotlin's adoption early on. So maybe it has more of a foothold there than on the server.
- pjmlp 2y ago
  It will, because that is the fate of every guest language since the dawn of times. The "systems" language of the platform, evolves with the platform, is designed alongside the platform. The guest languages might be better than the platform's "systems" language, on the day of the release, eventually it is bound to diverge with its own library ecosystem built on top (because "ugh" we're not using the platform libraries directly), its own IDE tooling, its additional debugging layer due to platform interop, its own abstractions not native to the platform,..... Eventually it naturally diverges as the platform takes incompatible decisions,... C and C++ on UNIX, JavaScript and anything compiles to JS, Java vs Groovy/Scala/Clojure/Kotlin/jTCL/Beanshell/jython/...., C# vs VB.NET/F#/C++/CLI/IronPython/IronRuby,... The guest languages that are survive, are those that move beyond the platform that gave them birth and create a platform of their own. In Kotlin's case that is definitely Android, because Android team is doing everything at their disposal to make Java a 2nd class language on Android, rewriting Jetpack libraries in Kotlin, requiring Kotlin for Compose, showing off Kotlin code samples against Java 8 examples(!), I bet they only starting updating Java support, because Android was starting to lose too many Java libraries as the Java ecosystem adopts new versions. Still, Android 15 being released one year later from Java 21 LTS, is still catching up with Java 17 LTS, introduced in Android 13 and not yet fully implemented, kind of proves the point of them not being in a hurry for proper Java support on the platform.

edemaine 2y ago

One of the Civet devs here. To me, the main benefit of Civet is the ability to rapidly add useful features to the language, while preserving all the benefits of TS (tooling, etc.). We're constantly coming up with ideas — from TC39 proposals, other languages, or general brainstorming — and implementing them quickly. For example, we recently added pattern matching when catching exceptions, which took just a couple of hours of development; or Python-style from ... import ... for better autocompletion of imports. All of these features are optional; you can write well-formed TypeScript as usual, and just choose to use the features you think are worth the learning curve for readers. The plugins for VSCode, Vite, esbuild, Webpack, eslint, etc. aren't perfect, but they let Civet code enjoy most of the tooling out there. I personally use Civet for all my coding projects, as I'm devoted to it continuing to flourish. But if you ever don't like what Civet is offering you, you can eject at any time by replacing your code with the TypeScript compilation, which we make as close as we can to your input. What happens if a TC39 proposal is rejected? That's actually the good case for us, because it means we can keep the feature as is. Civet already transpiles all features to TypeScript, so they can live here forever if we think they're good. The trickier part is when Java/TypeScript changes in a way that's incompatible with Civet. Then we plan to change Civet to match Java/TypeScript, so that we don't diverge (though compiler flags allow us to also support the older form with explicit opt-in if we think it's worth doing so). JavaScript and TypeScript move slow. Largely that's a good thing; they're a stable foundation, and we don't want to mess them up. But it's also exciting to be on the bleeding edge, explore new ideas, and obtain new features as quickly as we can design them, instead of waiting a decade. Many features are also too niche / add to much complexity for the general JavaScript language, but they're still fair game for languages that transpile to JavaScript. See also the recent JS0 vs. JSSugar discussion.

lifthrasiir 2y ago
I think you need to drop or at least weaken an inspiration from CoffeeScript if that's a goal, otherwise everyone will immediately draw a connection to that and overlook any other aspect of Civet. (I personally hate CoffeeScript especially for its indentation and that contributed to my initial reaction.) You can't solve this problem with simply supporting two radically different coding styles---the front page seems to prefer one over another anyway.

mistercow 2y ago

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 combined with “everything is an expression”. You can have one of those, but not both. With both, it’s far too easy to write loops intended to be statements, and which accidentally turn into gigantic multi-dimensional array returns which can’t easily be optimized out by the compiler. Fortunately, this would be only mildly inconvenient to work around with a lint rule that forces explicit return in all functions.

edemaine 2y ago
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 https://civet.dev/reference#code-children
- mistercow 2y ago
  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.
scotty79 2y ago
You can have shadowing with explicitly declared variables. And there are languages that allow that, Rust to name one and I love that I can do that every time I use it.

Myrmornis 2y ago

That's a really mean / uncharitable take. As others have pointed out, coffeescript did a great job of moving the language in a good direction, and that's presumably exactly what's intended here.

Yahivin 2y ago

Something interesting I've found while designing Civet is that TypeScript actually mitigates in a lot of the downsides of CoffeeScript. Types help quite a bit with implicit returns so you don't accidentally return an iteration results array from a void function. They also help reduce the downsides of terse syntax, just hover over things in the IDE and see what they are. Missed a step in a pipeline? The IDE will warn you if there's a mismatch.

acjohnson55 2y ago

CoffeeScript was great. It was vastly more pleasant to code in than ES5-era JS. Once ES6 came out, we simply migrated to it and moved on.

scotty79 2y ago
I still use CS for prototyping. It's easy to write and what's most important it's easy to read due to lack of visual clutter of JS. Once I have something decent I just take JS output and annotate it with types and work on it further debugging and optimizing.

usrusr 2y ago

> What's the benefit over Typescript? A few less characters? Faster TC39 proposal integrations? Getting hands on experience with those proposals could be an argument, learning how they feel, learning how their availability changes the way people write code. Could this be called a research language? Sure, but that categorization would certainly influence the outcome of the observation. I'm not disagreeing with any of your points though. Perhaps some mitigation could be provided by making their equivalent of decaffeinization a true first class citizen, intended to be run whenever a proposal gets rejected (or implicitly rejected by the language taking a different direction). This would have to be fine grained, and the language/tool would have to make "rolling preview of whatever proposals are currently in consideration" the code of its identity, not any particular set of language features.

mirekrusin 2y ago

CoffeeScript was very successful, the main win was that it could become irrelevant because so many constructs were adopted upstream.

scotty79 2y ago

It was a wonderful idea that got 90% assimilated by the underlying language thus becoming successfully obsolete.

root_axis 2y ago

CoffeeScript was amazing. It was only a dead-end because flow and subsequently typescript made an offer the ecosystem couldn't refuse. Unfortunately, I doubt that Civet will have much future momentum because even though typescript is the state of the art for front-end dev, it's a much less stable foundation to build on top of than ES was for CoffeeScript.