> 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.
Enough said! I agree.
Carbon Language: An experimental successor to C++
421–430 of 521 posts
Re: Carbon Language: An experimental successor to C++
#422Earlier quoted context omitted.
> this is a Google led project This doesn't give me much confidence if its Corporate governance rather than open governance.
Nor does it convey any confidence that Google will support it.
Looking at other languages Google developed and continued supporting, this comment is a bit unfair.
Re: Carbon Language: An experimental successor to C++
#423If 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…
Zig is to my knowledge specifically designed to have they kinds of use after free that C and C++ have. Their claim is not to “hide” allocation by requiring everyone to implement manual retain and release.
Zig is at most, as safe as a language like Modula-2.
Definitly safer than C and C++ in regards to bounds checking and numeric conversions, but without any language protection against user after free, other than what you would already get with heap debuggers on C and C++.
Re: Carbon Language: An experimental successor to C++
#424Earlier quoted context omitted.
C++ also has a very hard-line "you don't pay for what you don't use" philosophy, which sometimes lead to standard library APIs or language semantics which are a bit tortured. Compare C++ or against, say, the equivalent functionality in Rust, Go, Java, C#, etc. C++'s APIs are a bit overcomplicated, or at least they look that way if you don't know the various reasons why the C++ standard defined them that way (reasons…
"C++ also has a very hard-line "you don't pay for what you don't use" This always felt eye-rolling false to me. We can't have a better hashmap since we all need to pay for the std::unordered_map's un-needed features like bucket access. We are certainly paying for what we don't use.
"You don't pay for what you don't use" means the compiler doesn't generate worse code than if you had written the same by hand.
Every other adoption of the meaning is misuse of what Bjarne originally meant with it.
Re: Carbon Language: An experimental successor to C++
#425Earlier quoted context omitted.
The problem with the typical rants about C++ is that you guys are outdated. With Conan you can consume over 1,000 packages directly from build systems and with way more control than what Cargo seems to offer. Take a look. I did use it for a while and compared to 15 years ago things are way better now.
The problem isn't that Conan exists, but that other competing solutions are just as popular which results in fragmentation (for instance vcpkg, and cmake can also directly pull in external dependencies now). In the Rust world there's just Cargo.
Fragmentation is not the problem. The future of C++ is to have metadata exchange, at least the way I see it.
This means that packages can be compiled with any build system, the one that fits you better. In the event that you cannot find a binary that fits you, your package manager can compile on the fly. There are also solutions to keep binary artifacts in Conan. This means that most of the time you can consume pre-made packages in vcpkg/Conan for casual consumption but you can still have binary repositories with fully customized builds for all your permutations of compilers and systems and debug/release. Do not forget this is a hard problem, we are talking to compilation to native, sometimes you need full speed and a custom compilation, not about portable Java bytecode.
But you can still set up and tweak recipes in Conan and upload to your binary repository (what we do at my company).
However, none of these things tie you to a build system, since conan can generate .pc, .cmake, MSBuild, XCode and way more metadata to consume those packages.
You can scale from simple to fully customized. For example before we had a libcxx that we compiled ourselves and pointed all deps and patched packages and could build something with like twenty-some dependencies with that customized libcxx optimized for us. Can you do that with Cargo? Serious question, I did not make extensive use of it.
However for simple uses you can just drop a conanfile.txt and conan install your profile and start to consume your packages. All of this works with CMake, but if I want to use Meson build system or SCons, Make and others I can do it as well. Look at the generators page: https://docs.conan.io/en/latest/reference/generators.html
I do not think fragmentation in build systems is even a real problem anymore because the "not fragmented but simple" philosophy leaves many things out of the box, such as compiling something custom when you really need it.
The system is very flexible. True that the learning curve is harder at first, but much simpler than it used to be in the past.
I can have full projects, not even with Conan, just with simple Meson wraps (Meson wraps are source-only dependencies though) pointing interdependencies to the same version of a library with a very reasonable amount of work: sometimes a single switch in the options, sometimes a small patch that you can keep in your subprojects/ directory or somewhere else.
I can easily generate .cmake and .pc files from Meson itself without trouble, which are two of the most used build systems. But if on top of that you build a Conan recipe then you can have many consumers of your packages for free.
It is nice to have a tool that is more ore less streamlined sometimes, but build systems is a difficult topic and probably there are some that do a few things better than others: cross-compilation, linux tweaks, generating VS solutions for you if your company uses VS, XCode or whatever. It is not bad to have a choice as long as you can interchange.
I would say it is even better than having the one-size-fits-all thing and later when you want to go to the real native stuff then you discover that your tool is too basic and cannot switch.
Re: Carbon Language: An experimental successor to C++
#426Earlier quoted context omitted.
> C++ has virtually zero tooling and the committee is not interested in ever working on that This sentence makes no sense at all: 1 - Tooling does not stop to the build systems 2 - The tooling set in C++ (and C) has been built over decades. It is indeed not a single shiny CLI cargo-style but it several order of magnitude bigger and more powerful than anything you will ever find in any other programming language: memt…
Most of the tools you mention work below the language level, and thus work automatically for non-C/C++ languages too (or at least LLVM-based languages).
They do work below the language level but have been generally explicitly made for C and C++ programs. e.g abi-compliance-checker
The other languages benefit of them currently because they leverage LLVM (also made in C++), because their interpreter/VM are made directly in C.
How is it already ? Standing on the shoulders of giants ? :)
Re: Carbon Language: An experimental successor to C++
#427Earlier quoted context omitted.
Just a lot of small things stand out: - function and variable types are harder to visually parse for me. The keyword to declare a variable and the type put the varible name in the middle for instance. - the "fn" keyword is terrible, just to save on characters. Honestly, any keyword should have vowels and is pronounceable. Python has "def", I would have been fine with "func" as well - type annotation for templatizatio…
It's pronounced "fun", they just didn't want to make it too explicit because coding isn't always fun.
Then why not be consistent with "let" and "var", and actually use the vowel?
I also am sometimes not fun at parties.
Re: Carbon Language: An experimental successor to C++
#428Earlier quoted context omitted.
A blog post by Roman Elizarov (Kotlin designer) on the observation of types following the variable name [1]. It mostly states that having consistent length prefixes (fn, val/var) makes the code more readable than arbitrarily long type identifiers (in the eye of the beholder). Not scientific, but interesting. [1] https://elizarov.medium.com/types-are-moving-to-the-right-22...
Fixed prefixes also make a codebase significantly more grep-able. Want to find the definition of the function named `foobar`? Search `fn foobar` and that will always match, no regex required.
Only if you use a code formatter (which you should) because otherwise there will be some 'fn foobar'(two spaces or more) just to annoy you..
Re: Carbon Language: An experimental successor to C++
#429Earlier quoted context omitted.
I can't handle [] syntax for generics. It makes code unreadable as far as I'm concerned because it makes it twice as difficult to know if I'm dealing with an array indexer or a generic. The rest I can excuse but [], I cannot. Same reason I won't touch Nim.
I can't handle syntax for generics. It's impossible to auto-pair and looks ugly. The real solution is [] for generics and something else for indexing.
When looking for eleguant solutions: look at D, it's full of pearls: they use !() for generics.
Re: Carbon Language: An experimental successor to C++
#430Some quick notes about interesting features of the design: * Source file encoding is required to be UTF-8. Strings are UTF-8. No apparent provision for binary strings, but I haven't delved into the string API. * Retains the C/C++ definition of overflow of signed integers cannot overflow, unsigned can. That's o_O-worthy; the two should be aligned, and if they can't overflow, provide some form of wrapping integers as w…
> * Retains the C/C++ definition of overflow of signed integers cannot overflow, unsigned can. That's o_O-worthy; the two should be aligned, and if they can't overflow, provide some form of wrapping integers as well.
Agreed, they should provide three kinds of integers: signed as usual, unsigned like in C++ but for compatibility only, usage discouraged (unless your programming a clock) and "natural integers" which traps on over/under-flow in debug builds. And going from one kind to another kind should always be done with explicit cast (there is a proposal to allow some implicit conversions and it allows implicit conversion from unsigned to bigger signed :-( :-( )