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

141–150 of 209 posts

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

#141

Post by pjmlp »

mike_hock wrote: post #129
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 superfic…

Yeah, fully agree.

From my point of view, Cpp2 gets sold this way, due to the conflict of interest that it is being proposed by the ISO C++ chair, and naturally the story can't be that it is yet another wannabe C++ replacement like all the other ones.

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

#142

Post by eviks »

wsve wrote: post #121
eviks wrote: post #90

Earlier quoted context omitted.

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?

what is your list of successes besides TS?

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

#143

Post by synergy20 »

suby wrote: post #122
synergy20 wrote: post #94

Earlier quoted context omitted.

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.

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

next year 0.1 will be usable, 1.0 is about 3 years away, sigh, back to my rust fight

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

#144

Post by Animats »

Is there a paper for this? The video is an hour and 35 minutes.

Edit: found the Github repository.[1] "Where's the documentation? I'm not posting much documentation because that would imply this project is intended for others to use — if it someday becomes ready for that, I'll post more docs."

The examples don't have comments.

[1] https://github.com/hsutter/cppfront#wheres-the-documentation

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

#146

Post by chlorion »

Aeolos wrote: post #100
pjmlp wrote: post #65

Earlier quoted context omitted.

And exactly what makes C++ codebases so hard to clean up from C idioms, as many developers to this day apparently never went beyond changing the file extension, regardless of how many security advocacy we keep telling them.

C++ adds so many additional security footguns over C, that I find this line of reasoning hard to accept. The problem with C++ is not that people are using C constructs with it, the problem is that the language design itself is deficient. Are you aware of any systematic review that shows evidence that C++ is safer than C? The rate of safety defects between major C and C++ projects appears similar at first glance, and…

C++ containers such as std::vector and std::array have bounds checking at least, though I have not saw them used very much.

Bounds checking instantly eliminates buffer overflow related unsafety, but not having it as the default is not good.

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

#147

Post by Animats »

chlorion wrote: post #146
Aeolos wrote: post #100

Earlier quoted context omitted.

C++ adds so many additional security footguns over C, that I find this line of reasoning hard to accept. The problem with C++ is not that people are using C constructs with it, the problem is that the language design itself is deficient. Are you aware of any systematic review that shows evidence that C++ is safer than C? The rate of safety defects between major C and C++ projects appears similar at first glance, and…

C++ containers such as std::vector and std::array have bounds checking at least, though I have not saw them used very much. Bounds checking instantly eliminates buffer overflow related unsafety, but not having it as the default is not good.

The trouble with bounds checking via generics/macros is that the compiler doesn't know how to optimize out the checks. Most bounds checks can be optimized out of inner loops, where it really matters. But if the overflow test is just ordinary code, the compiler can't do that.

You also want to hoist bounds checks and do them early. Often, one check at loop entry can eliminate the bounds checks for each iteration. But the language has to allow an early fail.

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

#148

Post by seabird »

mplewis wrote: post #54
mgaunard wrote: post #42

Earlier quoted context omitted.

Type annotations for dynamically-typed languages is just a bad idea. JavaScript's only reason for existence is web browsers. If you're not doing web stuff do yourself a favour and use something else.

“C++’s only reason for existence is legacy GUI apps. If you’re not doing embedded stuff do yourself a favor and use something else.”

I would say this is largely true. C++ is incredibly fun and incredibly hard to wrangle. I think it's one of the most interesting ecosystems out there and you would have to do a lot of convincing to get me to start a new project in it. Everybody says they're going to be more disciplined this time, but after enough time, they remember the not-so-fun parts of the language. I'm not one of those freaks that has a fanatical drive to rewrite existing C++ software in Rust, but I do think it's something that's best avoided if you can help it.

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

#149

Post by csjh »

leptons wrote: post #96
jmull wrote: post #26

Earlier quoted context omitted.

You heard wrong. The only way typescript is going away is if JS essentially incorporates it. The only things people don't like about it is that you need some tooling and a build step. However, with its popularity, ts is built in to a lot of things, so the tooling usually isn't a big burden (particularly to get started). And it's viable in a lot of cases these days to forgo the build step and instead use JS with types…

>The only things people don't like about it is that you need some tooling and a build step. Wrong. Many people dislike many things about Typescript. https://levelup.gitconnected.com/the-inevitable-decline-of-t... https://medium.com/codex/why-are-javascript-pros-saying-good... https://gomakethings.com/ditching-typescript-for-javascript/ https://www.reddit.com/r/sveltejs/comments/12cyady/are_you_l... There are plenty m…

Claiming "many people" and proceeding to link to 4 posts that use Svelte as an example is a bit silly considering Rich Harris has said, numerous times, that the decision in Svelte's codebase should NOT be taken as advice for what to do in your codebase, because their decision only pertains to a very specific set of circumstances.

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

#150

Post by rictic »

AprilArcus wrote: post #133
tylerchurch wrote: post #119

Earlier quoted context omitted.

I think the main complaints are: 1. Enums are one of the few TypeScript features that isn't a type annotation that can simply be erased. Enums emit code and don't have an equivalent JS feature. 2. Const enums are unsupported by some bundlers/build tools, and so people try to use them and then got burned at build time. 3. The use cases covered by enums are often better served by union types. None of the above is neces…

FWIW, Babel has supported const enums for a few years now (since 7.15) https://babeljs.io/blog/2021/07/26/7.15.0

Yeah, tools can add support for them, but they're fundamentally a whole-program-optimization in a build chain that's 99.9% file-by-file.

Supporting const enums will, by necessity, greatly reduce the maximum performance that toolchain can achieve, because you have to evaluate the entire project to tell whether `Foo.BAR` should be left alone or replaced with a constant defined elsewhere. And in the worst case of an ambient declaration, "elsewhere" could be any file in the project.

Post reply on HN