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

Cooperative C++ Evolution – Toward a TypeScript for C++

herbsutter.com

Post reply on HN
Print view View original

121–130 of 209 posts

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#121

Post by wsve »

eviks wrote: post #90
jmull wrote: post #55

I'm heartened by the success of the Typescript model of improving things when there's a deficiency/problem. The alternate approach (which is extremely popular unfortunately), is to throw it all out and rebuild everything from scratch. I guess it's fun and exciting, which attracts developers, but it takes a long time to achieve any level of maturity and are hard to sustain (the people who are in it for the fun and exc…

The alternate approach is also popular because there is no success in the typescript model, as in critical deficiencies get unfixed for decades (with some of the same "not fun" challenges )

There is no success in the Typescript model...? What on earth are you needing that off of?

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#122

Post by suby »

synergy20 wrote: post #94
timmg wrote: post #50

Earlier quoted context omitted.

> After the talk, the activity on it is nearly zero since then... Is that true? Seems like he is actively working on it: https://github.com/hsutter/cppfront/commits/main

compare to carbon it is way much less

But Carbon doesn't have a working compiler or prototype version I can download and try out does it? Compared to cppfront where I have downloaded, built, and compiled / run some demo code.

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#123

Post by IAmLiterallyAB »

pjmlp wrote: post #34
logicchains wrote: post #28

Earlier quoted context omitted.

No, it says "No one else has tried the TypeScript plan for C++ yet". Which is true; Carbon isn't a compiler/transpiler to C++, it's a whole new language, albeit one with strong C++ interop.

That is completely false, as it ignores Circle and Sean Baxter's efforts.

When Sean is willing to release the source, I'll start paying attention. Until then, it's just a tech demo.

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#124

Post by Quekid5 »

pjmlp wrote: post #32

The real Typescript for C++ is Circle. https://www.circle-lang.org/ Just like Typescript to JavaScript, the syntax is an evolution of what already exists, not a completely different syntax.

Such a shame it isn't open source, so it's really impossible to eyeball QoI without actually investing a huge amount of time into the language. (Plus the usual bad things about closed source.)

I have no doubts about the qualifications (or even intentions) of the author, but one feels that a language meant for serious things should have an open implementation and/or standard. Of course, I realize this may not align with Baxter's goals, but it is going mean ~0 adoption.

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#125

Post by deschutes »

frankjr wrote: post #110
harrid wrote: post #95

Earlier quoted context omitted.

It's impossible to memory leak even with bugs if you don't use antique parts of the language that won't pass any static analysis anyways.

Considering that Chromium, being one of the most heavily statically analyzed code bases, is full of commits which fix memory leaks, your comment makes absolutely no sense. https://github.com/search?q=repo%3Achromium%2Fchromium+memor...

Chromium is a massive project spanning decades of intense active development that intricately connects just about every domain of programming.

A few leaks fixed per month is nothing. Further there is no major language promising no leaks once you include things like retained references to garbage and reference cycles. Leaks are one thing modern C++ solves pretty well.

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#126

Post by IAmLiterallyAB »

afavour wrote: post #3

I wish there was a clarification of the differences between the “Dart plan” and the “TypeScript plan”. If I had to guess I’d say the Dart approach is a whole new language that transpiles to C++ while the TypeScript plan is one that augments the current language with useful additions.

It's about 100% compatibility and interop

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#127

Post by IAmLiterallyAB »

andai wrote: post #71
afavour wrote: post #3

I wish there was a clarification of the differences between the “Dart plan” and the “TypeScript plan”. If I had to guess I’d say the Dart approach is a whole new language that transpiles to C++ while the TypeScript plan is one that augments the current language with useful additions.

Yeah, the whole article rests on this premise, but does not explain it. I guess that's behind the "timewall" of the talk?

Yeah you really have to watch the talk video to understand the article. Which is a time sink but I felt it was worth it

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#129

Post by mike_hock »

pjmlp wrote: post #32

The real Typescript for C++ is Circle. https://www.circle-lang.org/ Just like Typescript to JavaScript, the syntax is an evolution of what already exists, not a completely different syntax.

> not a completely different syntax

> [new_decl_syntax]

There's too much pining for Rust syntax and non-conservative changes or additions that aren't consistent with the rest of C++ syntax.

It repeats C++'s mistake of having too many non-convergent features and adds as much new syntax on top as C++ already has. This is a problem because to be able to read code, you have to know all language features at least superficially.

Instead of doing what plain C++ has been trying to do and stabilize on a smaller feature set and (at least verbally) deprecate legacy cruft, this is going the exact opposite route.

Sorry, but this is DOA.

Re: Cooperative C++ Evolution – Toward a TypeScript for C++

#130

Post by mike_hock »

jeffreygoesto wrote: post #115
mike_hock wrote: post #111

Earlier quoted context omitted.

[&] { auto D = C; C += 2; return D; }()

Dis you, Walter?

Lol, this would imply that D is the old C, so I doubt Walter would write this. :)

I should have just called the variable oldC.

Post reply on HN