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

221–230 of 237 posts

Re: Civet: A Superset of TypeScript

#221

Post by int_19h »

smt88 wrote: post #129
Yahivin wrote: post #87

Earlier quoted context omitted.

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.

Re: Civet: A Superset of TypeScript

#222

Post by chrismorgan »

int_19h wrote: post #218
chrismorgan wrote: post #188

Earlier quoted context omitted.

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

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.

Re: Civet: A Superset of TypeScript

#223

Post by pjmlp »

MajimasEyepatch wrote: post #42
emmanueloga_ wrote: post #37

Earlier quoted context omitted.

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…

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.

Re: Civet: A Superset of TypeScript

#224

Post by mistercow »

scotty79 wrote: post #170
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…

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.

Re: Civet: A Superset of TypeScript

#225

Post by jamincan »

btown wrote: post #48
rjknight wrote: post #20

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…

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.

Re: Civet: A Superset of TypeScript

#226

Post by gr4vityWall »

f33d5173 wrote: post #177
gr4vityWall wrote: post #135

Earlier quoted context omitted.

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…

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.

Re: Civet: A Superset of TypeScript

#227

Post by scubbo »

keyle wrote: post #90
scubbo wrote: post #78

Earlier quoted context omitted.

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

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.

Re: Civet: A Superset of TypeScript

#228

Post by troupo »

chrismorgan wrote: post #102
troupo wrote: post #98

Earlier quoted context omitted.

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

Re: Civet: A Superset of TypeScript

#229

Post by chrisandchris »

progx wrote: post #108
vivzkestrel wrote: post #86

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.

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.

Re: Civet: A Superset of TypeScript

#230

Post by edemaine »

tough wrote: post #216

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
Post reply on HN