C++ only needs 4 things: gradually-introducable memory safety, static reflection, first-class compile time string manipulation, and adoption+refinement of its modules feature.
C++ is a memory safe language if not abused.
Just don't write bugs!
Cooperative C++ Evolution – Toward a TypeScript for C++
91–100 of 209 posts
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#92I'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 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).
I think the Typescript creators themselves learned a lesson with decorators and enums which is why we haven’t seen other JS language proposals get added until they’re actually in the process of being adopted (e.g. matchers).
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#93Earlier 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.
People who chase "new, shiny" often get rewarded with stupid prizes.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#94After the talk, the activity on it is nearly zero since then, in a world where ideas are cheap, show me the code, this does not seem promising to me. On the other hand, carbon has been very actively developed since its announcement, which also claims to be a typescript-for-c++. Now it also wants to be a memory safe: https://www.youtube.com/watch?v=1ZTJ9omXOQ0 I'm forced to learn rust but I hope carbon will take off A…
> 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
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#95Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#96I’m not a frontend guy but heard that typescript is already falling off and contentious at this point. Is it truly something that’s going to stay?
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 more examples of why people tried typescript and went back to javascript. It's definitely not only because of a build step, but also "type gymnastics", and other code bloat.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#97Earlier 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.
What antique part of the language am I using in this bugged code?
class A {};
std::unique_ptr array(new A[256]);
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#98Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#99Earlier quoted context omitted.
The whole point of JavaScript is that it's dynamically-typed. If you want static typing just use C++ or any other established programming language.
> it's dynamically-typed Yet, most of the code people write has statically defined types. Anyway, the whole point of JavaScript is that it runs on the browser. Outside of that, it has no strong points. Even though most of them are not weak enough to immediately abandon the language, its type system is one of the weakest.
Javascript's dynamic typing is fine if you aren't a really shitty programmer.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#100Earlier 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.
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 both way worse than managed languages or rust.