Carbon Language: An experimental successor to C++
501–510 of 521 posts
Re: Carbon Language: An experimental successor to C++
#502Earlier quoted context omitted.
And that's still not 100%. The Carbon devs are very clear that there will be some C++ code that Carbon is unable to interoperate with.
Like the standard library - they don't plan to support exceptions.
Oh, that's excellent and interesting news - not a fan of exceptions. I'm not sure how that's going to work with interop when libraries rely on exceptions though. Where did you hear about this? I'd love to know more.
Re: Carbon Language: An experimental successor to C++
#503Earlier quoted context omitted.
C++ has virtually zero tooling and the committee is not interested in ever working on that. Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle. I mean we are getting modules that aren't literally copy paste maybe next year.
Hahaha you have zero clue. C++ has the best tooling in the world. From static analysers to best in class debuggers to best in class performance profiling tools etc. No other language comes even close.
Java has far more extensive tooling in all the categories that you've mentioned. I don't know if it's "the best tooling in the world", but if I had to make an educated guess, I'd bet on Java - and I don't even like it as a language.
Re: Carbon Language: An experimental successor to C++
#504Earlier quoted context omitted.
Example of some well-written code that expresses things that can only be expressed in C++?
I'm far from the most experienced in C++, but friend classes/functions do not seem to have a direct equivalent in any other language.
In C#, nested classes are effectively friends with their outer class, and it's used quite often in practice.
On the other end of expressivity, in Eiffel, every class member is declared as visible to specific other classes; if you want something to be public, you say that it's visible to ANY, which is the universal base class similar to e.g. Object in Java.
Re: Carbon Language: An experimental successor to C++
#505Earlier quoted context omitted.
> Major problem with GC languages is that it is horribly to link against libraries that ships with a GC. I'm curious which GC languages do this. The most popular ones that come to mind for me are anything on the JVM, JS, and Go, and I've never heard anyone point this out about them.
Every language with a GC has this problem. If you want a library to be used in both Java and Python you don't write it in either Java nor Python, you write it in C++ or another language without a GC and import that to Java and Python. Trying to import a Java library in Python or vice versa is horrible, since GC's are very hard to work with from outside the language ecosystem.
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.
Re: Carbon Language: An experimental successor to C++
#506Earlier quoted context omitted.
AIUI, you don't need to use D with a garbage collector. It can be disabled.
The D standard library is heavily tied to the GC. If you want to avoid the GC, you'd have to give up the standard library, and if you do that, you have to give up most of the D ecosystem. As far as I can tell, there hasn't been progress in untying the stdlib from the GC - https://github.com/dlang/projects/issues/56
You don't need non-GC stdlib for C++ interop, though.
Re: Carbon Language: An experimental successor to C++
#507Earlier quoted context omitted.
An std::vector is a vector in the mathematical sense, though. It's a homogeneous tuple. It's just that using an std::vector of std::vectors to store a list of points would be inefficient.
It's not. Vectors can be added together and multiplied by scalars. That they are often represented as tuples of coefficients is just notation, doesn't matter for the notion of vectors, and vice versa: a tuple is not necessarily a vector. 1. std::vector doesn't have a fixed dimensionality, as would a mathematical vector. A fixed-length array actually makes more sense as a vector. 2. It doesn't provide the operations o…
Ironically, C++ does have a standard container that can be added together and multiplied by scalars... and it's called an array; std::valarray, to be specific.
Re: Carbon Language: An experimental successor to C++
#508Earlier quoted context omitted.
With the new versions of the JDK I think they will. The Java Vector features will be out of incubator in the next year or so and unlike the existing Vector, it's actually useful. For context the new vector features are for SIMD support on the JVM.
I'm honestly surprised java.util.Vector still exists. It was "deprecated" in 1.2 or something like that? I guess there's no pressure to actually remove it, though. I only know about it from dealing with J2ME crap where ArrayList wasn't available.
Java doesn't remove things from the standard library. AWT is still around, too.
Re: Carbon Language: An experimental successor to C++
#509Earlier quoted context omitted.
Using function call syntax for array indexing always made sense to me. Functions are mappings from inputs to outputs, and arrays are mappings from indexes to values.
I agree, but explain that to programmers who think parametric polymorphism is too complex.
Given that one of the languages that historically used the same syntax for array access and function invocation since day one is BASIC, I would dare say that it's not a complicated concept.
Re: Carbon Language: An experimental successor to C++
#510Earlier quoted context omitted.
I said C++ was diff, but how about: using namespace std; typedef vector > foo_bar_xref; foo_bar_xref foo( vector > x, unordered_map y); not sprinkling std:: everywhere helps with readability, but so does defining a couple types used frequently, especially if they are particularly verbose. And of course the parser doesn't really have a problem with this, so your editor should be able to find it with its 'goto declarat…
> not sprinkling std:: everywhere helps with readability I agree, but most C++ programmers don't :/ > And of course the parser doesn't really have a problem with this, so your editor should be able to find it with its 'goto declaration' function. C++ syntax is Turing-complete, so due to the halting problem, finding the declaration can take a long time, potentially unlimited in pathological cases.
The problem historically is that "using namespace" was undesirable in headers, since it would apply to anything that included them. And with the tendency for modern idiomatic C++ to be heavily templated, many function bodies have to be in the headers.