15 ms·

Civet: A Superset of TypeScript

249 points by revskill 2y ago

vosper 2y ago
I see a language that compiles to JS. What makes this a superset of Typescript? Are there more types? A more powerful type system?
- afavour 2y ago
  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.
epolanski 2y ago
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.
- edemaine 2y ago
  We're definitely looking for ways to improve ways to specify types! I think destructured typing [https://civet.dev/reference#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 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 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!
marcofiset 2y ago
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.
- boredtofears 2y ago
  C is syntactic sugar on top of assembly
  - 082349872349872 2y ago
    C++ was, for a long time, syntactic sugar on top of C
  - voidUpdate 2y ago
    Assembly is syntactic sugar on top of Machine Code
  - jmull 2y ago
    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.
    - legacynl 2y ago
      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.
      - jmull 2y ago
        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.
c0balt 2y ago
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.
- botanical76 2y ago
  You get used to it. It's really nice in Elixir. I'm not a fan of the fat pipe though.
- paxcoder 2y ago
  [dead]
- legacynl 2y ago
  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() `
danpalmer 2y ago
Civet. Kopi luwak coffee. It's CoffeeScript. I wrote a bunch of CoffeeScript back in the day, and everyone I've spoken to about it feels the same, that it was a bad idea in hindsight, and a language dead end. The language was only syntactic sugar, and by not bringing anything else to the table, was unconvincing for ports and support in other ecosystems. It now seems that most codebases have been decaffeinated though. Civet looks like it adds a little more, but the things that aren't just syntactic sugar are just a grab bag of TC39 proposals. I'm a big fan of language proposals in general, and having a language that adds all of them for research purposes seems like a nice thing to have. Haskell did this well with GHC language options. Is this a research language though? It seems not. What's the benefit over Typescript? A few less characters? Faster TC39 proposal integrations? What happens if a proposal is rejected, does it get removed from Civet? What's the cost? What happens as Typescript and Civet diverge? What if the TS tooling doesn't support Civet features?
- lgas 2y ago
  I think everyone mostly agrees that CoffeeScript was a dead end, but I think it drove at lot of innovation at the time. Hopefully Civet can do the same, even if it ends up being another dead end.
  - bhouston 2y ago
    CoffeScript was really good at driving innovation in JavaScript. The arrow operator, string literals, and for...in/for...of seemed to be driven specifically from CoffeeScript's innovations.
    - int_19h 2y ago
      Almost all of these were features of other mainstream PLs at the time, so it's questionable whether JS really borrowed them from CS or directly from those others. Especially since the latter is clearly true for some other features such as async/await.
  - danpalmer 2y ago
    What makes Civet more likely to drive that innovation than TC39 proposals themselves?
SSchick 2y ago
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.
- smt88 2y ago
  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.
  - Yahivin 2y ago
    The GWT approach has its own downsides as well.
    - smt88 2y ago
      A) GWT is 20 years old and not similar to how modern transpilation works B) What are the downsides?
      - Yahivin 2y ago
        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.
        smt88 2y ago
        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.
fabiospampinato 2y ago
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.
Kab1r 2y ago
Am I the only one that really dislikes the syntax choices here?
- antoineMoPa 2y ago
  Nope! I'm also not convinced by it.
- mpowaga 2y ago
  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.
  - pavel_lishin 2y ago
    Strongly agree. This is unreadable, and find it hard to believe they included this as an example of something someone would want to do: value min ceiling max floor
- afavour 2y ago
  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.
  - Kab1r 2y ago
    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.
- Aeolun 2y ago
  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.
colesantiago 2y ago
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.
- recursive 2y ago
  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.
- nsonha 2y ago
  So imagine what already happens and makes no impact to how I write code? How exciting!
pyrelight 2y ago
It's time to stop. Too much mental overhead in front-end dev right now.
paulddraper 2y ago
CoffeeScript never dies.
gregwebs 2y ago
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 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.
- recursive 2y ago
  JSX has a spec. This thing they're doing... I don't know what it is, but it ain't JSX.
  - edemaine 2y ago
    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.
    - recursive 2y ago
      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.
      - edemaine 2y ago
        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.)
rjknight 2y ago
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.
- btown 2y ago
  For “everything is an expression” https://github.com/tc39/proposal-do-expressions https://github.com/tc39/proposal-do-expressions may be of interest, though discussion seems to have paused.
  - jamincan 2y ago
    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.
    - edemaine 2y ago
      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.
- dgoldstein0 2y ago
  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.
hyperhello 2y ago
JavaScript already has the best use of C syntax I’ve seen. Destructuring, JSON, functions. It’s so easy.
diath 2y ago
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.
- bhouston 2y ago
  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.
  - edemaine 2y ago
    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.
    - lifthrasiir 2y ago
      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...
coolThingsFirst 2y ago
Just dont….
- williamstein 2y ago
  This is seriously triggering my CoffeeScript PTSD.
emmanueloga_ 2y ago
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 https://github.com/DanielXMoore/Civet/graphs/contributors 2: https://erikdemaine.org/ https://erikdemaine.org/
- runarberg 2y ago
  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.
hbbio 2y ago
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.
adamwong246 2y ago
Someone needs to mix this together with https://www.derw-lang.com/ https://www.derw-lang.com/
smilekzs 2y ago
I know this hasn't been updated, and I know it's a fork of CoffeeScript, but https://livescript.net/ https://livescript.net/ has had a lot of the "magic" syntax here for quite a while.
- edemaine 2y ago
  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.
  - k__ 2y ago
    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).
  - p2edwards 2y ago
    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!)
jcmontx 2y ago
This looks like F#
keyle 2y ago
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.
- scubbo 2y ago
  > It introduces an alternative and does so as a superset; which is not only dangerous to existing code bases... How so?
  - keyle 2y ago
    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.
    - scubbo 2y ago
      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.
adamtaylor_13 2y ago
This is way less readable than normal TS. For that reason alone I doubt I’d use it.
koolba 2y ago
What does this do? operator {min, max} := Math value min ceiling max floor Is that a declaration or an invocation?
- ht85 2y ago
  It looks like rubyist brainrot
- edemaine 2y ago
  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)".
  - nsonha 2y ago
    Don't understand the boner for infix notation, you find an usecase for it like... once every year?
01HNNWZ0MV43FF 2y ago
No relation to CivetWeb
omeid2 2y ago
If you find this interesting, you might also wanna suss out https://rescript-lang.org/ 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.
- eterps 2y ago
  I agree, Rescript is an actual language rather than syntactic sugar.
mhh__ 2y ago
|> 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".
Yahivin 2y ago
This is pretty neat but I wonder how it compares to Arc...
paulddraper 2y ago
"Everything is an expression" is low-key nice. Scala has it. Other languages too.
beders 2y ago
What's the compilation time impact of that?
- edemaine 2y ago
  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!)
inlined 2y ago
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)
- miffy900 2y ago
  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.
dang 2y ago
Related: CoffeeScript for TypeScript - https://news.ycombinator.com/item?id=34962782 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 https://news.ycombinator.com/item?id=33834312 - Dec 2022 (3 comments) Civet: The CoffeeScript of TypeScript - https://news.ycombinator.com/item?id=33323574 https://news.ycombinator.com/item?id=33323574 - Oct 2022 (17 comments) The CoffeeScript of TypeScript - https://news.ycombinator.com/item?id=33198931 https://news.ycombinator.com/item?id=33198931 - Oct 2022 (2 comments)
vivzkestrel 2y ago
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
- rochak 2y ago
  Pretty much what I feel about Rust
  - aurareturn 2y ago
    Explain more?
- progx 2y ago
  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 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.
  - nine_k 2y ago
    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.)
  - mplewis 2y ago
    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.
    - Yahivin 2y ago
steve_adams_86 2y ago
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.
worldsayshi 2y ago
This has to be an error in the documentation: <ul class="items"> Should be: <ul className="items">
- zarzavat 2y ago
  Depends on the framework. You can use class= in Preact.
- nsonha 2y ago
  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.
fire_lake 2y ago
Typescript with a dash of F#
meandmycode 2y ago
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
melodyogonna 2y ago
Lol. A superset of a superset. I wonder how far we can go with this
Myrmornis 2y ago
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.
north_african 2y ago
We need a language that compiles to js with strong typing not another ts!
- nsonha 2y ago
  Like Haskell or F#? Already exist.
vekker 2y ago
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).
- koromak 2y ago
  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.
- tootie 2y ago
  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.
xixixao 2y ago
I tried to build the braceless syntax some years back (after I worked on CoffeeScript and it mostly died): https://xixixao.github.io/lenientjs/ 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.
- xixixao 2y ago
  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.
erulabs 2y ago
Like coffeescript, this looks lovely to write and horrible to read.
gr__or 2y ago
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
- n_plus_1_acc 2y ago
  You can use braces if you like
deleted 2y ago
[deleted]
_jplc 2y ago
Not CoffeeScript again
nsonha 2y ago
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.
Nekorosu 2y ago
Or maybe just add a proper hygienic macros to ES6 and be done with it? Prior art: https://github.com/sweet-js/sweet-core https://github.com/sweet-js/sweet-core
jmull 2y ago
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.
skerit 2y ago
I guess it's kind of cool that you can create your own operators, but holy crap. operator {min, max} := Math value min ceiling max floor At least make them require a certain symbol at the start or something.
jFriedensreich 2y ago
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.
lakomen 2y ago
Please no
Garlef 2y ago
I was hoping for something more substantial. (such as list/object/monad/arrow comprehension)
dzonga 2y ago
looks like a coffeescript variant of elixir
gr4vityWall 2y ago
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. :)
mmaniac 2y ago
It's transpilers all the way down...
mattacular 2y ago
Nope
tylerchilds 2y ago
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.
- wruza 2y ago
  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…
wruza 2y ago
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?
rty32 2y ago
What a mess. switch x 0 console.log("zero") /^\s+$/ console.log("whitespace") [{type: "text", content}, ...rest] console.log("leading text", content) Yes, looks very cool, but nobody should ever write code like this, especially not in strictly typed code. And it is extremely rare you need to do similar pattern matching. For the object case, you would want to define interfaces and type guards in TypeScript anyway. This feels like poor man's pattern matching compared to Python and Rust. items = for item of items if item.length item.toUpperCase() else "<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.
throwaway918299 2y ago
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.
Kibranoz 2y ago
This isn't just syntaxic sugar this is syntaxic diabetes
deskr 2y ago
This will encourage people to compose a write only, Perl-esque horrors. Euthanize this atrocious abomination right away.
scotty79 2y ago
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.
bluelightning2k 2y ago
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.
pier25 2y ago
Looking at all these proposals makes me think the TC39 will do anything but add types to the language.
pavel_lishin 2y ago
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: value min ceiling max floor
- legacynl 2y ago
  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
  - ARandumGuy 2y ago
    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.
PhotoAomicLab 2y ago
no please
LelouBil 2y ago
I'd say just write Kotlin and compile to JavaScript at this point !
wg0 2y ago
Superset of a superset so basically an Überset?
pjmlp 2y ago
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.
- dhruvrajvanshi 2y ago
  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.
insane_dreamer 2y ago
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.
deleted 2y ago
[deleted]
guluarte 2y ago
a superset of a superset of a wrapper... interesting
ssalka 2y ago
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!
kizer 2y ago
Finally. I had been waiting for something like this.
tholm 2y ago
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.
dimal 2y ago
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.
tough 2y ago
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
- edemaine 2y ago
  Thanks for the report! This was tricky to track down, but I've got a fix: https://github.com/DanielXMoore/Civet/pull/1501 https://github.com/DanielXMoore/Civet/pull/1501
aloisdg 2y ago
As a F# and Elixir dev, I love it. This looks quite functional.

249 points by revskill 2y ago

I see a language that compiles to JS. What makes this a superset of Typescript? Are there more types? A more powerful type system?

afavour 2y ago
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.

epolanski 2y ago

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.

edemaine 2y ago
We're definitely looking for ways to improve ways to specify types! I think destructured typing [https://civet.dev/reference#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 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 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!

marcofiset 2y ago

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.

boredtofears 2y ago
C is syntactic sugar on top of assembly
- 082349872349872 2y ago
  C++ was, for a long time, syntactic sugar on top of C
- voidUpdate 2y ago
  Assembly is syntactic sugar on top of Machine Code
- jmull 2y ago
  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.
  - legacynl 2y ago
    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.
    - jmull 2y ago
      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.

c0balt 2y ago

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.

botanical76 2y ago
You get used to it. It's really nice in Elixir. I'm not a fan of the fat pipe though.
paxcoder 2y ago
[dead]
legacynl 2y ago
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() `

danpalmer 2y ago

Civet. Kopi luwak coffee. It's CoffeeScript. I wrote a bunch of CoffeeScript back in the day, and everyone I've spoken to about it feels the same, that it was a bad idea in hindsight, and a language dead end. The language was only syntactic sugar, and by not bringing anything else to the table, was unconvincing for ports and support in other ecosystems. It now seems that most codebases have been decaffeinated though. Civet looks like it adds a little more, but the things that aren't just syntactic sugar are just a grab bag of TC39 proposals. I'm a big fan of language proposals in general, and having a language that adds all of them for research purposes seems like a nice thing to have. Haskell did this well with GHC language options. Is this a research language though? It seems not. What's the benefit over Typescript? A few less characters? Faster TC39 proposal integrations? What happens if a proposal is rejected, does it get removed from Civet? What's the cost? What happens as Typescript and Civet diverge? What if the TS tooling doesn't support Civet features?

lgas 2y ago
I think everyone mostly agrees that CoffeeScript was a dead end, but I think it drove at lot of innovation at the time. Hopefully Civet can do the same, even if it ends up being another dead end.
- bhouston 2y ago
  CoffeScript was really good at driving innovation in JavaScript. The arrow operator, string literals, and for...in/for...of seemed to be driven specifically from CoffeeScript's innovations.
  - int_19h 2y ago
    Almost all of these were features of other mainstream PLs at the time, so it's questionable whether JS really borrowed them from CS or directly from those others. Especially since the latter is clearly true for some other features such as async/await.
- danpalmer 2y ago
  What makes Civet more likely to drive that innovation than TC39 proposals themselves?

SSchick 2y ago

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.

smt88 2y ago
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.
- Yahivin 2y ago
  The GWT approach has its own downsides as well.
  - smt88 2y ago
    A) GWT is 20 years old and not similar to how modern transpilation works B) What are the downsides?
    - Yahivin 2y ago
      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.
      - smt88 2y ago
        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.

fabiospampinato 2y ago

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.

Kab1r 2y ago

Am I the only one that really dislikes the syntax choices here?

antoineMoPa 2y ago
Nope! I'm also not convinced by it.
mpowaga 2y ago
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.
- pavel_lishin 2y ago
  Strongly agree. This is unreadable, and find it hard to believe they included this as an example of something someone would want to do: value min ceiling max floor
afavour 2y ago
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.
- Kab1r 2y ago
  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.
Aeolun 2y ago
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.

colesantiago 2y ago

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.

recursive 2y ago
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.
nsonha 2y ago
So imagine what already happens and makes no impact to how I write code? How exciting!

pyrelight 2y ago

It's time to stop. Too much mental overhead in front-end dev right now.

paulddraper 2y ago

CoffeeScript never dies.

gregwebs 2y ago

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

recursive 2y ago
JSX has a spec. This thing they're doing... I don't know what it is, but it ain't JSX.
- edemaine 2y ago
  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.
  - recursive 2y ago
    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.
    - edemaine 2y ago
      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.)

rjknight 2y ago

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.

btown 2y ago
For “everything is an expression” https://github.com/tc39/proposal-do-expressions https://github.com/tc39/proposal-do-expressions may be of interest, though discussion seems to have paused.
- jamincan 2y ago
  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.
  - edemaine 2y ago
    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.
dgoldstein0 2y ago
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.

hyperhello 2y ago

JavaScript already has the best use of C syntax I’ve seen. Destructuring, JSON, functions. It’s so easy.

diath 2y ago

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.

bhouston 2y ago
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.
- edemaine 2y ago
  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.
  - lifthrasiir 2y ago
    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...

coolThingsFirst 2y ago

Just dont….

williamstein 2y ago
This is seriously triggering my CoffeeScript PTSD.

emmanueloga_ 2y ago

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 https://github.com/DanielXMoore/Civet/graphs/contributors 2: https://erikdemaine.org/ https://erikdemaine.org/

runarberg 2y ago
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.

hbbio 2y ago

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.

adamwong246 2y ago

Someone needs to mix this together with https://www.derw-lang.com/ https://www.derw-lang.com/

smilekzs 2y ago

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

edemaine 2y ago
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.
- k__ 2y ago
  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).
- p2edwards 2y ago
  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!)

jcmontx 2y ago

This looks like F#

keyle 2y ago

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.

scubbo 2y ago
> It introduces an alternative and does so as a superset; which is not only dangerous to existing code bases... How so?
- keyle 2y ago
  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.
  - scubbo 2y ago
    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.

adamtaylor_13 2y ago

This is way less readable than normal TS. For that reason alone I doubt I’d use it.

koolba 2y ago

What does this do? operator {min, max} := Math value min ceiling max floor Is that a declaration or an invocation?

ht85 2y ago
It looks like rubyist brainrot
edemaine 2y ago
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)".
- nsonha 2y ago
  Don't understand the boner for infix notation, you find an usecase for it like... once every year?

01HNNWZ0MV43FF 2y ago

No relation to CivetWeb

omeid2 2y ago

If you find this interesting, you might also wanna suss out https://rescript-lang.org/ 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.

eterps 2y ago
I agree, Rescript is an actual language rather than syntactic sugar.

mhh__ 2y ago

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

Yahivin 2y ago

This is pretty neat but I wonder how it compares to Arc...

paulddraper 2y ago

"Everything is an expression" is low-key nice. Scala has it. Other languages too.

beders 2y ago

What's the compilation time impact of that?

edemaine 2y ago
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!)

inlined 2y ago

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)

miffy900 2y ago
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.

dang 2y ago

Related: CoffeeScript for TypeScript - https://news.ycombinator.com/item?id=34962782 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 https://news.ycombinator.com/item?id=33834312 - Dec 2022 (3 comments) Civet: The CoffeeScript of TypeScript - https://news.ycombinator.com/item?id=33323574 https://news.ycombinator.com/item?id=33323574 - Oct 2022 (17 comments) The CoffeeScript of TypeScript - https://news.ycombinator.com/item?id=33198931 https://news.ycombinator.com/item?id=33198931 - Oct 2022 (2 comments)

vivzkestrel 2y ago

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

rochak 2y ago
Pretty much what I feel about Rust
- aurareturn 2y ago
  Explain more?
progx 2y ago
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 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.
- nine_k 2y ago
  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.)
- mplewis 2y ago
  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.
  - Yahivin 2y ago

steve_adams_86 2y ago

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.

worldsayshi 2y ago

This has to be an error in the documentation: <ul class="items"> Should be: <ul className="items">

zarzavat 2y ago
Depends on the framework. You can use class= in Preact.
nsonha 2y ago
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.

fire_lake 2y ago

Typescript with a dash of F#

meandmycode 2y ago

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

melodyogonna 2y ago

Lol. A superset of a superset. I wonder how far we can go with this

Myrmornis 2y ago

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.

north_african 2y ago

We need a language that compiles to js with strong typing not another ts!

nsonha 2y ago
Like Haskell or F#? Already exist.

vekker 2y ago

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

koromak 2y ago
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.
tootie 2y ago
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.

xixixao 2y ago

I tried to build the braceless syntax some years back (after I worked on CoffeeScript and it mostly died): https://xixixao.github.io/lenientjs/ 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.

xixixao 2y ago
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.

erulabs 2y ago

Like coffeescript, this looks lovely to write and horrible to read.

gr__or 2y ago

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

n_plus_1_acc 2y ago
You can use braces if you like

deleted 2y ago

[deleted]

_jplc 2y ago

Not CoffeeScript again

nsonha 2y ago

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.

Nekorosu 2y ago

Or maybe just add a proper hygienic macros to ES6 and be done with it? Prior art: https://github.com/sweet-js/sweet-core https://github.com/sweet-js/sweet-core

jmull 2y ago

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.

skerit 2y ago

I guess it's kind of cool that you can create your own operators, but holy crap. operator {min, max} := Math value min ceiling max floor At least make them require a certain symbol at the start or something.

jFriedensreich 2y ago

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.

lakomen 2y ago

Please no

Garlef 2y ago

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

dzonga 2y ago

looks like a coffeescript variant of elixir

gr4vityWall 2y ago

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

mmaniac 2y ago

It's transpilers all the way down...

mattacular 2y ago

Nope

tylerchilds 2y ago

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.

wruza 2y ago
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…

wruza 2y ago

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?

rty32 2y ago

What a mess. switch x 0 console.log("zero") /^\s+$/ console.log("whitespace") [{type: "text", content}, ...rest] console.log("leading text", content) Yes, looks very cool, but nobody should ever write code like this, especially not in strictly typed code. And it is extremely rare you need to do similar pattern matching. For the object case, you would want to define interfaces and type guards in TypeScript anyway. This feels like poor man's pattern matching compared to Python and Rust. items = for item of items if item.length item.toUpperCase() else "<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.

throwaway918299 2y ago

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.

Kibranoz 2y ago

This isn't just syntaxic sugar this is syntaxic diabetes

deskr 2y ago

This will encourage people to compose a write only, Perl-esque horrors. Euthanize this atrocious abomination right away.

scotty79 2y ago

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.

bluelightning2k 2y ago

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.

pier25 2y ago

Looking at all these proposals makes me think the TC39 will do anything but add types to the language.

pavel_lishin 2y ago

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: value min ceiling max floor

legacynl 2y ago
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
- ARandumGuy 2y ago
  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.

PhotoAomicLab 2y ago

no please

LelouBil 2y ago

I'd say just write Kotlin and compile to JavaScript at this point !

wg0 2y ago

Superset of a superset so basically an Überset?

pjmlp 2y ago

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.

dhruvrajvanshi 2y ago
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.

insane_dreamer 2y ago

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.

deleted 2y ago

[deleted]

guluarte 2y ago

a superset of a superset of a wrapper... interesting

ssalka 2y ago

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!

kizer 2y ago

Finally. I had been waiting for something like this.

tholm 2y ago

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.

dimal 2y ago

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.

tough 2y ago

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

edemaine 2y ago
Thanks for the report! This was tricky to track down, but I've got a fix: https://github.com/DanielXMoore/Civet/pull/1501 https://github.com/DanielXMoore/Civet/pull/1501

aloisdg 2y ago

As a F# and Elixir dev, I love it. This looks quite functional.