121–130 of 163 posts
Earlier quoted context omitted.
OK, so show us your source that shows Rust has higher uptake.
https://spectrum.ieee.org/top-programming-languages-2024
Python jobs: 0.9
Seems about right, maybe.
Except there's no way PHP (0.09), Ruby (0.07) and Go (0.1) are on the same magnitude as Rust jobs.
So this site doesn't pass the sniff test for me.
Based on this comparison : https://c3-lang.org/faq/compare-languages/ One would argue that the best C/C++ alternative/evolution language to use would be D. D also has its own cross-platform GUI library and an IDE. I wonder for which reasons D doesn't have a large base adoption.
I can only speak for myself: 1. It is so big. 2. It still largely depends on GC (less important actually) It keeps adding features, but adding features isn't what makes a language worth using. In fact, that's one of the least attractive things about C++ as well. So my guess: 1. It betted wrong on GC trying to compete with C++. 2. After failing to get traction, kept adding features to it – which felt a bit like there…
Many people consider that an anti-feature.
Earlier quoted context omitted.
"case X, Y" works for 3-4 values, but for something longer problems accumulate: case SOME_BAD_THING, SOME_OTHER_CONDITION, HERE_IS_NUMBER_THREE: foo(); int y = baz(); Placing them on the next row is fairly hard to read case SOME_BAD_THING, SOME_OTHER_CONDITION, HERE_IS_NUMBER_THREE, AND_NUMBER_FOUR, AND_NUMBER_FIVE, AND_THE_LAST_ONE: foo(); int y = baz(); In C I regularly end up with lists that have 10+ fallthroughs…
> In C I regularly end up with lists that have 10+ fallthroughs like this [...] Frankly, that seems like a code smell, not a problem that needs a solution within the language.
Earlier quoted context omitted.
How does C3 compared to C in runtime performance?
I based the LLVM-IR output on what Clang outputs for C. And so they should be identical. C3 has a single module option for maximum interfunctional optimizations, but Clang can give you LTO for the same thing. So they should be the same, otherwise it's a bug.
Earlier quoted context omitted.
>while not finishing the previous attempts I agree, and that applies to many software projects, and not just programming languages only. >so there are quite a few half baked features by now what are some of those half baked features?
The new allocators, some corner cases of the destroy and destructors, not everything on Phobos is @nogc friendly, BetterC still chockes on many common C extensions, DIP 1000, the whole set of @live semantics. Now there is a new GC being redesigned, and there are discussions about a possible Phobos V3.
I only wish that the syntax was changed to make it easier to search/grep for the definition of functions and types. Odin makes this so nice, you can search for “ ::”. Maybe moving the return type to after the closing parenthesis would be enough? 2 more wishes: add named parameters and structured concurrency and I think it would be a very cool language.
Named parameters are already in the language.
Regarding concurrency, I don't want to pick a single concurrency model over another. I will see what hooks I can make for userland additions, but the language will not be opinionated about concurrency.
C3 looks promising, but any language that supports nulls needs null-restricted types, not whatever those contract comments are. If I wanted to have to null-check everything, or YOLO it, I would just write Java... and even Java is seeking to fix this: https://openjdk.org/jeps/8303099
The entire rest of the language is built on pass-by-value using stack values and stack-managed hidden unique pointers. You basically never actually need to use a ref or a pointer unless you're building an interface to a C or C++ library. I having written a 40k line production application with no reference or pointer types anywhere. Almost any case you'd need is covered by simply passing a compound type or dynamic container as a mutable value, where it's impossible to perform any kind of pointer or reference semantics on it. The lifetime is already managed, so semantically it's just a value.
C3 looks promising, but any language that supports nulls needs null-restricted types, not whatever those contract comments are. If I wanted to have to null-check everything, or YOLO it, I would just write Java... and even Java is seeking to fix this: https://openjdk.org/jeps/8303099
Will everything blow up when they create C4?