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

161–170 of 237 posts

Re: Civet: A Superset of TypeScript

#161

Post by scotty79 »

danpalmer wrote: post #43
arp242 wrote: post #26

Earlier quoted context omitted.

> I wrote a bunch of CoffeeScript back in the day, and everyone I've spoken to about it feels the same, that it was a bad idea in hindsight I don't think it was a bad idea in hindsight. JS of the era was a pain to use; CoffeeScript made writing and reading things much easier, which is the reason it took off. Since then things changed and many "CoffeeScript features" are now "JavaScript features". Only with knowledge…

> CoffeeScript made writing and reading things much easier My point is that it kinda didn't. It looked prettier on the surface, but didn't actually solve any of the deeper problems of writing JavaScript. To write CoffeeScript you had to still know JavaScript and all its oddities. TypeScript solved those problems, and that's why it has taken off and had a meteoric rise to the point that it's practically synonymous wit…

> TypeScript solved those problem

I don't think TS removed any peculiarities of JS. It just forced you to actually learn them which JS and CS didn't do.

Re: Civet: A Superset of TypeScript

#162

Post by Yahivin »

mplewis wrote: post #141
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.

From my experience, I predict that LLM code completion will not work very well when using a language like Civet. Copilot is good when working with something where the idiomatic patterns are common, widespread, and hard to screw up. Civet has low adoption, uses much looser syntax (bracing, whitespace), and lacks the rigor of common TypeScript code.

I was pleasantly surprised with how well Copilot picked it up. Civet doesn't have that many truly new language features, most of them are from existing languages and used in a similar way. Copilot is really good at matching what you are doing near the completion so I was impressed with how well it did with a new language.

Re: Civet: A Superset of TypeScript

#163

Post by akdev1l »

smt88 wrote: post #131
chrismorgan wrote: post #101

Earlier quoted context omitted.

That approach only makes any sense if you have broadly compatible semantics; otherwise execution will pay a heavy penalty (CPU usage, memory usage, bundle size). And let me tell you, your “Rust, Kotlin, Python, probably many more” don’t transpile to JS well. If you genuinely mean transpiling as distinct from compiling , I think you could even reasonably say that it’s simply not possible for many languages due to fund…

I should have referenced compiling to Wasm as well, which is what languages with very different semantics to JS (like Rust, the CLR family, and the JVM family) all do.

Working with WASM isn’t really that good for interactive pages with dynamic DOM.

If you don’t mind I guess you could just render to a canvas but then you lose a ton of functionality provided by the browser. (Eg: making a responsive page in WASM seems hard)

It seems to me for most web applications JS is the only real alternative as of now

Re: Civet: A Superset of TypeScript

#165

Post by pavel_lishin »

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

Re: Civet: A Superset of TypeScript

#167

Post by pavel_lishin »

mpowaga wrote: post #16
Kab1r wrote: post #10

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

It appears to prioritize easier and faster typing over readability, which is a poor choice as programmers spend more time reading rather than writing code.

Strongly agree. This is unreadable, and find it hard to believe they included this as an example of something someone would want to do:

    value min ceiling max floor

Re: Civet: A Superset of TypeScript

#168

Post by jakub_g »

dgoldstein0 wrote: post #49
danpalmer wrote: post #43

Earlier quoted context omitted.

> CoffeeScript made writing and reading things much easier My point is that it kinda didn't. It looked prettier on the surface, but didn't actually solve any of the deeper problems of writing JavaScript. To write CoffeeScript you had to still know JavaScript and all its oddities. TypeScript solved those problems, and that's why it has taken off and had a meteoric rise to the point that it's practically synonymous wit…

Coffeescript had some great features: classes, array comprehensions, default parameter values, arrow functions, optional chaining. Many of these eventually made it to ecmascript. And then it ruined us with implicit returns, optional parentheses and brackets, and the isnt vs is not fiasco. I worked a lot with Python and coffeescript at the same time back in the day. In Python you mess up your whitespace and 95% of the…

> implicit returns

Oh man, that brings memories. When I joined a coffee-shop (pun intended), and learnt about implicit returns, I was screaming internally until we got rid of all the coffee (which was massive long team-wide migration effort that took like 2y to finish).

Once the migration was finished, everyone was so tired, that at the mere proposal of using TypeScript instead of JS the whole team would just roll their eyes and silently say "nope" in terror. Which was a shame, because large JS codebases are difficult to maintain and explore.

Re: Civet: A Superset of TypeScript

#169

Post by scotty79 »

lifthrasiir wrote: post #71
edemaine wrote: post #53

Earlier quoted context omitted.

One of the Civet devs here. To me, the main benefit of Civet is the ability to rapidly add useful features to the language, while preserving all the benefits of TS (tooling, etc.). We're constantly coming up with ideas — from TC39 proposals, other languages, or general brainstorming — and implementing them quickly. For example, we recently added pattern matching when catching exceptions, which took just a couple of h…

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

I love getting rid of visual noise of brackets around code blocks. It's as silly debate as tabs vs spaces. It should be a text editor setting if you prefer to see them or hide and see just indents instead.

Re: Civet: A Superset of TypeScript

#170

Post by scotty79 »

mistercow wrote: post #56
danpalmer wrote: post #6

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

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