Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)
It seems that the goal is a new language with full interop with C++, kind of like Zig's interop with C.
- I wonder how much baggage had to be maintained for interop. If some of it could be isolated, how did they do it?
- Does this fall into any of the traps that D initially did where it allowed C interop but was, by default, more limited in what C environments it could run in or is this as flexible as C++ for environments?
As for the language itself, I've not had a chance to dig into it too much but I am sad to see that it uses explicit local inference by replacing the type name with `auto` rather than eliding the type completely . While it has its pains at times, this is something I've come to enjoy in Rust.
I also didn't see mention of tooling. Having out-of-the-box build, test, and code formatting would be a big help for establishing community standards / practices, even if the build/test tool might get limited when having to do C++ interop. At least for pure-Carbon libraries it would be a big help!
> Once we can migrate code into Carbon, we will have a simplified language with room in the design space to add any necessary annotations or features, and infrastructure like generics to support safer design patterns. Longer term, we will build on this to introduce a safe Carbon subset. This will be a large and complex undertaking, and won't be in the 0.1 design. Meanwhile, we are closely watching and learning from efforts to add memory safe semantics onto C++ such as Rust-inspired lifetime annotations.
I'm a bit skeptical if they push off lifetime annotations too far.
Qt without moc: set of macros to use Qt without needing moc
> it's possible to do Qt without moc even in C++ with https://github.com/woboq/verdigris/, why wouldn't it be possible from D ?
You're talking about an entirely different thing. While OP was referring to the current state of D's ecosystem and the impact that missing key frameworks have on hindering adoption, you're arguing about the theoretical possibility of writing a framework with a language, which really does not address OP's point.
Collect and Analyze Billions of Data Points in Real Time. Manage all types of time series data in a single, purpose-built database. Run at any scale in any environment in the cloud, on-premises, or at the edge.
From the README:
> Interoperate with your existing C++ code, from inheritance to templates
Somewhere in the docs (can't remember where) is a link to a Rust/C++ interop project sponsored by Google, Crubit:
In case it's not clear, Carbon is also at the moment a Google project.
There's not much in the Crubit README (although there is a warning not to use it), but the docs directory has some interesting stuff:
> The primary goal of C++/Rust interop tooling is to enable Rust to be used side-by-side with C++ in large existing codebases.
Safe interop between Rust and C++
> In otherwords, what carbon can do that Rust can't do, is take a C++ class with a `foo` method and call that method. Or create a class with a `foo` method and call that method from C++. Probably one of the biggest hurdles to get over in C++ interopt. Most don't do that, instead you'd make a C function binding and struct and move data/invoke functions through that.
Design of the Dart language
D Improvement Proposals
There's no "nogc" containers in phobos, or allocators, or an idiomatic way to do safe manual memory management. It expects you to do it the C way. It's also impossible to implement some things because of how D does moving. There's a DIP in the works to change how moving works, but it's overly complicated and bound to introduce even more bugs. https://github.com/dlang/DIPs/blob/master/DIPs/DIP1040.md
Compiler-neutral Internal Program Representation for C++
> C++ has virtually zero tooling
CMake, Meson, Waf, Conan, Visual Studio Code, Visual Studio, CLion, Intel VTune, GDB, LLDB, XCode, Artifactory, SonarQube, clang-tidy, clang-format, astyle, Incredibuild...
> Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle
You are wrong here. Cargo serves a set of fixed "this-is-how-to-do-it" thing. In C++ you can build anything. I do not mean it is better, but C++ software already exists and that is the solution that it works better for it. :)
> and the committee is not interested in ever working on that
Interoperability effort for modules: https://github.com/GabrielDosReis/ipr
Learn any GitHub repo in 59 seconds. Onboard AI learns any GitHub repo in minutes and lets you chat with it to locate functionality, understand different parts, and generate new code. Use it for free at www.getonboard.dev.
Python for .NET is a package that gives Python programmers nearly seamless integration with the .NET Common Language Runtime (CLR) and provides a powerful application scripting tool for .NET developers.
I don't know about Java, but it's trivial to import a .NET library in Python with a high-level mapping that takes care of everything GC-related automatically:
I don't see any reason why something like this cannot exist for Java, if it doesn't already.
Why do we have to put the const keyword in Flutter?
1 project | /r/FlutterDev | 6 Dec 2023
FastHttp for Python (64k requests/s)
5 projects | /r/Python | 8 Nov 2023
Playing around with Extension Types
1 project | /r/FlutterDev | 26 Oct 2023
Entendendo Algoritmos: Recursão
1 project | dev.to | 20 Oct 2023
I modified and hacked away xonsh source code
2 projects | /r/xonsh | 18 Oct 2023