Our great sponsors
-
carbon-lang
Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
CppCoreGuidelines
The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
> 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
The "Dart plan" vs "TypeScript plan" comparison is shown at 1:33:50 in the talk:
> "Dart plan" - Competitive/successor 10x improvement
> New creation
> Limited interop, relies on wrapping/marshaling/thunking...
> Competes with standard (e.g., different modules, different generic constraints)
> Evolves independently of standards committee - far fewer design constraints
> Needs to bootstrap a new ecosystem
> "Typescript plan" - Cooperative/compatible 10x improvement
> Every .js file is a valid .ts file, add 1 class and see benefit
> Lowers to standard .js, 100% seamless compat with all JS libraries
> Cooperates with the standards committee (ECMAScript)
> Brings evolution proposals to standards committee
> Leverages entire existing ecosystem - works with all JS implementations & tools
Carbon is an example of the "Dart plan". Some quotes from Carbon's "Interoperability philosophy and goals" page (my emphasis):
> The C++ interoperability layer of Carbon allows a subset of C++ APIs to be accessed from Carbon code, and similarly a subset of Carbon APIs to be accessed from C++ code.
> The result is that it will often be reasonable to directly expose a C++ data structure to Carbon without converting it to a "native" or "idiomatic" Carbon data structure. Although interfaces may differ, a trivial adapter wrapper should be sufficient.
> There should be support for most idiomatic usage of advanced C++ features. A few examples are templates, overload sets, attributes and ADL.
> Non-goals
> Never require bridge code
> Support for C++ exceptions without bridge code
https://github.com/carbon-language/carbon-lang/blob/trunk/do...
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.
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.