https://www.youtube.com/watch?v=TH9VCN6UkyQ
Just as the scripting languages took a big bite out of C/C++ usage starting in the 90s, I think we're seeing another couple use-case for C/C++ pull off:
1) stuff that is performance sensitive but security sensitive as well (Rust) 2) stuff that is soooo performance sensitive that Rust and C++ are actually too bloated, but which isn't really security sensitive so the guarantees that Rust/Modern C++ offer aren't worth it (Jai, Blow's language).
Category 1 is clearly real, but Category 2 might be too small to sustain itself (though Blow makes an economic argument that it would be worth it).
Are we just going to keep peeling back C/C++ users from the pack with more specifically-useful languages until there are none left except for those maintaining legacy code? Or are there use-cases where C++ will continue to make sense?
I guess a lot of this depends on whether or not we can meaningfully "modernize" C++ through the standards process without simply bolting on a lot more features that add to the bloat. I wouldn't wager much that this trick can be pulled off.
I should revisit the topic in light of the latest progress with C++ and to correct some errors in those posts but I continue to believe that C++ is getting better as a language for games.
There is a somewhat legitimate argument that C++ is too complex but I don't believe you can make a convincing case that it justifies creating a whole new language (which will inevitably come with its own quirks, idiosyncracies and complexities) rather than engaging with the development of C++ itself.
Really though for what he wants to do you want a flexible framework(scripting language) backed by a fast engine(native). Jai sounds pretty interesting but I don't know if Blow has the interest in building an ecosystem around it or just using it for his own projects.
FWIW my ideal use case is Lua + Rust. I've done it on a few projects so far and really love the combo of flex + stability.
The only case I see for "C++ is too bloated" is for embedded apps on limited hardware and even then
But then of course people make something that's 10 inheritance levels deep and (ab)uses templates and then suddenly "C++ is slow". Write better code
I think of it like bicycling: one could use the same bike for commuting, road racing, mountain biking, and BMX, and you'd certainly save room in your garage, but most people do not need to do all four of those activities and will instead invest in bikes that make tradeoffs to excel in the use cases that they actually care about.
If you expect Jai to be faster than C++ I think you will end up disappointed. There isn't much reason there should be any more performance disparity than Clang and a different C++ compiler. The only language that I think could be really be called faster than C++ is ISPC.
We endeavor to not ever leave performance on the table.
For example, Java has an interface, in which methods are declared but not defined. The proposal for metaclass gives a demonstration of what an interface in C++ could look like:
interface Shape {
int area() const;
void scale_by(double factor);
};
Instead of changing the compiler to allow for new interface keyword, we can create a metaclass: // the dollar sign ($) prefix indicates reflection and metaprogramming
$class interface {
// the constexpr indicates compile-time execution
constexpr {
// raise an error if there are data members
compiler.require($interface.variables().empty(),
"interfaces may not contain data");
// loop over all functions
for (auto f : $interface.functions()) {
// raise an error if move/copy functions are present
compiler.require(!f.is_copy() && !f.is_move(),
"interfaces may not copy or move");
// function must be public
if (!f.has_access())
f.make_public();
compiler.require(f.is_public(),
"interface functions must be public");
// function must be virtual
f.make_pure_virtual();
}
}
// add a destructor
virtual ~interface() noexcept { }
};
Thus I can create a new kind of type directly in my code. This can be part of a library for downstream users without ever changing the compiler.See the full proposal here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p070...
That's a good thing: now you can refer to 20 lines of code instead of 15 pages of standardese to understand what happens.
The "interface" definition should probably qualify for that.
Update: From Herb's blog :
"Also, a vocal minority in the committee strongly want a syntax that does not include the $ character (not just for $class, but also for $expr reflection) because they have large code bases that use $ in source code that is not C++ code but is processed to emit C++; removing $ is an easy change at any time and we’ll just follow what the committee decides for reflection syntax (in fact, the alternative syntax I showed in the endnote above removes the need to write $). So further work is needed on those items, but fortunately none of it affects the core model."
https://herbsutter.com/2017/07/26/metaclasses-thoughts-on-ge...
P.S. I really hope that vocal minory would win ;)
But overall the proposal is what I have been talking about for a long time.
meta::type interface(const meta::type source) {
// … basically same code …
};
[1] https://herbsutter.com/2017/07/26/metaclasses-thoughts-on-ge...I am very interested in having Reflection in C++. But tbh $ makes it really awkward.
`reflexpr interface {...}` could be declaring and initializing a global.
`$class`, on the other hand, doesn't compile. One could also do `virtual class` or something, I guess, since `virtual class` is a combination of reserved keywords.
C++ needs a new strict set of rules that (ideally for individual files, to start) prohibits some set of older/deprecated features from even compiling. That way, you know where the language is going and you adapt.
Headers suck. Build systems suck. Package management sucks. Compile times suck.
Precisely the things that are not part of the language are those that suck the most.
Now we only write
struct Point {
int x;
int y;
};
to get the oh-so-needed class Point {
private:
int x;
int y;
public:
Point() =default;
~Point() noexcept =default;
Point(const Point&) =default;
Point& operator=(const Point&) =default;
Point(Point&&) =default;
Point& operator=(const Point&&) =default;
};
Genius! Almost like 1972 where we wrote the former and that was just fine!