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

101–110 of 209 posts

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

#101

Post by cylemons »

pjmlp wrote: post #65
solarkraft wrote: post #62

Earlier quoted context omitted.

That's why incremental adoptability is so powerful. Slightly ironically that's exactly what (AFAIK) made C++ so popular: You can start using it without really giving up anything. And ideally once you see the benefits you'll be hooked and want to (incrementally) use it more and more throughout your code.

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.

But you can't deny that C++ is a straight upgrade to C. If CppFront becomes this straight upgrade to C++, isn't that a good thing?

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

#102

Post by superb_dev »

bitschubser_ wrote: post #29
surfmike wrote: post #7

The article claims nobody’s tried a language natively compatible with C++, but that’s the approach that Google’s Carbon is taking: https://github.com/carbon-language/carbon-lang

This is also a design goal for swift, afaik…

I think at this point Swift/C++ interop is pretty good too (anecdotally)

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

#103

Post by misnome »

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 )

What hasn't gotten fixed in typescript for "decades"?

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

#104

Post by cylemons »

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…

> The rate of safety defects between major C and C++ projects appears similar at first glance

How come? Surely there would be fewer memory leaks in a code base with proper RAII than in C code with malloc and free all over the place.

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

#105

Post by leptons »

uxp8u61q wrote: post #97
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.

What antique part of the language am I using in this bugged code? class A {}; std::unique_ptr array(new A[256]); It's very easy to produce innocuous-looking code that contains leaks. (And yes, I know that make_unique solves the problem here.)

At this point I'd rather just write assembly language.

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

#106

Post by jmisavage »

moogly wrote: post #86
jmisavage wrote: post #80

Earlier quoted context omitted.

The only problem is you run the risk of implementing a still developing standard that might be vastly different than the finalize version. You then have code and programmers trained in doing something the old "wrong" way. This happened in TypeScript when they added support for an early version of decorators and now the TC39 version (which is still only Stage 3) is just different enough to cause issues.

You mean the feature that was gated behind an opt-in switch called `experimentalDecorators' and documented from the start with "Experimental support for decorators is a feature that is subject to change in a future release"? This was only really added to appease Google and Angular 2.0.

Yeah Microsoft didn’t want AtScript to steal the little thunder TypeScript had at the time, but we’re still left with that one experimental feature all over Angular codebases.

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

#107

Post by mike_hock »

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 TS approach is really dumb for C++ and completely unnecessary. Compile times are long enough as it is without another meta compiler on top.

You already have a compiler. Just make it emit binary-compatible code for the new dialect. You have modules now so you don't have the problem of supporting mixed-dialect headers.

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

#108

Post by scriptproof »

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.

Dart compile to JavaScript, TypeScript like stated above augments JavaScript, and transpiles also when needed.

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

#109

Post by harrid »

uxp8u61q wrote: post #97
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.

What antique part of the language am I using in this bugged code? class A {}; std::unique_ptr array(new A[256]); It's very easy to produce innocuous-looking code that contains leaks. (And yes, I know that make_unique solves the problem here.)

new

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

#110

Post by frankjr »

harrid wrote: post #95
uxp8u61q wrote: post #91

Earlier quoted context omitted.

Just don't write bugs!

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

Post reply on HN