C++ only needs 4 things: gradually-introducable memory safety, static reflection, first-class compile time string manipulation, and adoption+refinement of its modules feature.
What’s the use case for static reflection?
Cooperative C++ Evolution – Toward a TypeScript for C++
81–90 of 209 posts
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#82The 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
Google claims that Carbon is the future internally at Google for a safer C++, and Google never approves Rust for internal usage. Then I see multiple public announcements of Google rewriting something in Rust (such as the recent Binder rewrite). I'm quite confused.
For the most part, Rust projects at Google tend to be things that are relatively self-isolated (like the Binder rewrite). Google has a huge monorepo with tens of millions of lines of C++ code, much of which is highly interlinked and interdependent. The goal of Carbon is to help move that code to a simpler and safer programming model.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#83The article assumes that the reader is familiar with what is meant by the “Dart plan” and the “TypeScript plan”. I only have cursory knowledge of Typescript and know nothing about Dart. Others in this thread already went into more details about this, but it doesn't help me much as long as I don't have an idea what the basic difference between both approaches is. Can someone ELI5 the gist of both approaches?
In addition to the other comments -
TypeScript deliberately takes a "good enough" approach to improving JavaScript, instead of designing an ideal but incompatible approach. For example, its handling of function parameter bivariance (https://www.typescriptlang.org/docs/handbook/type-compatibil...) is unsound but works much better with the existing JavaScript ecosystem. By contrast, a more academic functional programming language would guarantee a sound type system but would be a huge shift from JavaScript.
By analogy, Herb Sutter is arguing that something like the C++ Core Guidelines (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines), with tooling help in this new Cpp2 syntax, can bring real improvements to safety. Something like Rust's borrow checker would bring much stricter guarantees, backed by academic research and careful design, but would be incompatible and a huge adjustment.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#84Earlier 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.
I’m not sure how people are supposed to do that in the browser. This feels like an excessively dismissive comment.
Have you not heard of WebAssembly?
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#85C++ only needs 4 things: gradually-introducable memory safety, static reflection, first-class compile time string manipulation, and adoption+refinement of its modules feature.
I'd add less verbose ranges. Idk about memory safety, optional and expected are working pretty well for me (i just use it on personal projects though)
You can't possibly put syntactic sugar on the same level as memory safety.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#86I'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.
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.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#87Please let it fade away with dignity.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#88But C++ already is a typed language confusedsmiley
Ever heard of typeclasses? ;)
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#89Earlier quoted context omitted.
Dart was made by Google as a new language for the web. In the beginning, it was already quite different from JavaScript at the time, and crucially the main way to use it is through the Dart VM (that was embedded into a build of Chromium). It did have compilation to JS, but AFAIK never caught on. In the end, Dart diverges from JS so much so that the split in ecosystem means it's not viable for the web anymore. TypeScr…
I can't think of anyone besides Anders Hejlsberg that has a better track record with programming language innovation. At least 3 different languages that have all been commercially successful.
Dennis Richie[0] and/or Ken Thompson[1] might be of interest.
Re: Cooperative C++ Evolution – Toward a TypeScript for C++
#90I'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 )