71–79 of 79 posts
Earlier quoted context omitted.
Which projects use D as the main language ? Rust has Servo. Redox got some light. But D has always been a language's language.
I use D for econometrics. The ability to easily call C libraries and interoperate with R (D embedded in R and vice versa) is very handy.
Earlier quoted context omitted.
I… I just got corrected by Walter Bright. That's true. You actually can write an RTOS in D, and it would still be more pleasant than in C (thanks to D's excellent metaprogramming). The problem I have with opt-out GC in D is that it leaves you with very little else as far as memory safety goes—you have RAII, but nothing like Rust or Cyclone or other languages that are explicitly safe without a GC. You can leak, you ca…
D does have @safe, which does a good job of preventing large classes of unsafe pointer issues. It is not perfect yet (we're working on it) but it is far better than "nothing like", and far better than C/C++. For example, it does array bounds checking.
At the moment I'm pretty happy with OCaml and learning Rust, but D definitely has me interested (especially when the no-GC stdlib completes).
Earlier quoted context omitted.
I would want to create a microkernel, but that would be really hard so I'm targeting a hybridkernel design.
Have you checked out the GRUB features to load blob file systems for you into memory? It's one of the best ways to implement that kind of feature (for this sort of hardware). Do you sit on some IRC somewhere? I'd be interested in talking to you about how you're approaching this work. Very cool
Earlier quoted context omitted.
What "functional stuff" are you referring to? I don't consider Rust a particularly functional language, other than the fact that it has closures and the ability to `map` over iterators. And if closures and `map` are your benchmarks for functional stuff, then Python, Javascript, and Perl have been doing functional stuff for decades now. :)
There is quite widespread use of monads in the standard library (albeit with a very targeted effort to hide their nature and make them very concrete).
Earlier quoted context omitted.
There is quite widespread use of monads in the standard library (albeit with a very targeted effort to hide their nature and make them very concrete).
Can you give an example? I can't think of anything in the Rust standard library that I consider a "monad".
The fact that they don't implement pure/return doesn't change the fact that they have monadic interfaces because that would only be useful once it was generalized to its own trait, and such a function would be trivially implemented for any of these types. For example, Some(x) works as the return/pure function for Option and the fact that the name differs for each type is not an issue because there's no way to make code generic over all monads as it is. It would be like having a unique trait for each type where there's `bind_option` and `bind_result`, etc.
Earlier quoted context omitted.
Can you give an example? I can't think of anything in the Rust standard library that I consider a "monad".
Iterators are monadic (since they have a flat_map method), Option and Result have the and_then method. Both of these are equivalent to >>=/bind. The fact that they don't implement pure/return doesn't change the fact that they have monadic interfaces because that would only be useful once it was generalized to its own trait, and such a function would be trivially implemented for any of these types. For example, Some(x…
Regardless of what we determine there, I don't think that matters in the broader context of this thread, which concerns the notions that Rust has the potential to scare people away by including unfamiliar "functional stuff". But seeing an `.and_then` method doesn't scream "functional programming"; method chaining has been long popularized in Javascript, Ruby, etc. Furthermore, AFAIK there's nothing about Rust's pseudo-monadic interfaces on iterators that hasn't already been popularized by LINQ in C#.
The creator of PowerNex, Wild, streams the development on Livecoding as well, if anyone wants to watch. https://www.livecoding.tv/wild/
Yep, been following his streams on and off on there. Sad that livecoding.tv hasn't become big, but I can see why honestly.
Earlier quoted context omitted.
Andrei Alexandrescu, one of chief architects of D answered this a while ago on Quora [1]. IMO, this is a fair and nuanced answer. [1] https://www.quora.com/Which-language-has-the-brightest-futur...
Hehe, I saw a talk with the creators of Rust, D, C++ and Go. No one of the "older" fellas even knew the Rust guy and I don't even know anymore who he was, was it Hoare? Maybe. C++ was about "We get things fixed, I promise!" D was about "We get shit done!" Go was about "We are good enough!" Rust was about "We try new shiny things!"
Earlier quoted context omitted.
It sounds you like you asking for more toy OSes. Supporting POSIX is necessary if the designer wants the OS to run real software.
That sounds somewhat defeatist. Taken to it's logical extreme, wouldn't that mean we'll never have anything better than POSIX? Or are you suggesting more of an 'embrace and extend' thing, where a new OS supports POSIX for backwards compatibility but adds whatever new API(s) and then tries to grow adoption of those slowly?
Basically, if you want to make an OS that's immediately useful, it has to run software that's available right now. That means either Windows (Win32 or .NET) or POSIX or maybe whatever Mac uses. That's it.
Now of course, you can try to build an OS that has backwards compatibility for one standard and adds a new one. MacOSX did that to an extent to ease the transition from their older version. Windows does that too, supporting multiple APIs (even POSIX at one point).
However, even here, these standards still require an OS to work a certain way underneath, which all current OSes do to a good extent. If you want to do something really, really different, it might not be so easy to build an emulation or compatibility layer. That's just the price of progress; if you want to do a clean-sheet design, you're going to sacrifice compatibility with everything that came before. If you build in backwards compatibility, that's going to limit how different you can be.