Live data from Hacker News

CoffeeScript for TypeScript

civet.dev

141–143 of 143 posts

Re: CoffeeScript for TypeScript

#141
post #95

Earlier quoted context omitted.

I love me some lisp, but I definitely prefer my JS-hosted code to be as close to JS language and semantics as possible (and that’s after a few years working in ClojureScript). Then again I’m commenting in a thread about an article with CoffeeScript in the title so I’m probably the weird one here.

Have you considered https://github.com/squint-cljs/squint ? Personally I couldn't let go of Clojure's other advantages but at least using the syntax would let you step off the syntax churn bus

No, unfortunately the greener pastures I found have type annotations. I miss the parentheses like hell, and I miss the actual state semantics of Clojure even more. But I wouldn’t give up static types for any of that. If I explore lisps again I’m going to start with Typed Racket.

Re: CoffeeScript for TypeScript

#142
post #104

Is this an April fools joke? You compile Coffeescript to Typescript to JavaScript to bytecode. What problem ist actually solved by being able to compile pseudo-languages like Coffeescript or Typescript into each other?

I used to use CoffeeScript because the syntax was more convenient. I could do the same thing with less code. Less code can mean less maintenance (although some people have said CoffeeScript can overdo this...)

Now I use TypeScript to get the benefit of type-checking. It really helps catch silly little mistakes.

I would use Civet just to be able to use the new pipe operator syntax.

There are even compilers that compile future versions of JS into the current version of JS so future language features can be used in current browsers.

I've heard JS is the new assembly language.

Re: CoffeeScript for TypeScript

#143
post #129

Earlier quoted context omitted.

I agree. The Rust foundation (or Mozilla's Rust Team in the early stages) tried out a sigil heavy approach in the beginning, but they ultimately made the decision to steer Rust away from being overloaded with single character keywords of differing significance. Sadly, with Steve Klabnik's withdrawal from the core Team, the current maintainers are on a path to repeat these mistakes.

> the current maintainers are on a path to repeat these mistakes Do you recall specific RFCs that are leaning in this direction?

Yes and no.

A good example would be the behavior of the tilde operator. Another would be the current drafting process of keyword generics.

Post reply on HN