Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Civet: A Superset of TypeScript

civet.dev

Post reply on HN
Print view View original

211–220 of 237 posts

Re: Civet: A Superset of TypeScript

#211

Post by dhruvrajvanshi »

pjmlp wrote: post #186

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.

Re: Civet: A Superset of TypeScript

#213

Post by tholm »

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.

Re: Civet: A Superset of TypeScript

#214

Post by edemaine »

recursive wrote: post #176
edemaine wrote: post #65

Earlier quoted context omitted.

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'…

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

Re: Civet: A Superset of TypeScript

#215

Post by dimal »

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.

Re: Civet: A Superset of TypeScript

#216

Post by tough »

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

Re: Civet: A Superset of TypeScript

#218

Post by int_19h »

chrismorgan wrote: post #188
mistercow wrote: post #56

Earlier quoted context omitted.

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

> 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, a…

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

Re: Civet: A Superset of TypeScript

#219

Post by int_19h »

bhouston wrote: post #23
lgas wrote: post #18

Earlier quoted context omitted.

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.

Re: Civet: A Superset of TypeScript

#220

Post by int_19h »

wruza wrote: post #174
progx wrote: post #108

Earlier quoted context omitted.

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.

I think it’s time to reveal the shocking ancient knowledge people weren’t ready to deal with before: textmate snippets. foro for ($1 of $2) { $0 } touc toUpperCase() le length map map(x => $0) 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.

CoPilot completion is much more extensive than any of these.
Post reply on HN