> C++ requires the developer to make a conscious effort to avoid unsafe code
The problem is much worse than how you put it. I've written C++ for more than a decade and it's painful to constantly having to worry about memory safety due to enormous complexity of the language. Even if you are super diligent, you will make a mistake and it will bite you when you expect it the least.
Relying on clang-tidy, non-default compiler flags, sanitizers and other tools is not only not enough, but a constant source of headache on how to integrate them with your build systems and project requirements.
Admittedly, I am more of a hobbiest when it comes to C++ development. I try to keep track of things, but I started learning the language before it was standardized and I switched to other languages shortly after it was standardized (never mind the introduction of memory safe option in the standard libraries, which occurred in the 2000's). That said, memory safety has been a consideration, and a feature, for nearly 20 years now. It seems to me that people should have been taught how to approach it for nearly 20 years now. Sure, you can break the rules. Sure, anyone working with older code would have been exposed to bad code. Yet it shouldn't be a universal problem unless people are deliberately seeking out shortcuts (since writing memory safe code in C++ is messier than writing unsafe code).
I am very interested in Hylo! I think they're playing in similar spaces. I'd like to explore mutable value semantics for Rue.
One huge difference is that Hylo is using LLVM, whereas I'm implementing my own backends. Another is that Hylo seems to know what they want to do with concurrency, whereas I really do not at all right now.
I think Hylo takes a lot of inspiration from Swift, whereas I take more inspiration from Rust. Swift and Rust are already very similar. So maybe Hylo and Rue will end up like this: sister languages. Or maybe they'll end up differently. I'm not sure! I'm just playing around right now.
Both are playing around in similar spaces, both shared team members for a while, both have a take an automatic memory management that isn’t a garbage collector, both were sponsored by a primary company for a while (Swift still is, I think). There’s a lot of differences too.
I'd like to ask HN a very vaguely related question. I need to get a self-hosted runner (for GitHub Actions) that is capable of running Windows ARM64. What are my options other than buying a machine and do everything manually? Are there any service providers that offer Windows ARM64 VMs? I can only seem to find options for Linux.
In case you don't already know, there are Github-hosted runners that run Windows arm64 [1]
Also, it's not what you're asking, but self-hosted runners are a security nightmare if you don't have the hardware to completely isolate them from your local network.
Yeah and (1) the codegen produces massive headers that slow compilation of anything that touches them (2) the generated classes are really awkward to use. Not a big fan of the experience of protobuffer generated code in a large C++ code base.
It's lead to a huge layer of adapters and native c++ classes equivalent to the protobuffers classes to try and mitigate these issues.
I wish GPU vendors would stick to a standard terminology, at least for common parts. It's really confusing having to deal with warps vs wavefronts vs simd groups, thread block vs workgroup, streaming multiprocessor vs compute unit vs execution unit, etc...
> Travelling to a 3rd world country with genuinely poor people can help, a bit.
I agree with this. For anyone who's young and can afford, I wholeheartedly recommend travelling to a poor country. It will truly give you a lot perspective on the world and appreciate your life more.
Having said that, I often see people grossly misunderstanding that just because you visited a poor country you understand the lives of the people you saw (e.g. their cultures, opinions and lifestyle). It really does not. You only get a very superficial glimpse, but it takes years to embody their experience in your mind.
> We are collaborating with the Flutter team at Google to bring Impeller, their GPU first renderer, to .NET. That work is already in progress and as it lands, the MAUI backend will inherit those gains.
Interesting, I wonder how good Impeller is and if it's actually better than the new Graphite backend of Skia.
Predictable performance: Impeller compiles all shaders and reflection offline at build time. It builds all pipeline state objects upfront. The engine controls caching and caches explicitly.
or as described here [2]
Flutter’s Impeller renderer outperformed Skia. Impeller eliminates runtime shader compilation stalls, delivering lower frame times and more stable performance. For animation-heavy, graphics-rich apps, enabling Impeller significantly reduces jank and provides a smoother user experience.
reply