Thanks for this link. Between it and the main article, I have a much better sense for how compile time reflection will actually be useful. The syntax is bad enough to make my eyes bleed, but at least they'll bleed for a good reason I hope.
While true, just like everyone on Rust land rarely thinks about configuring their projects without clippy, C and C++ developers should learn static analysers for C and eventually C++ exist since 1979.
It doesn't fix everything, yet it fixes more than those that don't use them at all.
I have been using such tools since mid-1990's when coding in either C or C++, and sadly it is still a discussion point regarding adoption.
The rationale in section 2.2 for the single std::meta::info type is interesting. While having a single “dynamic” type is fine insofar as any type error would occur at compile time anyway, I wonder if there wouldn’t be a way to maintain future backwards compatibility for finer-grained meta types, as long as the language elements they reflect remain backwards-compatible in the language as well. From first principles, one would think that it should be possible for the backwards compatibility of the reflection system to mirror the backwards compatibility of the reflected language. I’d be interested in the underlying reasons for why this isn’t the case, if any.
Rust is the future of systems programming and will always be for the foreseeable future. The memory issue will mostly be addressed as needed, see from John Carmack yesterday[1], the C++ ecosystem advantage (a broad sense of how problems whether DS, Storage, OS, Networking, etc. have been solved) will be very hard to overcome for newer programming languages. I think it is ironic how modern C++ folks just keep chugging along releasing products while Rust folks are generally haranguing everyone about "memory safety" and generally leaving half finished projects (turns out writing Rust code is more fun than reading someone else, who would have guessed).
> The memory issue will mostly be addressed as needed
I have no allegiance to either lang ecosystem, but I think it's an overly optimistic take to consider memory safety a solved problem from a tweet about fil-c, especially considering "the performance cost is not negligible" (about 2x according to a quick search?)
Performance drop of 2x for memory safety critical sections vs Rust rewrite taking years/decades, not even a contest. Now, if that drop was 10x maybe, but at 2x it is no brainer to continue with C++. I'm not certain Fil-C totally works in all cases, but it is an example of how the ecosystem will evolve to solve this issue and not migrate to Rust.
What would you consider to be a non memory safety critical section? I tried to answer this and ended up in a chain of 'but wait, actually memory issues here would be similarly bad...', mainly because UB and friends tend to propagate and make local problems very non-local.
time.Now().Format("Monday, January 2, 2006 at 15:04")
// Try on the Go Playground: https://go.dev/play/p/kOWlG6bdvbC
You can change it to time.Now.Format("Monday, January 345, 2006 at 588:46") and it will compile and run fine, printing junk. No compile or runtime checks, is there any language that is this broken in dates. Most should print some error or something right?
The “k” in awk, of course. I’ve never met Kernighan or Weinberger personally. I did have a great conversation once with Al Aho and Larry Wall, largely about the history and mutual influence of programming languages upon one another.
yeah, he was 20 when he co-authored lex. Had a good career at Sun and was brought into Google as adult supervision and that was 20 years ago! Kind of living example of the (almost) entire history of computing.
@dang I feel like this is getting close to the lowest level of discourse and occurs somewhat often these days where people overly reference the output of some AI and then are challenging the results without googling. I feel a proper hacker ethos would spur someone to find a real answer. So in honor of the name of the site maybe disallow refutations or other dismissals of a submission based on the output of an AI or overly long discussion that is offtopic about an AI?
Tom and I of course agree! But it's not so easy to disallow things, since humans do $thing anyway.
Most probably the long-term solution is for the community to express this preference by flagging comments that do this. I think we see signs of that happening, which is good, because a community solution is better than a technical solution (and way better than an authority solution) any day.
Btw, tapirl is a good contributor and I don't think they did anything particularly wrong. It just takes time for us all to learn the optimal patterns together.
As repeated for another game engine, written in modern C++20 gives one great confidence in the viability and longevity of the engine. Good choice, kudos on the effort.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p29...
reply