With all the different variants of Linux and customization, I have yet to find a desktop environment that I'm actually happy with. Windows has a lot of features I like, they built on them and make them better. For Linux it usually seems there's no direction, they are all spread thin or not optimized and are slow. Even things like file explorers, since they all need to make their own, they are lacking in comparison to Windows. It is incredibly frustrating to be able to do something in Windows file explorer, and to not be able to do the same thing on Linux and instead have to open up a terminal to do something that just takes 2-3 button presses with a proper GUI.
Dolphin is better than Windows Explorer IMO. What can't it do? I would say Dolphin is just above Explorer in terms of the 'top' graphical file managers across operating systems
I don't really like KDE, so of the environments I've used, they don't use Dolphin. You can install it otherwise, but it tends to be buggy. Part of it too is that when you open/save a file in Windows, it effectively gives you a file explorer. There are some apps that roll their own, but on Linux basically all of them roll their own. A lot of the times they lack features like simply being able to create a new folder when you are saving something.
Dolphin is better than any other Linux file managers but Windows Explorer is best IMO. In directory that contains many files, Windows Explorer runs quickly but Dolphin isn't quick as it (and alternatives are much worse). Also I like ribbon UI on Explorer.
Exactly, Google prefers to automate this sort of thing. Youtube has similar problems and it's equally as impossible to reach a human being to get the problem sorted out.
D's borrow checker fails in comparison to Rust's. It serves very little purpose and provides almost no guarantees. These issues have been brought up multiple times but they are brushed aside with ignorant responses like "I've been told my entire career what I'm doing will fail but I continue to do it anyways".
Rust was designed from the ground up and every feature is implemented and designed to work with its borrow checker. So it is able to provide a definitive guarantee that memory isn't free'd or used after it is free'd. The only exception is in "unsafe" code, where you can break the borrow checker. But this limits where you have to worry about potential bugs.
In D, the ""borrow checker"" is being tacked on as an after thought, in an attempt to copy Rust. This means that it doesn't play nice with existing features and makes it difficult if not impossible to guarantee that memory isn't leaked or used after it was free'd. For example with exceptions. The checker doesn't check for exceptions and if memory is free'd correctly if an exception is thrown. This isn't a problem in Rust because it doesn't have exceptions so it doesn't have to worry about checking them so it can maintain its strong guarantee.
> This isn't a problem in Rust because it doesn't have exceptions
Rust does have something similar to exceptions when compiled with "panic=unwind" (the default). It uses the same mechanism as C++ exceptions to unwind the stack (while calling all the necessary destructors), can be caught (std::panic::catch_unwind) and rethrown (std::panic::resume_unwind), and has some of the same concerns as C++ about "exception safety" (mostly within unsafe code - the programmer has to take care to leave the objects in a safe state when it can unwind).
I didn't know that used something akin to exceptions. Still panics aren't as common as exceptions (in D), and still only have to worry about unsafe code (for the most part).
Rust guarantees memory safety, or are you saying D isn't similar in that regard as well? If that's what you are saying, then I agree completely. D's ownership/borrowing does not provide memory safety, and that makes it pretty much useless.
There's really no point discussing this with you any further. You don't contribute anything to the discussion. That's just PR babble, and provides zero information and doesn't even deny the fact that exceptions break memory safety with D's borrow checker (you know it that's why you don't deny it like a "good" PR person).
> I don't know anything about D so I wanted to pick something that I was certain his analyzer would fail one way or the other.
What he is talking about is a proposed implementation of the solution. It isn't actually in the D language yet. No one's tested it (except for Walter). So I would definitely take its' validity with a grain of salt.
