[flagged]
OpenD, a D language fork that is open to your contributions
171–180 of 322 posts
Re: OpenD, a D language fork that is open to your contributions
#172Earlier quoted context omitted.
Notice Rust actually forbids you from doing this to types you don't own. Rust's own standard library gets a pass. For example the [T] (a slice of T) generic type is a built-in, and the core library defines methods on that type, but in terms of sorting it only provides sort_unstable - an unstable sort, and the associated variants of that sort. Then Rust's alloc crate, which is optional, has a new impl block for [T] an…
Yeah I found it somewhat surprising too. Coming from kotlin I had expected this to be similar to extension methods but apparently not. I never fully understood the motivation behind this restriction.
Suppose I use Jim's birds crate, Sarah's noises crate and Hannah's shape crate.
If Hannah is allowed to write
impl birds::Goose { fn fudge(&mut self) { self.counter += 1; } }
and Sarah is allowed to write
impl birds::Goose { fn fudge(&mut self) { self.counter -= 1; } }
... Now what happens when I call fudge on a Goose? Does it increment the counter? Or decrement the counter? If instead the program is rejected because of the ambiguity, whose fault is the ambiguity? Sarah's fault? Hannah's fault? Jim's fault?
Re: OpenD, a D language fork that is open to your contributions
#173Earlier quoted context omitted.
What kind of solution would you propose to folks like your boss? One positive aspect I see about "rewrite it in Rust" is that you can to some degree expect a random Rust project to not leak and crash and expose vulnerabilities quite as much as a random C++ project. It's silly, but "written in Rust" acts somewhat as a badge of safety and performance, whereas "written in Java" and "written in C++" each only carry one o…
> What kind of solution would you propose to folks like your boss? Rewrite it in C#. It’s safer than Rust, because VM. Both standard and third party libraries are often way better. With modern versions of the language, GC allocations are avoidable if that’s what needed for performance reasons. C interop is equally simple.
Not necessarily VM, depending on how it gets deployed.
Re: OpenD, a D language fork that is open to your contributions
#174At least Walter, and presumably others in the D leadership, are active here. There's a good chance they will see your comments. This is just a reminder that they are human, too, they care a lot about D, and in my experience they are basically decent people who are trying their best.
More than 20 years passed and nothing really changed. What makes you think it will be different now. It's a "Tango" part 2 all over again. Except now, the ship has long sailed.
Re: OpenD, a D language fork that is open to your contributions
#175Earlier quoted context omitted.
The thing is, I just don’t want to write programs the way Rust wants me to. Among statically typed languages, Java is the closest to what I want to use but my true love is Common Lisp. With the arrival of Coalton, I can get the best of both worlds: a type system with nice properties for the rare program that would benefit from them and CL for the majority of programs.
Alright, so when I’m appointed Lord Emperor, we’ll all be writing CL. Until then, I’m digging Rust. It’s like garbage collection, but where you can always tell exactly when a thing is going to be collected.
Unless you happen to be using something like Rust/WinRT and to avoid the usual stop the world cascade deletion when smart pointers in a complex data structure all reach 0, have a background thread collecting those smart pointers.
Re: OpenD, a D language fork that is open to your contributions
#176Earlier quoted context omitted.
Rust is for people who stick around, can come over hurdles, can take in new concepts and see the overall benefits. It has a steep learning curve that pays off. For me there are three reasons why Rust is suitable for many usecases: - performance - safety - static binary compilation with targeting different cpu architecture After spending majority of my time with Python and Java in the last 10 years these are things i…
Performance and static binary compilation are available in 40-year-old languages, not forgetting Dlang, which is the central topic of this post. The only reason left to really use Rust is safety.
And the safety reason is also fulfilled with Ada/SPARK2014 as an alternative to Rust with a longer legacy in high-integrity applications.
Re: OpenD, a D language fork that is open to your contributions
#177Earlier quoted context omitted.
Yeah I found it somewhat surprising too. Coming from kotlin I had expected this to be similar to extension methods but apparently not. I never fully understood the motivation behind this restriction.
Suppose I use Jim's birds crate, Sarah's noises crate and Hannah's shape crate. If Hannah is allowed to write impl birds::Goose { fn fudge(&mut self) { self.counter += 1; } } and Sarah is allowed to write impl birds::Goose { fn fudge(&mut self) { self.counter -= 1; } } ... Now what happens when I call fudge on a Goose? Does it increment the counter? Or decrement the counter? If instead the program is rejected because…
I'd get what I import (explicitly). If I import conflicting extensions then its my fault for doing so and (only) my program fails to compile.
Re: OpenD, a D language fork that is open to your contributions
#178Earlier quoted context omitted.
Alright, so when I’m appointed Lord Emperor, we’ll all be writing CL. Until then, I’m digging Rust. It’s like garbage collection, but where you can always tell exactly when a thing is going to be collected.
Unless you happen to be using something like Rust/WinRT and to avoid the usual stop the world cascade deletion when smart pointers in a complex data structure all reach 0, have a background thread collecting those smart pointers.
There’s no plausible scenario in which I’d ever write a single line of Rust/WinRT.
Re: OpenD, a D language fork that is open to your contributions
#179Earlier quoted context omitted.
> it's cringe seeing key leaders talking down to people, or dismissing people's concerns, or just have this ego about themselves like they know what's best and everyone should shutup and just go along with them. That's not the case. The job of language designers is to say "no" all the time and Walter is certainly a model with how to speak with users.
I don't think Walter has ever intentionally talked down to anyone in my time, but his tone can be subtly belittling over some details. I don't think it's intentional but the argument always begins with explaining some detail as if you didn't know it existed even though you'd have to do be able to bring it up in the first place. This is not just me, I've had this discussion with a few people. One of a short list of co…
I haven't seen any of that tbh, I have seen a lot of disrespect come in direction of Walter and him responding in a gracious way actually. Criticism existence means it is allowed and thus is "open".
Re: OpenD, a D language fork that is open to your contributions
#180Earlier quoted context omitted.
Suppose I use Jim's birds crate, Sarah's noises crate and Hannah's shape crate. If Hannah is allowed to write impl birds::Goose { fn fudge(&mut self) { self.counter += 1; } } and Sarah is allowed to write impl birds::Goose { fn fudge(&mut self) { self.counter -= 1; } } ... Now what happens when I call fudge on a Goose? Does it increment the counter? Or decrement the counter? If instead the program is rejected because…
I'd get what I import (explicitly). If I import conflicting extensions then its my fault for doing so and (only) my program fails to compile.
You cannot import specific inherent methods. What you can do though is use the extension trait concept and import those traits.
If you import both traits you get an ambiguous function error and are asked to resolve which trait you want `::fudge(...)`.