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?
> 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.
> 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.
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.
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.
> but you're free to use explicit parentheses and braces as you like
I’ve been eying Civet and I quite like it so far, but I dislike having this option because it means I’ll have to see it in other peoples code. I prefer strict rules for readability.
What was so ruinous about implicit returns? That's one of the things I missed most when leaving CoffeeScript. ECMAScript only partially adopted it (single statement fat arrow functions) which probably muddies the waters for people trying to learn and understand the language's behavior.
Since it's optional for the caller to use or assign the return value of a function, I don't see much problem with functions defaulting to returning something. Maybe it just fits with my personal preference of functions returning a value and not having side-effects..
probably gets better with use but having to remember not to put a loop as the last statement of a function, because it would make it return an array of the last statement of the loop body, caught me off guard enough times to get annoying.
easy enough to add an extra line with just 'undefined' as the last statement of the function of course. but then you do need to remember that.
Oh man, that brings memories. When I joined a coffee-shop (pun intended), and learnt about implicit returns, I was screaming internally until we got rid of all the coffee (which was massive long team-wide migration effort that took like 2y to finish).
Once the migration was finished, everyone was so tired, that at the mere proposal of using TypeScript instead of JS the whole team would just roll their eyes and silently say "nope" in terror. Which was a shame, because large JS codebases are difficult to maintain and explore.
In Ruby and Elixir, it is implicit returns. That's always been like that, and people working with those languages don't have a problem with it. When I started writing Typescript, I was screaming internally at the explicit returns.
So I think this has more to do with how people are used to thinking with the languages they are fluent in.
It didn't solve the deeper problems, no, but it also didn't error out when you accidentally had a trailing comma in your object, -> and => made dealing with "this" less painful (no more "var that = this"), and stuff like that.
Convenience does matter. The less I have to think about nonsense like that, the more I can think about actually writing correct code.
CoffeeScript wasn't perfect in that sense either and had some nonsense of its own. That probably contributed to its demise as much as any thing else.
My biggest gripe with CoffeeScript, beyond it's scoping being madness [1], is it made writing very inefficient JavaScript much easier. The language was full of footguns.
Many times something would look perfectly reasonable in CoffeeScript but when you would actually read the JS it would be iterating the same dataset multiple times to grab individual items that could have and should have been a single loop.
It's the Hibernate problem all over again. Any time one language is layered on another, the user is totally unaware of the degenerate cases that they are triggering, and the higher language is usually blocked from fixing those. Similar to C++ preprocessors which generated poor C.
TypeScript even took off after the earth had been salted by CoffeeScript. Many people were sceptical about TypeScript because they assumed it was as big of a buy-in as CoffeeScript - rather than it just being JS with some (mostly) strictly-additive syntax, that you would have been able to strip out without risk had TS never taken off.
Regardless of one's opinion on duck typing, Javascript was like feeling out for ducks with your hands in the dark, typescript was like being able to see for the first time.
> 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.
It's also backed – nay, pushed – by one of the largest and most successful tech companies in the world. A company that also made a point of releasing a very capable IDE to go along with it. Surely this has had some impact on its meteoric rise? :o)
> JS of the era was a pain to use; CoffeeScript made writing and reading things much easier
It didn't. Anything you learn / are familiar with will be easier to write - Coffescript was easier to write for people who learned Coffescript. Which in hindsight wasn't time well spent as they would've eventually had to bite the bullet anyway & just learn JavaScript like everyone else.
JavaScript is much much easier to write and read for a person who has chosen to learn JavaScript & has not had the occasion to learn Coffescript (i.e. most people) so you were also doing others a disservice if readability was one of your goals.
> which is the reason it took off
The reason it took off was the Ruby was going through a popularity trend & Rails devs wanted to work in a front-end language that felt syntactically familiar. It was purely aesthetic.
Around 2012, I had sunk several years into becoming extremely familiar with JavaScript when I switched onto a team which was using CoffeeScript. I immediately liked it: it addressed some of the things I'd always found irritating about JavaScript, and I found it very easy to pick up. I was not a Ruby or even Python user at that time, so that didn't influence my decision either.
But you're right that you did have to know enough JS to understand what CoffeeScript was doing under the hood when things went wrong.
Outside of arrow functions, I don't really think CoffeeScript had a single important idea. And even then, the aversion to the `function` keyword in the JavaScript community never fails to make me laugh. Sure, sometimes the implicit scoping of the arrow function is nice, but man.
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.
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.
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.
And beyond this, there’s very much a world where a few key people don’t discover Jeremy Ashkenas’ work - much of which, between CoffeeScript and Backbone, was the excitement that you could make JS feel agile - at the right time in their careers to push the industry in the direction where frontend developers become frontend engineers. We owe so much to these stepping stones.
Well, yeah that was expressly known about CoffeeScript. It pushed JS to the future and was expected to be not useful whenever JS gained more features, but that would take a long time. And some of the syntax features weren't adopted, which meant CoffeeScript seems like a different thing from JS but it wasn't intended to be a departure or permanent.
But JS moved faster and babel was made and eventually we could use JS-future even when browsers hadn't updated yet and CoffeeScript wasn't needed. But it was pretty easy to translate it to JS, commit that and keep rolling. CS was great at the time.
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.
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.
I love getting rid of visual noise of brackets around code blocks. It's as silly debate as tabs vs spaces. It should be a text editor setting if you prefer to see them or hide and see just indents instead.
It's fun and valuable to have a place to land proposals and try them out early (seems like TS itself should have flags for this though). The problem is that as the proposal is refined, or if it is rejected, it implies constant changes to your language, which will basically drive away anyone who's not experimenting around for fun in the same mindset as you. Could be good or bad, although managing the flux might be tricky even so.
The addition of quick things you whipped up in a couple of hours seems like it'll make the rate of changes impossible to handle. It's unlikely almost by definition that the change you whipped up quickly will stand the test of repeated use and further experience unmodified.
All that said, it's a super fun thing to do, and hats off for such an ambitious project. If nothing else, writing a parser, transpiler, etc. is impressive and fun work, and will undoubtedly enable/force you to learn all the javascript/TS quirks and details extremely well! :-)
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.
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
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.
> implicit return combined with “everything is an expression”. You can have one of those, but not both.
Hang on, how can you have “everything is an expression” without implicit return? If I’m correctly understanding what you’re talking about, implicit return isn’t actually a thing—it’s just that the function body is an expression too.
(Never dealt with CoffeeScript, but I’ve been writing Rust for over a decade now, and learned to love expression-orientation there.)
You do it by making sequential evaluation (i.e. the semicolon, which becomes an operator in "everything is an expression" world) always produce a void result. Then you introduce the notion of terminating evaluation early and yielding a value from the compound expression - this becomes `return` (and other similar constructs like `break` and `continue`).
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.
I slightly misspoke. The issue was that you wanted shadowing, but because of the lack of declarations, some random inner variable could suddenly reference a variable with broader scope.
For example, you might have an “x” in some inner loop within a function. Then later on, you’d add an “x” earlier in the function, not realizing that that name was used down below. Suddenly the inner loop is referencing that new variable, and there was no way to tell other than the surprising ways your code would suddenly malfunction.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
- "everything is an expression" is a nicer solution for conditional assignments and returns than massive ternary expressions
- the pipe operator feels familiar from Elixir and is somewhat similar to Clojure's threading macros.
- being able to use the spread operator in the middle of an array? Sure, I guess.
I want to like the pattern matching proposal, but the syntax looks slightly too minimal.
The other proposals are either neutral or bad, in my opinion. Custom infix operators? Unbraced object literals? I'm not sure that anyone has a problem that these things solve, other than trying to minimize the number of characters in their source code.
Still, I'm glad that this exists, because allowing people to play with these things and learn from them is a good way to figure out which proposals are worth pursuing. I just won't be using it myself.
I'll pass on the pipe operator, but it's not particularly objectionable.
Agree there's some good ideas. Pattern matching looks like a great idea with the wrong syntax - let's just get a match statement similar to the switch statement - if we can't reuse switch.
String dedent and chained comparisons look nice. Though I think the latter is a breaking change if it were done in js. I'd also be fine with default const for loop variables.
"Export convenience" is going to confuse people. The syntax looks different than named exports and looks closer to the export form of default imports which is begging for trouble.
Exactly. It also massively improves readability by reordering the code to match the order of operations. Also long nested chains of function calls make it so the arguments for each call get spread out, so your eyes have to go back and forth to determine what function receives what.
Do blocks in Civet are mainly to provide shielded scopes (with local declarations). They're currently also necessary to handle declarations (const/let) in the middle of expressions, but hopefully they won't be necessary eventually - only when the user wants to shield scopes. They also have useful forms like `async do` that let you build Promises using await-style code.
This is terrible. I was so happy CoffeeScript died a quiet death. Now someone thinks of this.
Keep it simple. Code should be easy to read. Also, ain't nobody got time to learn yet another obscure abstraction that will add only a marginal productivity gain at best (and probably sacrifice readability + add another build step + add another learning curve to new devs in the process).
I'm not convinced this is a good idea either, but abstractions and syntax are what makes people love or hate a language. I enjoy writing python over JS because of ergonomics. Its not really about productivity, its about being happy when writing and reading code.
That being said, stapling on a compile step maybe isn't the answer.
CoffeeScript immediately revolted me and Civet is giving me the same heebie jeebies. It's the kind of punctuation-as-code that the world rejected 10+ years ago when Perl faded away. Verbose code is better for readability and readability is 100X more valuable that faster typing. It's not more expressive, it's more obscure.
Its not about how concise or short your code looks, its how about much time the new intern coming tomorrow needs to understand those 1000 line files. I find the syntax very hard to remember and confusing
And in times of Copilot & others writing become less and less a problem, as code completion works very well.
Like this example: https://civet.dev/#everything-is-an-expression
`items = for item of items`, in js you type `for`and copilot wrote nearly the full correct for-code. So you have to type not much and can read it easy.
It’s interesting in this example that the docs try to show that a for loop is useful, when there’s already an idiomatic approach here:
```
const result = items.map(
i => i.length
? i.toUpperCase()
: ‘<empty>’)
```
I think things get interesting here when different kinds of iterators come into play (eg generators, async-await for loops, non-array iterables). Shame the landing page doesn’t touch on that at all.
From my experience, I predict that LLM code completion will not work very well when using a language like Civet.
Copilot is good when working with something where the idiomatic patterns are common, widespread, and hard to screw up. Civet has low adoption, uses much looser syntax (bracing, whitespace), and lacks the rigor of common TypeScript code.
I was pleasantly surprised with how well Copilot picked it up. Civet doesn't have that many truly new language features, most of them are from existing languages and used in a similar way. Copilot is really good at matching what you are doing near the completion so I was impressed with how well it did with a new language.
We must be living on different worlds. Code completion is sometimes interesting, but being 50% of the time correct still means 50% of the time I have to fix the code that just got written. And it just gets horrible, if I can't trust the good 50% - nothings harder than reading code.
I think another way to express the same idea in a less business-like language is: it's nice to be able to come back to your side project after 6 months and be able to quickly make sense of it.
> Some people don't code for the interns but to have fun.
I don't think the person you were replying to necessarily disagrees with you there. But their post was phrased in such a way that seemed like business was the only focus that mattered, yeah.
If you write all your code in civet, them you'll have no trouble understanding civet code in 6 months. Besides that, there aren't many random symbols as additions, it's mostly logical extensions of the javascript syntax which are easy to understand if you know javascript.
The motivation is giving people a chance to try these features and thus ultimately helping move the language in a good direction. That's what coffeescript did also.
Languages like this don't make sense anymore. You can just pick a mature, feature-rich language you like (Rust, Kotlin, Python, probably many more) and transpile to JS.
That approach only makes any sense if you have broadly compatible semantics; otherwise execution will pay a heavy penalty (CPU usage, memory usage, bundle size). And let me tell you, your “Rust, Kotlin, Python, probably many more” don’t transpile to JS well. If you genuinely mean transpiling as distinct from compiling, I think you could even reasonably say that it’s simply not possible for many languages due to fundamental and incompatible differences. I’d count Rust as that due to things like resolution and aliasing.
If you’re interested in targeting JavaScript, languages like this are your only reasonable alternative to JavaScript itself. (If you’re interested in targeting the web more generally, WebAssembly is a better target.)
I should have referenced compiling to Wasm as well, which is what languages with very different semantics to JS (like Rust, the CLR family, and the JVM family) all do.
Working with WASM isn’t really that good for interactive pages with dynamic DOM.
If you don’t mind I guess you could just render to a canvas but then you lose a ton of functionality provided by the browser. (Eg: making a responsive page in WASM seems hard)
It seems to me for most web applications JS is the only real alternative as of now
> Working with WASM isn’t really that good for interactive pages with dynamic DOM.
It’s completely fine. At present you’ll need to trampoline via JS to make the actual DOM calls, but that’s not typically a performance bottleneck; and such bindings can give you exactly the same API, if you choose.
Yes, work is just about done in browsers for giving you direct access to these things without the JS trampolining, and lots of people are hanging out for that to be dependable, but in practical terms it changes nothing. Nothing. No change in expressiveness; it only gets you probably slightly better performance, and a simpler technique for binding (which is typically immaterial for end users, as libraries were handling that for them).
If you do mean more generically targeting the web, then I recommend avoiding the word “transpile”, which will be understood to be something far more restricted in scope.
That’s certainly not true of Rust: Rust had a particular goal, easily recognised as worthwhile, which wasn’t possible with any existing languages. Everyone sensible agreed the language made a lot of sense, even if they weren’t sold on the practicality of its specific approach.
I didn’t get involved with any of this stuff until mid-2013, but at the very least by then, it was well understood that Servo couldn’t reach its potential without Rust.
> Rust began as a personal project in 2006 by Mozilla Research employee Graydon Hoare, named after the group of fungi that are "over-engineered for survival". Mozilla began sponsoring the project in 2009, and would employ a dozen engineers to work on it full time over the next ten years
So by 2013 it was already 7 years old. I very much doubt the original personal project was viewed as "a lot of sense" etc.
You’ll always easily find plenty of people that will say “that makes no sense”. But of people that worked in these sorts of fields, I imagine that, from the very start, there would have been significantly more than average approval for its goals, even if you wouldn’t expect it to succeed (such endeavours normally don’t). The niche Rust was targeting from the very beginning was one that was known to be underserved, and known to be rather important.
The built in browser debugger is incredibly good. As long as the transpilation is simple and matches JS semantics you can still use the debugger. I haven't seen good debugging tools when using languages more distant from JS but I'd love to know if they've become viable.
You've been able to debug TypeScript (and anything else that transpiles to JS) natively in the browser for years using sourcemaps. That includes Dart, C#/F#, Go (as far as I know), and Python.
For the languages that target wasm instead, there are different debugging stories. Kotlin's is very good, Rust's is pretty immature.
Source maps are not sufficient to fully expose the semantics of the language being debugged to the debugger. You also need the expression evaluator (for stuff like Watch etc) to understand what it's debugging. And in cases where transpilation includes nontrivial mapping of data structures, you also need the ability to do that mapping in reverse to display the values.
Source maps work great for TS because it is just "JavaScript with types" at this point.
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. :)
Not a fan of YAML at all myself, but it's interesting that you like 'Yaml-like object structuring' yet then loathe 'Signifiant whitespace'? I mean that's basically YAML.
So make sure you introduce this in your company; become the subject expert in it, invite everyone to very cool sessions demonstrating how cool it is, and secure your job until the next rewrite!
Looking at the examples, 1/5th of it looked neat, which probably would be best to submit a proposal for |> to the typescript committee rather than write another alienation.
This is a solution looking for a problem to solve. It introduces an alternative and does so as a superset; which is not only dangerous to existing code bases, but also silly.
An alternative way to do something in a code base, for no other reason than style, is a recipe for technical debt. It builds up a larger cognitive load on the developers navigating and working the code base and induces more chances of bugs via half-refactors, or half-considerations.
As for the superset comment, I meant that if you introduce a completely different language, you probably have a valid reason; e.g. it does something different. Adding to an existing language with a superset without any need for it is also dangerous. It's not like it's a DSL at a higher level helping people get repetitive or scriptable things done faster. It's only an alternative, leading people down rabbit hole and second guessing with a lot more to remember.
I see. I misinterpreted your meaning of the word "existing" - I thought you were implying that, by virtue of the introduction of the alternative, any existing codebases would _immediately and instantly_ be worsened, whereas it seems that you're saying that continued (future) development _on_ existing codebases would deteriorate due to those alternatives. That's a fair criticism! I don't fall on the same point in the "alternatives provide better-focused tools <-> alternatives create cognitive load" spectrum as you do, but I see your point.
> It's not like it's a DSL at a higher level helping people get repetitive or scriptable things done faster.
I mean, I have to disagree with you there, because several of the comparisons on the main site page show >50% line-count reduction, and many of those that don't have (subjectivity-alert!) representations that more-clearly match my mental model of how the code works - so not only would I be executing fewer keystrokes to encode my idea (not the main bottleneck, but not irrelevant!), but also I'd be carrying out fewer mental translations to get from idea to code.
The real challenge in languages now is flawless LSP implementation, auto-formatter and AI completion. It’s possible for CoffeeScript like syntax, but just the existence of an auto-formatter mostly removes the need for dropping all the syntax.
I’d maybe take dropping of parens from if, to align with Rust, but even some of Rust’s syntax makes the language hard to read (if let bindings for example, which switch the flow from right to left), so I don’t consider it a golden standard to strive for anymore.
The other thing I would take is custom operators, not for any production code, but for building games and simulations, to simplify vector math.
I’ll check out the Civet IDE experience, but I suspect it’ll have large cons compared with TS.
I feel like there is a specific kind of person that likes all this, and there is very little overlap between those people and the people that choose to use Typescript.
Kinda feels like someone was forced to work in Typescript and really wanted to scratch their own itch.
I must be a very specific kind of person. I love TypeScript, and loved CoffeeScript even more. I’m baffled by many of the comments here and excited to try Civet.
It appears to prioritize easier and faster typing over readability, which is a poor choice as programmers spend more time reading rather than writing code.
Having worked in Rust I love the pattern matching proposal. Having dabbled in Swift I like the single argument function part (though keep the brackets, please)
Much of the rest I could take or leave… but then is that just because I’m not familiar with them? Stuff like the pipe operator makes sense to me but it reminds me of .reduce(): there are a few legitimate uses of it but the vast majority will be entirely-too-smart—for-its-own-good show off coding.
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.
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.
Not so sure. JSX is already a transpilation language. Why target a language that's only supported as an input language for other compilers? I don't think this is an LLVM-type scenario.
As an example, Solid's JSX compiler changes multiple times in a year. It's better to target JSX than the compiled form. There are also many JSX compilers. (Even React ships with at least two.)
The pattern matching (TC39 stage 1) and pipeline operators (TC39 stage 2) look great, and I'd love to have those in TypeScript. It will probably take a loooong while for those features to be available in JavaScript, but I feel like I can live without those for now :-).
Fwiw it seems a lot of people really like the concept of "significant indentation". I'm thinking Python, YAML, Godot's GDScript. Not a lof of languages implement it but those that do seem to get a lot of users.
Interestingly, it seems like Erik Demain [1] is one of the contributors [2] of this project.
Note that the pipe operator is the rejected tacit pipes from TC-39. TC-39 made the (IMO) wrong choice of what they call hack style pipes (with a mandatory token) where instead of the pipe being a simple way to call unary functions. Civet seems to have picked the better pipes.
That’s part of what C does, but it’s not the only thing.
Assembly adds mnemonics and a logical structure to machine code.
C largely does the same, but adds a cross-platform abstraction, mechanisms for organizing and sharing source code, a standard library, and various other things.
Syntactic sugar is such a broad and vague term that those features you mentioned could also technically be considered syntactic sugar. Instead of having to write harder longer code you can write easier and less code.
I think we can understand syntactic sugar as an alternative (hopefully more convenient, elegant, or pleasing) syntax for expressing something that can already be expressed.
That is, something that works the same but looks better (hopefully).
A cross-CPU abstraction, a preprocessor, a standard library all have certain elements of syntax in them, but go well beyond alternative syntax.
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.
The pipe operator just flips the order of execution. In my experience this doesn't really impact debugging at all.
without the pipe operator you would write ` fun1(fun2(fun3(fun4(fun5(x, y), z, w), u), v)) `
The order of operations in this line is actually from right to left. Also it's not immediately obvious to which function the u parameter belongs to.
With the pipe operate you would write it in the order that the functions are actually called and you have the arguments in the same location as the function they belong to.
So this would be written something like
I really, really dislike the Elixir/Ruby style of optional parentheses. Explicit is better than implicit!
I also absolutely cannot parse this, and while I'm open to the idea that eventually this would become readable, right now this just looks like word salad:
Yeah I agree, 'value min ceiling max floor' is a terrible example. Especially when making a case for improving readability.
That being said; regular written language (like in a book) has optimal readability. Therefore it makes sense for programming languages to lean towards that. If you could write code like: `draw 600 by 600 graph_of intersection_of data_set1 data_set2 in blue` it would be very easy for basically anybody to tell what the code does. This not only makes it easier for beginners and onboarding, it also reduces cognitive load, even for senior level engineers. In real terms this means less fatigue, less bugs, less time spent reviewing code, higher productivity.
That being said I also prefer the explicitness of parentheses, but I think that's because I'm used to needing that level of explicitness. But maybe there's some paradigm out there that makes it so we don't need that crutch
The problem with written language is that there's an inherent level of ambiguity. Now, this is fine for stuff read by humans, as we're pretty good at resolving that ambiguity using context and our own personal experience. Computers, however, are not good at ambiguity. They require explicitly defined syntax, as they just can't handle the ambiguous nature of natural language (at least, not without a shitload of processing power for a LLM)
Now, there's no reason we can't have an explicitly defined syntax that reads like normal written language. That's what SQL tries to do, after all. However, explicitly defined "natural" language has the tendency to get very unnatural very quickly. Human language is fluid and evolving in a way that a programming language just can't be. And no amount of emulating written language can eliminate the need to learn a programming language's syntax.
This just looks like it's trying to remove as much syntax as possible and as a consequence makes it harder for me to follow what's going on. Kind of like a write-only language.
I do not particularly like the lack of brackets everywhere. I think it is hard to know precedence perfectly and brackets ensure you do not make stupid mistakes.
Also there is the classic issue where you take an if statement that has a line one expression and you add a second line, but now because it didn't have brackets (and you are not using indentation style), you just introduced a bug. Or you have an if statement with an expression and you comment out the expression but not the if, then your next statement is now the if conditional expression, which is not obvious.
But we are using indentation style; that's one of the major design principles. In Civet, the body of an "if" can be multiple lines, and it's clear (from indentation) what they're nested under. Also, the body of an "if" statement can be empty, so if you comment out the body, the "if" doesn't apply to anything else. (This is an improvement over Python, which requires non-empty bodies, even if just to say "pass".)
I think there's a reason that Python is among the most popular programming languages, and part of it is the indentation-based syntax and lack of brackets. The core of Civet's syntax (originally inspired by CoffeeScript) is like a combination of JavaScript/TypeScript and Python, the two/three most popular programming languages.
But also, if you like brackets, you can include them! Most JavaScript/TypeScript code is also valid Civet. Just use the features you like.
>I think there's a reason that Python is among the most popular programming languages, and part of it is the indentation-based syntax and lack of brackets.
Perhaps, but IMO that will then be because it looks tempting at first glance like YAML. No matter how much Python I write, I never learned to enjoy this and the fact that I can't select inside/around brackets to quickly manipulate a scope is just so frustrating.
Python used an indentation-based syntax from the beginning and its syntax is particularly optimized for that. In particular, any block statement (formally, a statement followed by a "suite") would end with `:` and that's effectively the only place where a dangling `:` can happen [1], so you can easily recognize such statement from any directions.
In comparison, at least some people would find CoffeeScript and Civet to be hard to read because they solely rely on left-bearing indents. If my eye is pointing to the rightmost column and scanning to left, I wouldn't be sure about any nature of the line until the very first token and thus preceding indent is reached. This problem is not unique but can be somehow alleviated with some tweaks to the syntax. Ruby `if` for example is also prone to this issue but an explicit `end` token keeps it on track in most cases. CoffeeScript did nothing.
[1] The only other case is `lambda ...:` in parenthesized expressions. `lambda` in Python is quite exceptional in its syntax after all...
Civet has so many quality of life improvements! It's good that it exists sort of as a playground for ideas that could maybe in the future be adopted by JS itself, kinda like how it went with CoffeeScript.
The usual curse of syntax extensions is that they make a few good things and then a pile of bikeshedded nonsense in the same payload. These two sets differ from person to person, of course.
Dedent and object globs are useful imo and should be added to javascript. Maybe for-of with index too.
Also, I see no flow control in array literals, how do they plan to appeal to jsx/h users?
I think the most exciting aspect here is this might actually push JavaScript to add some missing features that can make a lot of difference, the pipeline operator for example can really improve the design of JavaScript code and has been proven already in several languages, C#, swift, kotlin to name a few I know
I personally would love for 90% of these features to make it into TypeScript and eventually be ECMAScript standards. This is a taste of the world we could have, I don't understand all the hate towards this project.
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.
It would essentially involve changing the meaning of `: Type` and `as Type`. Basically, instead of ignoring type annotations at runtime, you'd have to throw when a cast fails.
This would also have other implications on the language design. Checking if an expression has a certain type at runtime would mean relying less on structural types to make these checks cheap.
I've been thinking about this exact language a lot recently, but it would not be the same as Typescript. A superset of JavaScript which can be statically optimized based on type information.
Fwiw, I don't think Assembly script is this language either. It's a completely different language than JavaScript with a superficially similar syntax.
We're definitely looking for ways to improve ways to specify types! I think destructured typing [https://civet.dev/reference#destructured-typing] is already quite useful, especially for React. On the readability side, if/then/else [https://civet.dev/reference#conditional-types] seems easier to read than ?: ternaries, and "Partial Record Name, Info" seems easier to read than "Partial<Record<Name, Info>>" (implicit type arguments — https://civet.dev/reference#implicit-type-arguments). But we'd love to hear more ideas for features like branded types. Join us in Discord if you're interested!
The one thing i was hoping for from civet is the trailing closure syntax from swift, which would make jsx less needed and make similar dsl usage way more convenient. There is absolutely a place to get real world experience with syntax that did not make it or is not ready yet to be moved forward in standardisation.
A lot of hate in the comments but I’m excited for this. I don’t think I’d ever inflict it on teammates, but this looks like a much nicer way to use functional idioms without making the jump to something like PureScript. I’ll definitely try this for personal projects.
Civet reminds me of Coffeescript but now in TypeScript.
This has made me even more convinced that the future of JavaScript is JavaScript.
We will be seeing JavaScript (natively) having all the types, features and proposals that TypeScript has and the industry will eventually move on from TypeScript.
I feel like typescript would officially deprecate itself if that ever happened. But I also feel like that won't ever happen. It would be cool if ES would get optional type annotations or something, even if they were ignored at runtime. But someone would still want a static type checker. TS does that, and if there's nothing to replace that part, then TS still has a viable mission statement.
The more I've used Golang over the past few years the more I've come to appreciate the simplicity of its design and its lack of syntactic sugar.
It's made me realise that much of the sugar I was writing in other languages didn't make me more productive or my code more readable, in many cases it was actually the opposite and the usage of that sugar was more about writing more "succinct" code that was in the long run harder to understand and maintain.
I really like that everything is an expression. I know the extra work is happening in the background, but this kind of developer experience is really nice in my opinion.
Since Typescript I wanted a Coffeescript with gradual typing. But I'm not sure if Civet isn't going to far into foreign syntax and shorthands for many things.
It probably won't share fate of Coffeescript. It won't get popular, influence TS and JS and fade into obsurity due to mostly fulfilling it's goal. I'm afraid it won't get popular enough to do that.
The linked page is pretty self explanatory. It’s TS with some extra features, many of which are already proposals for the language. Cool for an experiment, not good for a maintained codebase.
* `{min, max} := Math` is a destructuring declaration. It's similar to the destructuring assignment `{min, max} = Math` (i.e., `min = Math.min; max = Math.max`), but also declares min and max as const.
* The `operator` prefix means to treat min and max as new infix operators in the rest of the program.
Second line:
Given that min and max are infix operators, `value min ceiling max floor` is equivalent to `max(min(value, ceiling), floor)`. Yes, the latter is gross. That's why we like to write `value min ceiling max floor` instead. Think of it as "value minned with ceilling (i.e. capped at ceiling), then maxed with floor (i.e. prevented from going below floor)".
All I’m seeing here is alternative syntax for what’s already there.
I like some of it, but that’s hardly worth the increase in complexity.
In fact, having fewer aesthetic syntax choices is probably more of an improvement — cuts down on pointless/superficial coding style arguments, and leaves code generally more readable.
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.
I came to the same conclusion after the initial perl intoxication. Stable, regular constructs are much easier to parse and get back to than this pseudo-natural language. My worst confusion is python’s truly unreadable “x if cond else y” construct, especially when x and y are non-trivial. Putting a condition in between is not smart. Oh, now this gets me started on “is not”! Keeping calm…
One nice aspect of Python compared to TS/JS is the presence of list, set, map, and generator comprehensions. How far in that direction is civet likely to go? I see that arrays can be built from a for...of expression.
There is nothing I miss more in TS than pattern matching, so I came in with a lot of good will, but the syntax for it looks jarring to me. Might be a matter of taste, I'm not made for meaningful whitespaces
I’ve been a rails developper my entire career and I’ve seen some sh*t with coffeescript monstrosities. I am so glad we moved away from that, and I won’t be going down that path again.
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!)
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
"<empty>"
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.
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?
> 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.
> 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.
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.
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.
> but you're free to use explicit parentheses and braces as you like
I’ve been eying Civet and I quite like it so far, but I dislike having this option because it means I’ll have to see it in other peoples code. I prefer strict rules for readability.
Regardless, I like pretty much everything else.
> And then it ruined us with implicit returns
What was so ruinous about implicit returns? That's one of the things I missed most when leaving CoffeeScript. ECMAScript only partially adopted it (single statement fat arrow functions) which probably muddies the waters for people trying to learn and understand the language's behavior.
Since it's optional for the caller to use or assign the return value of a function, I don't see much problem with functions defaulting to returning something. Maybe it just fits with my personal preference of functions returning a value and not having side-effects..
probably gets better with use but having to remember not to put a loop as the last statement of a function, because it would make it return an array of the last statement of the loop body, caught me off guard enough times to get annoying.
easy enough to add an extra line with just 'undefined' as the last statement of the function of course. but then you do need to remember that.
I came from Ruby and Elixir. It is always implicit returns. When I started writing TypeScript, having to have explicit returns was my number 1 bug.
People can adapt either way. You can write more concise code with implicit returns and "everything is an expression".
> implicit returns
Oh man, that brings memories. When I joined a coffee-shop (pun intended), and learnt about implicit returns, I was screaming internally until we got rid of all the coffee (which was massive long team-wide migration effort that took like 2y to finish).
Once the migration was finished, everyone was so tired, that at the mere proposal of using TypeScript instead of JS the whole team would just roll their eyes and silently say "nope" in terror. Which was a shame, because large JS codebases are difficult to maintain and explore.
In Ruby and Elixir, it is implicit returns. That's always been like that, and people working with those languages don't have a problem with it. When I started writing Typescript, I was screaming internally at the explicit returns.
So I think this has more to do with how people are used to thinking with the languages they are fluent in.
It didn't solve the deeper problems, no, but it also didn't error out when you accidentally had a trailing comma in your object, -> and => made dealing with "this" less painful (no more "var that = this"), and stuff like that.
Convenience does matter. The less I have to think about nonsense like that, the more I can think about actually writing correct code.
CoffeeScript wasn't perfect in that sense either and had some nonsense of its own. That probably contributed to its demise as much as any thing else.
My biggest gripe with CoffeeScript, beyond it's scoping being madness [1], is it made writing very inefficient JavaScript much easier. The language was full of footguns.
Many times something would look perfectly reasonable in CoffeeScript but when you would actually read the JS it would be iterating the same dataset multiple times to grab individual items that could have and should have been a single loop.
1. https://donatstudios.com/CoffeeScript-Madness
It's the Hibernate problem all over again. Any time one language is layered on another, the user is totally unaware of the degenerate cases that they are triggering, and the higher language is usually blocked from fixing those. Similar to C++ preprocessors which generated poor C.
You just about need some sort of ast optimizer or some such.
TypeScript even took off after the earth had been salted by CoffeeScript. Many people were sceptical about TypeScript because they assumed it was as big of a buy-in as CoffeeScript - rather than it just being JS with some (mostly) strictly-additive syntax, that you would have been able to strip out without risk had TS never taken off.
> TypeScript solved those problem
I don't think TS removed any peculiarities of JS. It just forced you to actually learn them which JS and CS didn't do.
Regardless of one's opinion on duck typing, Javascript was like feeling out for ducks with your hands in the dark, typescript was like being able to see for the first time.
> 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.
It's also backed – nay, pushed – by one of the largest and most successful tech companies in the world. A company that also made a point of releasing a very capable IDE to go along with it. Surely this has had some impact on its meteoric rise? :o)
(Wait – aren't meteors falling?)
I never wrote enterprise apps in it but the short syntax and arrows made it easier to prototype/ reason with it.
It probably died fueling the whole js build/transpiler landscape that is in use today.
> JS of the era was a pain to use; CoffeeScript made writing and reading things much easier
It didn't. Anything you learn / are familiar with will be easier to write - Coffescript was easier to write for people who learned Coffescript. Which in hindsight wasn't time well spent as they would've eventually had to bite the bullet anyway & just learn JavaScript like everyone else.
JavaScript is much much easier to write and read for a person who has chosen to learn JavaScript & has not had the occasion to learn Coffescript (i.e. most people) so you were also doing others a disservice if readability was one of your goals.
> which is the reason it took off
The reason it took off was the Ruby was going through a popularity trend & Rails devs wanted to work in a front-end language that felt syntactically familiar. It was purely aesthetic.
Around 2012, I had sunk several years into becoming extremely familiar with JavaScript when I switched onto a team which was using CoffeeScript. I immediately liked it: it addressed some of the things I'd always found irritating about JavaScript, and I found it very easy to pick up. I was not a Ruby or even Python user at that time, so that didn't influence my decision either.
But you're right that you did have to know enough JS to understand what CoffeeScript was doing under the hood when things went wrong.
This sounds a bit like all design is just what you are accustomed to, which seems wrong.
> JS of the era was a pain to use
Was it really?
Outside of arrow functions, I don't really think CoffeeScript had a single important idea. And even then, the aversion to the `function` keyword in the JavaScript community never fails to make me laugh. Sure, sometimes the implicit scoping of the arrow function is nice, but man.
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.
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.
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.
And beyond this, there’s very much a world where a few key people don’t discover Jeremy Ashkenas’ work - much of which, between CoffeeScript and Backbone, was the excitement that you could make JS feel agile - at the right time in their careers to push the industry in the direction where frontend developers become frontend engineers. We owe so much to these stepping stones.
Well, yeah that was expressly known about CoffeeScript. It pushed JS to the future and was expected to be not useful whenever JS gained more features, but that would take a long time. And some of the syntax features weren't adopted, which meant CoffeeScript seems like a different thing from JS but it wasn't intended to be a departure or permanent.
But JS moved faster and babel was made and eventually we could use JS-future even when browsers hadn't updated yet and CoffeeScript wasn't needed. But it was pretty easy to translate it to JS, commit that and keep rolling. CS was great at the time.
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.
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.
I love getting rid of visual noise of brackets around code blocks. It's as silly debate as tabs vs spaces. It should be a text editor setting if you prefer to see them or hide and see just indents instead.
It's fun and valuable to have a place to land proposals and try them out early (seems like TS itself should have flags for this though). The problem is that as the proposal is refined, or if it is rejected, it implies constant changes to your language, which will basically drive away anyone who's not experimenting around for fun in the same mindset as you. Could be good or bad, although managing the flux might be tricky even so.
The addition of quick things you whipped up in a couple of hours seems like it'll make the rate of changes impossible to handle. It's unlikely almost by definition that the change you whipped up quickly will stand the test of repeated use and further experience unmodified.
All that said, it's a super fun thing to do, and hats off for such an ambitious project. If nothing else, writing a parser, transpiler, etc. is impressive and fun work, and will undoubtedly enable/force you to learn all the javascript/TS quirks and details extremely well! :-)
Coming from Ruby and Elixir, Civet adds a lot of things I miss from those languages.
I still have gripes about runtimes such as Nodejs, but I don't expect something like Civet to solve those.
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.
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
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.
> implicit return combined with “everything is an expression”. You can have one of those, but not both.
Hang on, how can you have “everything is an expression” without implicit return? If I’m correctly understanding what you’re talking about, implicit return isn’t actually a thing—it’s just that the function body is an expression too.
(Never dealt with CoffeeScript, but I’ve been writing Rust for over a decade now, and learned to love expression-orientation there.)
You do it by making sequential evaluation (i.e. the semicolon, which becomes an operator in "everything is an expression" world) always produce a void result. Then you introduce the notion of terminating evaluation early and yielding a value from the compound expression - this becomes `return` (and other similar constructs like `break` and `continue`).
Ah yes, true, true, I had forgotten about the semicolon. Somehow. Yeah, I don’t think I’d like expression-orientation so much without it.
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.
I slightly misspoke. The issue was that you wanted shadowing, but because of the lack of declarations, some random inner variable could suddenly reference a variable with broader scope.
For example, you might have an “x” in some inner loop within a function. Then later on, you’d add an “x” earlier in the function, not realizing that that name was used down below. Suddenly the inner loop is referencing that new variable, and there was no way to tell other than the surprising ways your code would suddenly malfunction.
Ah, I see, you are right. It's terrible behavior.
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.
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.
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.
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.
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.
What makes Civet more likely to drive that innovation than TC39 proposals themselves?
We ship
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.
> 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.
CoffeeScript was very successful, the main win was that it could become irrelevant because so many constructs were adopted upstream.
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.
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.
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.
It was a wonderful idea that got 90% assimilated by the underlying language thus becoming successfully obsolete.
Some of these seem good to me:
- "everything is an expression" is a nicer solution for conditional assignments and returns than massive ternary expressions
- the pipe operator feels familiar from Elixir and is somewhat similar to Clojure's threading macros.
- being able to use the spread operator in the middle of an array? Sure, I guess.
I want to like the pattern matching proposal, but the syntax looks slightly too minimal.
The other proposals are either neutral or bad, in my opinion. Custom infix operators? Unbraced object literals? I'm not sure that anyone has a problem that these things solve, other than trying to minimize the number of characters in their source code.
Still, I'm glad that this exists, because allowing people to play with these things and learn from them is a good way to figure out which proposals are worth pursuing. I just won't be using it myself.
I'll pass on the pipe operator, but it's not particularly objectionable.
Agree there's some good ideas. Pattern matching looks like a great idea with the wrong syntax - let's just get a match statement similar to the switch statement - if we can't reuse switch.
String dedent and chained comparisons look nice. Though I think the latter is a breaking change if it were done in js. I'd also be fine with default const for loop variables.
"Export convenience" is going to confuse people. The syntax looks different than named exports and looks closer to the export form of default imports which is begging for trouble.
Using the pipe operator in Elixir is very nice, even more so for building up complex multi operations and such
Exactly. It also massively improves readability by reordering the code to match the order of operations. Also long nested chains of function calls make it so the arguments for each call get spread out, so your eyes have to go back and forth to determine what function receives what.
For “everything is an expression” https://github.com/tc39/proposal-do-expressions may be of interest, though discussion seems to have paused.
The odd thing is that Civet includes both do expressions and everything is an expression. I'd be happy with either, but both seems like a bad idea.
Do blocks in Civet are mainly to provide shielded scopes (with local declarations). They're currently also necessary to handle declarations (const/let) in the middle of expressions, but hopefully they won't be necessary eventually - only when the user wants to shield scopes. They also have useful forms like `async do` that let you build Promises using await-style code.
This is terrible. I was so happy CoffeeScript died a quiet death. Now someone thinks of this.
Keep it simple. Code should be easy to read. Also, ain't nobody got time to learn yet another obscure abstraction that will add only a marginal productivity gain at best (and probably sacrifice readability + add another build step + add another learning curve to new devs in the process).
I'm not convinced this is a good idea either, but abstractions and syntax are what makes people love or hate a language. I enjoy writing python over JS because of ergonomics. Its not really about productivity, its about being happy when writing and reading code.
That being said, stapling on a compile step maybe isn't the answer.
CoffeeScript immediately revolted me and Civet is giving me the same heebie jeebies. It's the kind of punctuation-as-code that the world rejected 10+ years ago when Perl faded away. Verbose code is better for readability and readability is 100X more valuable that faster typing. It's not more expressive, it's more obscure.
Its not about how concise or short your code looks, its how about much time the new intern coming tomorrow needs to understand those 1000 line files. I find the syntax very hard to remember and confusing
The new intern or you in a year reviewing your own code.
And in times of Copilot & others writing become less and less a problem, as code completion works very well.
Like this example: https://civet.dev/#everything-is-an-expression `items = for item of items`, in js you type `for`and copilot wrote nearly the full correct for-code. So you have to type not much and can read it easy.
To reiterate the point above: writing is not the biggest problem. reading is.
(Terse Perl may be delightful to write, as long as you still remember exactly what you wrote and why. But not after that.)
It’s interesting in this example that the docs try to show that a for loop is useful, when there’s already an idiomatic approach here:
``` const result = items.map( i => i.length ? i.toUpperCase() : ‘<empty>’) ```
I think things get interesting here when different kinds of iterators come into play (eg generators, async-await for loops, non-array iterables). Shame the landing page doesn’t touch on that at all.
From my experience, I predict that LLM code completion will not work very well when using a language like Civet.
Copilot is good when working with something where the idiomatic patterns are common, widespread, and hard to screw up. Civet has low adoption, uses much looser syntax (bracing, whitespace), and lacks the rigor of common TypeScript code.
I was pleasantly surprised with how well Copilot picked it up. Civet doesn't have that many truly new language features, most of them are from existing languages and used in a similar way. Copilot is really good at matching what you are doing near the completion so I was impressed with how well it did with a new language.
We must be living on different worlds. Code completion is sometimes interesting, but being 50% of the time correct still means 50% of the time I have to fix the code that just got written. And it just gets horrible, if I can't trust the good 50% - nothings harder than reading code.
I think it’s time to reveal the shocking ancient knowledge people weren’t ready to deal with before: textmate snippets.
And so on.Seriously, typing code is some '90s activity since forever. Using copilot for this is akin to hitting a nail with a microscope.
I don’t understand your last part of the comment. What are you saying copilot should be used for?
CoPilot completion is much more extensive than any of these.
If you don’t understand the code code completion becomes cargo cult programming.
I sure hope they see it and realize it is most likely in desperate need of refactor
Some people don't code for the interns but to have fun. But I agree this isn't a very enterprise programming language, à la Java or Golang.
I think another way to express the same idea in a less business-like language is: it's nice to be able to come back to your side project after 6 months and be able to quickly make sense of it.
> Some people don't code for the interns but to have fun.
I don't think the person you were replying to necessarily disagrees with you there. But their post was phrased in such a way that seemed like business was the only focus that mattered, yeah.
If you write all your code in civet, them you'll have no trouble understanding civet code in 6 months. Besides that, there aren't many random symbols as additions, it's mostly logical extensions of the javascript syntax which are easy to understand if you know javascript.
> If you write all your code in civet, them you'll have no trouble understanding civet code in 6 months.
I hope so.
> it's mostly logical extensions of the javascript syntax which are easy to understand if you know javascript.
They didn't look thatneasy to understand to me, and a lot of other people judging by the comments.
Pretty much what I feel about Rust
Explain more?
yea this
i see it as moving physical abstraction into mental abstraction
save few lines of code but costs more mental ram
Really redminds me of coffeescript, lots of special syntax that doesn't really help readability?
I have a hard time understanding the motivation of this project other than syntactic sugar-maxxing JS/TS.
The motivation is giving people a chance to try these features and thus ultimately helping move the language in a good direction. That's what coffeescript did also.
Languages like this don't make sense anymore. You can just pick a mature, feature-rich language you like (Rust, Kotlin, Python, probably many more) and transpile to JS.
That approach only makes any sense if you have broadly compatible semantics; otherwise execution will pay a heavy penalty (CPU usage, memory usage, bundle size). And let me tell you, your “Rust, Kotlin, Python, probably many more” don’t transpile to JS well. If you genuinely mean transpiling as distinct from compiling, I think you could even reasonably say that it’s simply not possible for many languages due to fundamental and incompatible differences. I’d count Rust as that due to things like resolution and aliasing.
If you’re interested in targeting JavaScript, languages like this are your only reasonable alternative to JavaScript itself. (If you’re interested in targeting the web more generally, WebAssembly is a better target.)
I should have referenced compiling to Wasm as well, which is what languages with very different semantics to JS (like Rust, the CLR family, and the JVM family) all do.
Working with WASM isn’t really that good for interactive pages with dynamic DOM.
If you don’t mind I guess you could just render to a canvas but then you lose a ton of functionality provided by the browser. (Eg: making a responsive page in WASM seems hard)
It seems to me for most web applications JS is the only real alternative as of now
> Working with WASM isn’t really that good for interactive pages with dynamic DOM.
It’s completely fine. At present you’ll need to trampoline via JS to make the actual DOM calls, but that’s not typically a performance bottleneck; and such bindings can give you exactly the same API, if you choose.
Yes, work is just about done in browsers for giving you direct access to these things without the JS trampolining, and lots of people are hanging out for that to be dependable, but in practical terms it changes nothing. Nothing. No change in expressiveness; it only gets you probably slightly better performance, and a simpler technique for binding (which is typically immaterial for end users, as libraries were handling that for them).
If you do mean more generically targeting the web, then I recommend avoiding the word “transpile”, which will be understood to be something far more restricted in scope.
All those mature feature-rich languages started as "languages like this make no sense"
That’s certainly not true of Rust: Rust had a particular goal, easily recognised as worthwhile, which wasn’t possible with any existing languages. Everyone sensible agreed the language made a lot of sense, even if they weren’t sold on the practicality of its specific approach.
IIRC everyone was perplexed why Mozilla was spending time on what looked like a research/academic problem instead of focusing on Servo
I didn’t get involved with any of this stuff until mid-2013, but at the very least by then, it was well understood that Servo couldn’t reach its potential without Rust.
Just to quote Wikipedia:
> Rust began as a personal project in 2006 by Mozilla Research employee Graydon Hoare, named after the group of fungi that are "over-engineered for survival". Mozilla began sponsoring the project in 2009, and would employ a dozen engineers to work on it full time over the next ten years
So by 2013 it was already 7 years old. I very much doubt the original personal project was viewed as "a lot of sense" etc.
You’ll always easily find plenty of people that will say “that makes no sense”. But of people that worked in these sorts of fields, I imagine that, from the very start, there would have been significantly more than average approval for its goals, even if you wouldn’t expect it to succeed (such endeavours normally don’t). The niche Rust was targeting from the very beginning was one that was known to be underserved, and known to be rather important.
The GWT approach has its own downsides as well.
A) GWT is 20 years old and not similar to how modern transpilation works
B) What are the downsides?
The built in browser debugger is incredibly good. As long as the transpilation is simple and matches JS semantics you can still use the debugger. I haven't seen good debugging tools when using languages more distant from JS but I'd love to know if they've become viable.
You've been able to debug TypeScript (and anything else that transpiles to JS) natively in the browser for years using sourcemaps. That includes Dart, C#/F#, Go (as far as I know), and Python.
For the languages that target wasm instead, there are different debugging stories. Kotlin's is very good, Rust's is pretty immature.
Source maps are not sufficient to fully expose the semantics of the language being debugged to the debugger. You also need the expression evaluator (for stuff like Watch etc) to understand what it's debugging. And in cases where transpilation includes nontrivial mapping of data structures, you also need the ability to do that mapping in reverse to display the values.
Source maps work great for TS because it is just "JavaScript with types" at this point.
Or compile to wasm
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. :)
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)
Not a fan of YAML at all myself, but it's interesting that you like 'Yaml-like object structuring' yet then loathe 'Signifiant whitespace'? I mean that's basically YAML.
If you find this interesting, you might also wanna suss out https://rescript-lang.org/
It is a shame that Bloomberg and Facebook made the whole situation pretty confusing though, but still, it is a nice idea.
I agree, Rescript is an actual language rather than syntactic sugar.
So make sure you introduce this in your company; become the subject expert in it, invite everyone to very cool sessions demonstrating how cool it is, and secure your job until the next rewrite!
Looking at the examples, 1/5th of it looked neat, which probably would be best to submit a proposal for |> to the typescript committee rather than write another alienation.
This is a solution looking for a problem to solve. It introduces an alternative and does so as a superset; which is not only dangerous to existing code bases, but also silly.
> It introduces an alternative and does so as a superset; which is not only dangerous to existing code bases...
How so?
An alternative way to do something in a code base, for no other reason than style, is a recipe for technical debt. It builds up a larger cognitive load on the developers navigating and working the code base and induces more chances of bugs via half-refactors, or half-considerations.
As for the superset comment, I meant that if you introduce a completely different language, you probably have a valid reason; e.g. it does something different. Adding to an existing language with a superset without any need for it is also dangerous. It's not like it's a DSL at a higher level helping people get repetitive or scriptable things done faster. It's only an alternative, leading people down rabbit hole and second guessing with a lot more to remember.
I see. I misinterpreted your meaning of the word "existing" - I thought you were implying that, by virtue of the introduction of the alternative, any existing codebases would _immediately and instantly_ be worsened, whereas it seems that you're saying that continued (future) development _on_ existing codebases would deteriorate due to those alternatives. That's a fair criticism! I don't fall on the same point in the "alternatives provide better-focused tools <-> alternatives create cognitive load" spectrum as you do, but I see your point.
> It's not like it's a DSL at a higher level helping people get repetitive or scriptable things done faster.
I mean, I have to disagree with you there, because several of the comparisons on the main site page show >50% line-count reduction, and many of those that don't have (subjectivity-alert!) representations that more-clearly match my mental model of how the code works - so not only would I be executing fewer keystrokes to encode my idea (not the main bottleneck, but not irrelevant!), but also I'd be carrying out fewer mental translations to get from idea to code.
I tried to build the braceless syntax some years back (after I worked on CoffeeScript and it mostly died):
https://xixixao.github.io/lenientjs/
But this was before Prettier.
The real challenge in languages now is flawless LSP implementation, auto-formatter and AI completion. It’s possible for CoffeeScript like syntax, but just the existence of an auto-formatter mostly removes the need for dropping all the syntax.
I’d maybe take dropping of parens from if, to align with Rust, but even some of Rust’s syntax makes the language hard to read (if let bindings for example, which switch the flow from right to left), so I don’t consider it a golden standard to strive for anymore.
The other thing I would take is custom operators, not for any production code, but for building games and simulations, to simplify vector math.
I’ll check out the Civet IDE experience, but I suspect it’ll have large cons compared with TS.
The other thing that was hard to do with Lenient was to pass the thousands of tests in Babel to ensure the syntax handles every edge case.
Am I the only one that really dislikes the syntax choices here?
I feel like there is a specific kind of person that likes all this, and there is very little overlap between those people and the people that choose to use Typescript.
Kinda feels like someone was forced to work in Typescript and really wanted to scratch their own itch.
I must be a very specific kind of person. I love TypeScript, and loved CoffeeScript even more. I’m baffled by many of the comments here and excited to try Civet.
Nailed it
It appears to prioritize easier and faster typing over readability, which is a poor choice as programmers spend more time reading rather than writing code.
Strongly agree. This is unreadable, and find it hard to believe they included this as an example of something someone would want to do:
Having worked in Rust I love the pattern matching proposal. Having dabbled in Swift I like the single argument function part (though keep the brackets, please)
Much of the rest I could take or leave… but then is that just because I’m not familiar with them? Stuff like the pipe operator makes sense to me but it reminds me of .reduce(): there are a few legitimate uses of it but the vast majority will be entirely-too-smart—for-its-own-good show off coding.
I fell in love with pattern matching the first time I used Haskell. Having the feature is great, but I really don't like the syntax used here.
Nope! I'm also not convinced by it.
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.
Not so sure. JSX is already a transpilation language. Why target a language that's only supported as an input language for other compilers? I don't think this is an LLVM-type scenario.
As an example, Solid's JSX compiler changes multiple times in a year. It's better to target JSX than the compiled form. There are also many JSX compilers. (Even React ships with at least two.)
The pattern matching (TC39 stage 1) and pipeline operators (TC39 stage 2) look great, and I'd love to have those in TypeScript. It will probably take a loooong while for those features to be available in JavaScript, but I feel like I can live without those for now :-).
Fwiw it seems a lot of people really like the concept of "significant indentation". I'm thinking Python, YAML, Godot's GDScript. Not a lof of languages implement it but those that do seem to get a lot of users.
Interestingly, it seems like Erik Demain [1] is one of the contributors [2] of this project.
--
1: https://github.com/DanielXMoore/Civet/graphs/contributors
2: https://erikdemaine.org/
Note that the pipe operator is the rejected tacit pipes from TC-39. TC-39 made the (IMO) wrong choice of what they call hack style pipes (with a mandatory token) where instead of the pipe being a simple way to call unary functions. Civet seems to have picked the better pipes.
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)
The industry has deemed those languages completely unnecessary when we migrated away from coffeescript.
Syntactic sugar can’t be the only thing that makes a programming language.
C is syntactic sugar on top of assembly
That’s part of what C does, but it’s not the only thing.
Assembly adds mnemonics and a logical structure to machine code.
C largely does the same, but adds a cross-platform abstraction, mechanisms for organizing and sharing source code, a standard library, and various other things.
Syntactic sugar is such a broad and vague term that those features you mentioned could also technically be considered syntactic sugar. Instead of having to write harder longer code you can write easier and less code.
I think we can understand syntactic sugar as an alternative (hopefully more convenient, elegant, or pleasing) syntax for expressing something that can already be expressed.
That is, something that works the same but looks better (hopefully).
A cross-CPU abstraction, a preprocessor, a standard library all have certain elements of syntax in them, but go well beyond alternative syntax.
Assembly is syntactic sugar on top of Machine Code
C++ was, for a long time, syntactic sugar on top of C
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.
You get used to it. It's really nice in Elixir. I'm not a fan of the fat pipe though.
The pipe operator just flips the order of execution. In my experience this doesn't really impact debugging at all.
without the pipe operator you would write ` fun1(fun2(fun3(fun4(fun5(x, y), z, w), u), v)) `
The order of operations in this line is actually from right to left. Also it's not immediately obvious to which function the u parameter belongs to.
With the pipe operate you would write it in the order that the functions are actually called and you have the arguments in the same location as the function they belong to. So this would be written something like
` fun5(x, y) |> fun4(z, w) |> fun3(u) |> fun2(v) |> fun1() `
[dead]
I really, really dislike the Elixir/Ruby style of optional parentheses. Explicit is better than implicit!
I also absolutely cannot parse this, and while I'm open to the idea that eventually this would become readable, right now this just looks like word salad:
Yeah I agree, 'value min ceiling max floor' is a terrible example. Especially when making a case for improving readability.
That being said; regular written language (like in a book) has optimal readability. Therefore it makes sense for programming languages to lean towards that. If you could write code like: `draw 600 by 600 graph_of intersection_of data_set1 data_set2 in blue` it would be very easy for basically anybody to tell what the code does. This not only makes it easier for beginners and onboarding, it also reduces cognitive load, even for senior level engineers. In real terms this means less fatigue, less bugs, less time spent reviewing code, higher productivity.
That being said I also prefer the explicitness of parentheses, but I think that's because I'm used to needing that level of explicitness. But maybe there's some paradigm out there that makes it so we don't need that crutch
The problem with written language is that there's an inherent level of ambiguity. Now, this is fine for stuff read by humans, as we're pretty good at resolving that ambiguity using context and our own personal experience. Computers, however, are not good at ambiguity. They require explicitly defined syntax, as they just can't handle the ambiguous nature of natural language (at least, not without a shitload of processing power for a LLM)
Now, there's no reason we can't have an explicitly defined syntax that reads like normal written language. That's what SQL tries to do, after all. However, explicitly defined "natural" language has the tendency to get very unnatural very quickly. Human language is fluid and evolving in a way that a programming language just can't be. And no amount of emulating written language can eliminate the need to learn a programming language's syntax.
This just looks like it's trying to remove as much syntax as possible and as a consequence makes it harder for me to follow what's going on. Kind of like a write-only language.
I do not particularly like the lack of brackets everywhere. I think it is hard to know precedence perfectly and brackets ensure you do not make stupid mistakes.
Also there is the classic issue where you take an if statement that has a line one expression and you add a second line, but now because it didn't have brackets (and you are not using indentation style), you just introduced a bug. Or you have an if statement with an expression and you comment out the expression but not the if, then your next statement is now the if conditional expression, which is not obvious.
But we are using indentation style; that's one of the major design principles. In Civet, the body of an "if" can be multiple lines, and it's clear (from indentation) what they're nested under. Also, the body of an "if" statement can be empty, so if you comment out the body, the "if" doesn't apply to anything else. (This is an improvement over Python, which requires non-empty bodies, even if just to say "pass".)
I think there's a reason that Python is among the most popular programming languages, and part of it is the indentation-based syntax and lack of brackets. The core of Civet's syntax (originally inspired by CoffeeScript) is like a combination of JavaScript/TypeScript and Python, the two/three most popular programming languages.
But also, if you like brackets, you can include them! Most JavaScript/TypeScript code is also valid Civet. Just use the features you like.
>I think there's a reason that Python is among the most popular programming languages, and part of it is the indentation-based syntax and lack of brackets.
Perhaps, but IMO that will then be because it looks tempting at first glance like YAML. No matter how much Python I write, I never learned to enjoy this and the fact that I can't select inside/around brackets to quickly manipulate a scope is just so frustrating.
Python used an indentation-based syntax from the beginning and its syntax is particularly optimized for that. In particular, any block statement (formally, a statement followed by a "suite") would end with `:` and that's effectively the only place where a dangling `:` can happen [1], so you can easily recognize such statement from any directions.
In comparison, at least some people would find CoffeeScript and Civet to be hard to read because they solely rely on left-bearing indents. If my eye is pointing to the rightmost column and scanning to left, I wouldn't be sure about any nature of the line until the very first token and thus preceding indent is reached. This problem is not unique but can be somehow alleviated with some tweaks to the syntax. Ruby `if` for example is also prone to this issue but an explicit `end` token keeps it on track in most cases. CoffeeScript did nothing.
[1] The only other case is `lambda ...:` in parenthesized expressions. `lambda` in Python is quite exceptional in its syntax after all...
Sorry, I did misunderstood. I apologize and thanks for the clarification.
I didn't realize Civet is indentation-based like Python. That isn't so bad.
I guess it's kind of cool that you can create your own operators, but holy crap.
At least make them require a certain symbol at the start or something.JavaScript already has the best use of C syntax I’ve seen. Destructuring, JSON, functions. It’s so easy.
Civet has so many quality of life improvements! It's good that it exists sort of as a playground for ideas that could maybe in the future be adopted by JS itself, kinda like how it went with CoffeeScript.
The usual curse of syntax extensions is that they make a few good things and then a pile of bikeshedded nonsense in the same payload. These two sets differ from person to person, of course.
Dedent and object globs are useful imo and should be added to javascript. Maybe for-of with index too.
Also, I see no flow control in array literals, how do they plan to appeal to jsx/h users?
I think the most exciting aspect here is this might actually push JavaScript to add some missing features that can make a lot of difference, the pipeline operator for example can really improve the design of JavaScript code and has been proven already in several languages, C#, swift, kotlin to name a few I know
This is way less readable than normal TS. For that reason alone I doubt I’d use it.
I personally would love for 90% of these features to make it into TypeScript and eventually be ECMAScript standards. This is a taste of the world we could have, I don't understand all the hate towards this project.
Kudos to all building & contributing to this!
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.
I do miss 2 features from LiveScript:
1. `wxyz = [ 2 8 -5 5 ]` (commas optional for non callables)
2. `console.log \hello` (backslash strings)
Don't know how hard/compatible #1 is, but for #2 I had a tested PR that I could bring around.
(#3 was bulleted lists, but you already added that!)
Nice!
I loved LiveScript, but it got kinda lost in the wake of ES6.
They planned to add types, but never got around doing it (at least the last time I looked).
Nice, although what I really would like is Typescript in V8, and like Common Lisp, Dylan, Julia,...., having the JIT being aware of type annotations.
Additionally having the integration of Microsoft's AOT experiments with Typescript in MakeCode.
It would essentially involve changing the meaning of `: Type` and `as Type`. Basically, instead of ignoring type annotations at runtime, you'd have to throw when a cast fails.
This would also have other implications on the language design. Checking if an expression has a certain type at runtime would mean relying less on structural types to make these checks cheap.
I've been thinking about this exact language a lot recently, but it would not be the same as Typescript. A superset of JavaScript which can be statically optimized based on type information.
Fwiw, I don't think Assembly script is this language either. It's a completely different language than JavaScript with a superficially similar syntax.
Interesting but not sure how much do I buy it.
I would rather do with a stricter super set of TypeScript with some sugar/conveniences around its many verbose but useful features like branded types.
We're definitely looking for ways to improve ways to specify types! I think destructured typing [https://civet.dev/reference#destructured-typing] is already quite useful, especially for React. On the readability side, if/then/else [https://civet.dev/reference#conditional-types] seems easier to read than ?: ternaries, and "Partial Record Name, Info" seems easier to read than "Partial<Record<Name, Info>>" (implicit type arguments — https://civet.dev/reference#implicit-type-arguments). But we'd love to hear more ideas for features like branded types. Join us in Discord if you're interested!
Stuff like this does so well on HN.
Not because people want it, but because the "should this exist" argument does really consistently well in the algorithm.
Someone needs to mix this together with https://www.derw-lang.com/
The one thing i was hoping for from civet is the trailing closure syntax from swift, which would make jsx less needed and make similar dsl usage way more convenient. There is absolutely a place to get real world experience with syntax that did not make it or is not ready yet to be moved forward in standardisation.
This isn't just syntaxic sugar this is syntaxic diabetes
A lot of hate in the comments but I’m excited for this. I don’t think I’d ever inflict it on teammates, but this looks like a much nicer way to use functional idioms without making the jump to something like PureScript. I’ll definitely try this for personal projects.
Civet reminds me of Coffeescript but now in TypeScript.
This has made me even more convinced that the future of JavaScript is JavaScript.
We will be seeing JavaScript (natively) having all the types, features and proposals that TypeScript has and the industry will eventually move on from TypeScript.
I feel like typescript would officially deprecate itself if that ever happened. But I also feel like that won't ever happen. It would be cool if ES would get optional type annotations or something, even if they were ignored at runtime. But someone would still want a static type checker. TS does that, and if there's nothing to replace that part, then TS still has a viable mission statement.
So imagine what already happens and makes no impact to how I write code? How exciting!
I'd say just write Kotlin and compile to JavaScript at this point !
The more I've used Golang over the past few years the more I've come to appreciate the simplicity of its design and its lack of syntactic sugar.
It's made me realise that much of the sugar I was writing in other languages didn't make me more productive or my code more readable, in many cases it was actually the opposite and the usage of that sugar was more about writing more "succinct" code that was in the long run harder to understand and maintain.
I really like that everything is an expression. I know the extra work is happening in the background, but this kind of developer experience is really nice in my opinion.
|> is such a breath of fresh air when otherwise stuck without it, or worse being forced to do OOP style "design your abstraction before your logic".
The JS community needs a Martin Odersky who will one day drops a JS 3 with indent-significant syntax upon them. F# had the same transition too.
Since Typescript I wanted a Coffeescript with gradual typing. But I'm not sure if Civet isn't going to far into foreign syntax and shorthands for many things.
It probably won't share fate of Coffeescript. It won't get popular, influence TS and JS and fade into obsurity due to mostly fulfilling it's goal. I'm afraid it won't get popular enough to do that.
I see a language that compiles to JS. What makes this a superset of Typescript? Are there more types? A more powerful type system?
The linked page is pretty self explanatory. It’s TS with some extra features, many of which are already proposals for the language. Cool for an experiment, not good for a maintained codebase.
What does this do?
Is that a declaration or an invocation?It's doing a few things at once:
First line:
* `{min, max} := Math` is a destructuring declaration. It's similar to the destructuring assignment `{min, max} = Math` (i.e., `min = Math.min; max = Math.max`), but also declares min and max as const.
* The `operator` prefix means to treat min and max as new infix operators in the rest of the program.
Second line:
Given that min and max are infix operators, `value min ceiling max floor` is equivalent to `max(min(value, ceiling), floor)`. Yes, the latter is gross. That's why we like to write `value min ceiling max floor` instead. Think of it as "value minned with ceilling (i.e. capped at ceiling), then maxed with floor (i.e. prevented from going below floor)".
Don't understand the boner for infix notation, you find an usecase for it like... once every year?
It looks like rubyist brainrot
CoffeeScript never dies.
All I’m seeing here is alternative syntax for what’s already there.
I like some of it, but that’s hardly worth the increase in complexity.
In fact, having fewer aesthetic syntax choices is probably more of an improvement — cuts down on pointless/superficial coding style arguments, and leaves code generally more readable.
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.
I came to the same conclusion after the initial perl intoxication. Stable, regular constructs are much easier to parse and get back to than this pseudo-natural language. My worst confusion is python’s truly unreadable “x if cond else y” construct, especially when x and y are non-trivial. Putting a condition in between is not smart. Oh, now this gets me started on “is not”! Keeping calm…
One nice aspect of Python compared to TS/JS is the presence of list, set, map, and generator comprehensions. How far in that direction is civet likely to go? I see that arrays can be built from a for...of expression.
Or maybe just add a proper hygienic macros to ES6 and be done with it? Prior art: https://github.com/sweet-js/sweet-core
There is nothing I miss more in TS than pattern matching, so I came in with a lot of good will, but the syntax for it looks jarring to me. Might be a matter of taste, I'm not made for meaningful whitespaces
You can use braces if you like
Pattern matching: yes, it's needed and maybe the only useful feature in here.
The syntax and some other features, no. Some are even anti-features or "magic" that takes the actual semantics away from the developer.
Typescript with a dash of F#
"Everything is an expression" is low-key nice.
Scala has it. Other languages too.
I’ve been a rails developper my entire career and I’ve seen some sh*t with coffeescript monstrosities. I am so glad we moved away from that, and I won’t be going down that path again.
nextjs example seems broken, any idea what's going on?
unhandledRejection: Error: ENOENT: no such file or directory, open 'Civet/integration/unplugin-examples/components/button.civet'
also by default build is broken due to error TS5110: Option 'module' must be set to 'NodeNext' when option 'moduleResolution' is set to 'NodeNext'.
changing it still doesn't fix the not being able to import the civet button
Thanks for the report! This was tricky to track down, but I've got a fix: https://github.com/DanielXMoore/Civet/pull/1501
Looks Ruby-infused in terms of syntax. Or CoffeeScript.
But getting rid of the curly braces alone is enough to get me to adopt it over JS. I really hate writing JavaScript.
Finally. I had been waiting for something like this.
Superset of a superset so basically an Überset?
I was hoping for something more substantial. (such as list/object/monad/arrow comprehension)
Looking at all these proposals makes me think the TC39 will do anything but add types to the language.
As a F# and Elixir dev, I love it. This looks quite functional.
Like coffeescript, this looks lovely to write and horrible to read.
Not CoffeeScript again
This is pretty neat but I wonder how it compares to Arc...
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!)
It's transpilers all the way down...
No relation to CivetWeb
This has to be an error in the documentation:
<ul class="items">
Should be:
<ul className="items">
Depends on the framework. You can use class= in Preact.
Didn't they say it? If you turn on the react directive then it outputs the react prop.
Btw, you seem to have missed the new jsx transformer, className has been a thing of the past even in React.
a superset of a superset of a wrapper... interesting
It's time to stop. Too much mental overhead in front-end dev right now.
This looks like F#
looks like a coffeescript variant of elixir
Lol. A superset of a superset. I wonder how far we can go with this
Please no
This will encourage people to compose a write only, Perl-esque horrors. Euthanize this atrocious abomination right away.
We need a language that compiles to js with strong typing not another ts!
Like Haskell or F#? Already exist.
no please
Just dont….
This is seriously triggering my CoffeeScript PTSD.
Nope
What a mess.
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. 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.