391–400 of 521 posts
It's not immediately obvious from this page and GitHub org, but this is a Google led project. It's led by Chandler and the c++ toolchain team. I have no idea of it's endgoals or how open to non-Google ideas it will be.
No good can result from the interaction between the most complex and powerful programming language and the corporation who created the programming language for dummies.
It's not immediately obvious from this page and GitHub org, but this is a Google led project. It's led by Chandler and the c++ toolchain team. I have no idea of it's endgoals or how open to non-Google ideas it will be.
> this is a Google led project This doesn't give me much confidence if its Corporate governance rather than open governance.
Earlier quoted context omitted.
Regarding C++. IMHO - it’s not getting intrinsically better. More complex. Easy things become a bit less verbose, but the hardest things remain as hard and the compiler is as unhelpful as before. I agree C++11 and it’s successors are sugaring the language to be a lot nicer but fundamentally nothing has changed. Rust is fundamentally better in it’s compiler warnings (they are actually helpful), and contains specific s…
In my experience compiler error messages have gotten hugely better, except for template issues which are still very verbose. Especially with clang.
Earlier quoted context omitted.
Considering the seemingly endless list of things that deliberately don't break with the c++ legacy, new syntax is almost the only change left. And if you were about to give c++ a syntax reboot, why wouldn't you look at what successful other modern syntaxes are doing? "c++, but in a syntax for people accustomed to rust instead of in a syntax for people accustomed to C" sounds like a perfectly reasonable approach. Your…
The problem with C++ is it keeps getting better. There was a time when Rust was interesting to me but then C++11 came out. Then they kept improving it
This is debatable.
It keeps getting more complex. Whether all the additions are worthwhile remains to be seen.
. Performance matching C++, an essential property for our developers.
. Seamless, bidirectional interoperability with C++, such that a library anywhere in an existing C++ stack can adopt Carbon without porting the rest.
. A gentle learning curve with reasonable familiarity for C++ developers.
. Comparable expressivity and support for existing software's design and architecture.
. Scalable migration, with some level of source-to-source translation for idiomatic C++ code.
Earlier quoted context omitted.
Based on what they've told me the long term governance plan is to establish an independent foundation, with development controlled by three equal lead developers from different companies. It may have been started by mostly Googlers but they want other companies and individuals to participate
Official governance vs the effective governance is the real crux of this issue. Immediately starting from the lead developers separated by companies already puts a deep corporate interest spin on the project. Choosing to do a lot of the initial work in secret and then disclosing is also a pretty big data point. I think this is going to be an uphill battle for them and I hope they win it but I'll be skeptical unless i…
Also, for what it’s worth: despite being an ISO-standard language, C++ is still heavily swayed by corporate interests, with most committee members being tied to BigCos. This has the effect of somewhat-necessarily aligning language progress with its most significant users. Without this alignment, the language might be “better” in some respects, but less useful.
Earlier quoted context omitted.
A developer familiar with C++ may believe it to be a fixed length container (perhaps with automatic bounds checking[0]) and treat it as such in memory/security/performance critical sections. 0: https://en.cppreference.com/w/cpp/container/array/at
And if they named it “vector”, a developer familiar with mathematics might believe it to be a vector.
Mathematicians are probably better suited to using R, Julia, Octave, or Wolfram.
Earlier quoted context omitted.
Yes it is very useful addition. Hopefully stdlib will also be fully nogc soon. Of all available options I am most hopeful of dlang. While it doesn't still have taken off it still is improving a lot & has high chances of increased usage. (Python also took years).
It doesn't need to be fully nogc. Not using the parts that use the gc will cripple nothing. You'll know which ones use the gc because they won't compile with @nogc.
Earlier quoted context omitted.
dlang would have been a very serious contender to C++ had it been fully nogc, stable & lean. Also dlang unnecessarily suffered low adoption in start due to competing stdlibs, trying to be both Java & C++ at once.
Most C++ codebases would be exactly the same with or without a GC. Probably 90% of collective programmer-intuition about memory allocation is either completely wrong or from thinking about a scaling to a point that most products don't get anywhere near.