[flagged]
Type resolution redesign, with language changes to taste
221–230 of 284 posts
Re: Type resolution redesign, with language changes to taste
#222Earlier quoted context omitted.
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.
Yes, of course you can call objc_msgSend or equivalent in Rust just as you can in C. But you are pushing the object-oriented model into a library. It is not native to the language.
I am talking about Rust OOP language features for polymorphism, dynamic and static dispatch, encapsulation, interfaces.
Which allowed me to port 1:1 the Raytracing Weekend tutorial from the original OOP design in C++ to Rust.
Also the OOP model used by COM and WinRT ABIs, that Microsoft makes heavy use of in their Rust integration across various Windows and Office components.
Re: Type resolution redesign, with language changes to taste
#223Earlier quoted context omitted.
Thus Rust cannot really replace C++ when its reference toolchain depends on it.
If you define success for Rust as "everything is written in Rust", then Rust will never be successful. The project also doesn't pursue success in those terms, so it is like complaining about how bad a salmon is at climbing trees.
That is however how the Rust Evangelism Strike Force does it all the time, hence these kind of remarks I tend to do.
C++ is good for some things regardless of its warts due to ecosystem, and Rust is better in some other ones, like being much safer by default.
Both will have to coexist in decades to come, but we have this culture that doesn't accept matches that end in a draw, it is all about being in the right tribe.
Re: Type resolution redesign, with language changes to taste
#224Earlier quoted context omitted.
So it isn't just a matter of "they would use Rust instead". There is a whole ecosystem of contributions across the globe and the lingua franca used by those contributors.
> There is a whole ecosystem of contributions across the globe and the lingua franca used by those contributors. which is slowly changing with wider rust adaptation.
Where are the LLVM pull requests adding Rust code?
Re: Type resolution redesign, with language changes to taste
#225Earlier 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 what you want to write, because it gets out of the way. Rust is what you want your colleagues to write, to enforce good practices and minimise bugs. It's also what I want my past self to have written, because that guy is always doing things that make my present life harder.
zig really makes it unappealing to architecture astronaut, and rust pushes you towards it. id rather my colleagues write zig
Re: Type resolution redesign, with language changes to taste
#226Earlier quoted context omitted.
It is insane and you are completely right. This has been a part of programming for over 50 years. Unfortunately you aren't going to get anywhere with zig zealots, they just get mad when confronted with things like this that have no justification, but they don't want to admit it's a mistake.
But even the solutions would be so trivial - have a separate 'prod' compiler flag. With that, make these errors, without make these warnings. Problem solved, everyone happy.
You are right of course, the solution is trivial.
They also made a carriage return crash the compiler so it wouldn't work with any default text files on windows, then they blamed the users for using windows (and their windows version of the compiler!).
It's not exactly logic land, there is a lot of dogma and ideology instead of pragmatism.
Some people would even reply how they were glad it made life difficult for windows users. I don't think they had an answer for why there was a windows version in the first place.
Re: Type resolution redesign, with language changes to taste
#227Earlier quoted context omitted.
"More safety than C" is an incredibly low bar. These are hygiene features, which is great, but Rust offers a paradigm shift. It's an entirely different ballpark.
negative. For example bounds checking is turned on by default in Zig, which prevents classes of overflow safety errors.
[deleted]
Re: Type resolution redesign, with language changes to taste
#228Earlier quoted context omitted.
I am going to ask a question that is is definitely not the place for, but I am not involved with Zig in any way and am curious, so I hope you'll indulge me. I noticed the following comment was added to lib/std/multi_array_list.zig [0] with this change: /// This pointer is always aligned to the boundary `sizes.big_align`; this is not specified /// in the type to avoid `MultiArrayList(T)` depending on the alignment of…
I had to search for this, but managed to find the relevant mlugg@ comment[0] on the ZSF zulip: > i had to change the bytes field from [*]align(@alignOf(T)) u8 to just [*]u8 (and cast the alignment back in the like one place that field is accessed). this wasn't necessary for MultiArrayList in and of itself, but it was necessary for embedding a MultiArrayList(T) inside of T without a dependency loop, like const T = str…
Ah, that makes sense. Thanks for pulling this up!
Re: Type resolution redesign, with language changes to taste
#229Earlier quoted context omitted.
I had to search for this, but managed to find the relevant mlugg@ comment[0] on the ZSF zulip: > i had to change the bytes field from [*]align(@alignOf(T)) u8 to just [*]u8 (and cast the alignment back in the like one place that field is accessed). this wasn't necessary for MultiArrayList in and of itself, but it was necessary for embedding a MultiArrayList(T) inside of T without a dependency loop, like const T = str…
Ah, that makes sense. Thanks for pulling this up!
He went into it a bit more over on Ziggit today too. I only noticed it way after I went digging: https://ziggit.dev/t/devlog-type-resolution-redesign-with-la...
Re: Type resolution redesign, with language changes to taste
#230Earlier quoted context omitted.
> There is a whole ecosystem of contributions across the globe and the lingua franca used by those contributors. which is slowly changing with wider rust adaptation.
Where are the LLVM pull requests adding Rust code?
I am not expert in compilers, but in databases space there are multiple prominent projects which gain traction, create ecosystem and making Rust strong contender against C++ dominance.