81–90 of 521 posts
Interesting. It will obviously take off _because Google_ but since they're heavily influcened by the Rust syntax, why not just learn Rust instead. They'll need to get it into Compiler Explorer so people can really look at codegen rather than porting small programs.
https://carbon.godbolt.org/
Earlier quoted context omitted.
Isn't this one of the most prominent features in D? Sounds like they're trying for something very much like D, while starting closer to current C++.
D still requires you to write bindings, see https://dlang.org/spec/cpp_interface.html Also D objects have a different lifetimes & requirements, which complicates things ( see https://dlang.org/spec/cpp_interface.html#lifetime-managemen... ) Carbon appears to be auto-generating bi-directional bindings, and since it has the same memory model has no such awkward interactions between non-GC'd and GC'd worlds like D does.
Does Carbon actually solve these issues, though? It would be great if it did, but they don't list complete interop w/ C++ as an actual goal of theirs, only enough to make it practically viable for development.
Interesting. It will obviously take off _because Google_ but since they're heavily influcened by the Rust syntax, why not just learn Rust instead. They'll need to get it into Compiler Explorer so people can really look at codegen rather than porting small programs.
That's pretty extensively covered in the link, but here's a relevant snippet:
"Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should. Unfortunately, the designs of these languages present significant barriers to adoption and migration from C++. These barriers range from changes in the idiomatic design of software to performance overhead."
If you are like me and wondering "What makes carbon different from Rust or Zig? 1. The ability to interoperate with a wide variety of code, such as classes/structs and templates, not just free functions. 2. A willingness to expose the idioms of C++ into Carbon code, and the other way around, when necessary to maximize performance of the interoperability layer. 3. The use of wrappers and generic programming, including…
Interestingly enough, Chicken Scheme has a library that allows for interop with C++ to this degree: http://wiki.call-cc.org/eggref/5/bind#c-notes
Why use Rust syntax (fn, x:Type, ...)? Syntax is one thing that is not so well-designed in Rust (in my opinion). Also, with the stated goals, it seems a bit unnecessary to overhaul C++ syntax, but then I found no explanation why syntax was changed. So what's wrong with C++ syntax if your goal is a successor of C++? This now looks to me like a Rust-- instead of a C++++, which is a picture they might not want to give r…
It's not just Rust syntax. `name: Type` is the syntax used in TypeScript and Python type annotations (also Ocaml, which is probably where Rust got it from). Golang drops the colon, but still keeps the name first. As for what's wrong with `Type name(constructor, args)`? A lot of tooling wants to be able to parse "mostly-valid C++", like IDEs and compiler diagnostics. Sure, once clang's type inference is finished, the…
No thanks
Interesting. It will obviously take off _because Google_ but since they're heavily influcened by the Rust syntax, why not just learn Rust instead. They'll need to get it into Compiler Explorer so people can really look at codegen rather than porting small programs.
It's a shame a stable ABI is declared as one of the non-goals, C++ is painful enough to integrate with other languages.