[flagged]
please don't use AI to write comments
Type resolution redesign, with language changes to taste
121–130 of 284 posts
Re: Type resolution redesign, with language changes to taste
#122[flagged]
[deleted]
Re: Type resolution redesign, with language changes to taste
#123Earlier quoted context omitted.
As proven a few times, it doesn't matter if committee decides to break something if compiler vendors aren't on board with what is being broken. There is still this disconnection on how languages under ISO process work in the industry.
The C++ standards committee’s antiquated reliance on compiler “vendors” holds it back. They should adopt maintenance of clang and bless it as the reference compiler.
And you will be the one telling the losers that their compiler, operating systems and OS doesn't count?
By the way this applies to the C language so beloved on this corner as well.
As it does to COBOL, Fortran, Ada and JS (ECMA is not much different from ISO).
Re: Type resolution redesign, with language changes to taste
#124Earlier quoted context omitted.
Go has a garbage collector though. This makes it unsuitable for many use cases where you could have used C or C++ in the past. Rust and Zig don't have a GC, so they are able to fill this role. GC is a showstopper for my day job (hard realtime industrial machine control/robotics), but would also be unwanted for other use cases where worst case latency is important, such as realtime audio/video processing, games (where…
> GC is a showstopper for my day job (hard realtime industrial machine control/robotics) Which is a very niche use case to begin with, isn't it? It doesn't really contradict what the parent comment stated about Go feeling like modern C (with a boehm gc included if you will). We're using it this way and it feels just fine. I'd be happy to see parts of our C codebase rewritten in Go, but since that code is security sen…
Not everybody is writing web apps.
You can also see it differently: If the language dictates a 4x increase in memory or CPU usage, you have set a much closer deadline before you need to upgrade the machine or rearchitect your code to become a distributed system by a factor 4 as well.
Previously, delivering a system (likely in C++) that consumed factor 4 fewer resources was an effort that cost developer time at a much higher factor, especially if you had uptime requirements. With Rust and similar low-overhead languages, the ratio changes drastically. It is much cheaper to deliver high-performance solutions that scale to the full capabilities of the hardware.
Re: Type resolution redesign, with language changes to taste
#125Earlier quoted context omitted.
I really wanted to deep dive into zig but I'm into rust now kinda late as I'm really just started like 2024. Have you tried rust? how does it compared to zig? * just asking
Zig is a modern C, Rust is a modern C++/OCaml So if you enjoy C++, Rust is for you. If you enjoy C and wish it was more verbose and more modern, try Zig.
Zig is Modula-2/Object Pascal re-packaged with a C like syntax.
Re: Type resolution redesign, with language changes to taste
#126Earlier quoted context omitted.
Zig is a modern C, Rust is a modern C++/OCaml So if you enjoy C++, Rust is for you. If you enjoy C and wish it was more verbose and more modern, try Zig.
As someone who never liked writing anything C++ since 2000+ (did like it before) I cannot agree with this. C++ and Rust are not comparable in this sense at all. One can argue Rust is what C++ wanted to be maybe. But C++ as it is now is anything but clean and clear.
See my other comment[1]
It replaces C++ for me, so I would say it's "a C++"
Re: Type resolution redesign, with language changes to taste
#127Earlier quoted context omitted.
Comparing Rust to C++ feels strange to me. It’s like people do it just because Zig is very comparable to C. So the more complex Rust must be like something else that is also complex, right? And C++ is complex, so… But that is a bit nonsensical. Rust isn’t very close to C++ at all.
I wrote lots of C++ before learning Rust, and I enjoyed it. Since learning Rust, I write no more C++. I found no place in which C++ is a better fit than Rust, and so it's my "new C++". For example, high performance servers (voltlane.net), programming languages ( https://github.com/HF-Foundation , https://github.com/lionkor/mcl-rs , and one private one), webservers (beampaint.com) and lots of other domains. Rust is cl…
> found no place in which C++ is a better fit than Rust, and so it's my "new C++".
Writing the compiler toolchains that Rust depends on, industry standards like CUDA, SYSCL, Metal, Unreal or the VFX Reference Platform.
Re: Type resolution redesign, with language changes to taste
#128Earlier quoted context omitted.
It is kind of interesting that the Linux kernel is slowly adopting Rust, whereas Zig seems like it would be a more natural fit? I know, timelines not matching up, etc.
Definitely not. Rust gives you a tangible benefit in terms of correctness. It's such a valuable benefit that it outweighs the burden of incorporating a new language in the kernel, with all that comes with it. Zig offers no such thing. It would be a like-for-like replacement of an unsafe old language with an unsafe new one. May even be a better language, but that's not enough reason to overcome the burden.
actually that's not true at all. Zig offers you some more safety than C. And it also affords you a compiler architecture and stdlib that is so well designed you could probably bolt on memory safety relatively easily as a 3rd party static checker
Re: Type resolution redesign, with language changes to taste
#129Earlier quoted context omitted.
> GC is a showstopper for my day job (hard realtime industrial machine control/robotics) Which is a very niche use case to begin with, isn't it? It doesn't really contradict what the parent comment stated about Go feeling like modern C (with a boehm gc included if you will). We're using it this way and it feels just fine. I'd be happy to see parts of our C codebase rewritten in Go, but since that code is security sen…
> Which is a very niche use case to begin with, isn't it? My specific use case is yes, but there are a ton of microcontrollers running realtime tasks all around us: brakes in cars, washing machine controllers, PID loops to regulate fans in your computer, ... Embedded systems in general are far more common than "normal" computers, and many of them have varying levels of realtime requirements. Don't believe me? Every c…
See TamaGo, used to write firmware in Go, being shipped in production.
Re: Type resolution redesign, with language changes to taste
#130Earlier quoted context omitted.
Zig is a modern C, Rust is a modern C++/OCaml So if you enjoy C++, Rust is for you. If you enjoy C and wish it was more verbose and more modern, try Zig.
C++ added OOP to C. Rust is not object-oriented. That makes your statement wrong.
It certainly is according to the various CS definitions of type systems.
Plenty of OOP architectures can be implemented 1:1 in Rust type system.