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

131–140 of 209 posts

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

#131

Post by tialaramex »

_flux wrote: post #73
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.

As far as I recall, all compiled languages use untyped target languages. The only downside with TS/JS is that the JS implementation loses an optimization opportunity by not being aware of the TS-checked types.

I think probably the Java bytecode is type aware ? But yes, in general AOT compiled languages result in machine code, and so it isn't type aware after transformation.

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

#132

Post by tentacleuno »

mgaunard wrote: post #42
tentacleuno wrote: post #30

Earlier quoted context omitted.

Why is TypeScript a "bad web technology"? It's not really a "web technology" at all. It's a language which transpiles to standard JavaScript. The only real web-geared parts of TypeScript are the included (optional) DOM typings.

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.

> Type annotations for dynamically-typed languages is just a bad idea.

Yet, as with the parent comment, you haven't divulged your reasoning behind this statement. If you're going to make such a broad statement, at least place your rationale beside it.

> JavaScript's only reason for existence is web browsers.

JavaScript has seen broad adoption throughout the industry, for servers (Node.js, Deno, Bun), IoT (DeviceScript), browsers (duh) and mobile apps (NativeScript, React Native, etc.). It has its weak points, but downright dismissing it (again, without any rationale) is unfair and disingenuous IMO.

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

#133

Post by AprilArcus »

tylerchurch wrote: post #119
maxloh wrote: post #112

Earlier quoted context omitted.

Why did you mention enum? Is it designed badly?

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

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

#134

Post by otabdeveloper4 »

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

Anything written by Google is absolute bottom of the barrel shit.

It's not indicative of anything average in the real world.

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

#135

Post by pjmlp »

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…

Yes, it starts by not coding in C++ as if it was C.

Use templates instead of macros, RAAI instead of gotos, namespaces instead of prefixes, bounded checked strings and arrays instead of raw pointers, new instead of error prone sizeof with malloc(),...

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

#136

Post by pjmlp »

cylemons wrote: post #101
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.

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?

C++ extended C syntax, did not introduce a completly different one alongside.

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

#137

Post by pjmlp »

IAmLiterallyAB wrote: post #123
pjmlp wrote: post #34

Earlier quoted context omitted.

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.

I guess many C and C++ compilers are tech demos as well, including some forks from GCC and clang.

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

#138

Post by harrid »

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

It's a bit hard to get an overview. But I did spot several uses of owning raw pointers and switching from those to managed ones. I'd say that's exactly the point I was trying to make.

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

#139

Post by pjmlp »

Quekid5 wrote: post #124
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 wi…

Once upon a time the only C and C++ compilers that one could get for free, were the ones available alongside UNIX tapes.

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

#140

Post by tentacleuno »

evilduck wrote: post #92
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.

They have been labeled experimental the entire time and off by default. That specific TC39 proposal is also approaching a decade of feet dragging and has been exceptionally slow to make progress. In Typescript if you aren’t opting into using decorators through a library that forces you to use them, they’re entirely avoidable (and some would argue, decorators make code worse and this failure to launch is a good thing)…

> That specific TC39 proposal is also approaching a decade of feet dragging and has been exceptionally slow to make progress.

So... like the pipeline operator? Pretty much given up on that being included now. They can't make up their minds over two competing syntaxes (and, FWIU, it has taken them years to decide).

Post reply on HN