Agreed. Gnome shell is actually super keyboard driven. But the KDE folks point out the fact that there isn’t a start menu to click and declare it bad UX. It’s just sad.
It may be keyboard driven, but especially under Wayland (see Talon [0]), it's almost unusable for disabled users. The situation was better a few years ago.
Doesn’t this just lead to the world where every application has its own specific schema and we lose any ability to operate on files in generic manner? So basically like iOS, and I don’t see many people using iOS as their development environment.
You may be correct in theory though in practice the reason to use Async over threads is often because the crate you want to use is async. Reqwest is a good example, it cannot be used without Tokio. Ureq exists and works fine. I've done a fairly high level application project where I tried to avoid all async and at some point it started to feel like swimming upstream.
Some of these worries make sense, but wouldn’t it be relatively trivial to pass a flag to the interpreter or something similar in order to force all imports to evaluate, as in the current behavior? But to be a bit cheeky if some of these issues cause serious production outages for you it might be time to consider moving on from a scripting language altogether.
The issue is that some imports can be made lazy and some cannot. A binaristic all-or-nothing approach does not address the issue. (I also think that there is zero basis to claim that adding such a flag is trivial, since there’s no reference implementation of this flavor of lazy imports.)
What if we have a program where one feature works only when lazy imports are enabled and one feature only when lazy imports are disabled?
This is not a contrived concern. Let’s say I’m a maintainer of an open-source library and I choose to use lazy imports in my library. Because I’m volunteering my time, I don’t test whether my code works with eager imports.
Now, let’s say someone comes and builds an application on top of this library. It doesn’t work with lazy imports for some unknown reason. If they reach for a “force all imports” flag, their application might break in another mysterious way because the code they depend on is not built to work with eager imports. And even if my dependency doesn’t break, what about all the other packages the application may depend on?
The only solution here would be for the maintainer to ensure that their code works with both lazy and eager imports. However, this imposes a high maintenance cost and is part of the reason why PEP 690 was rejected. (And if your proposed solution was “don’t use libraries made by random strangers on the Internet”, boy do I have news for you...)
My point is that many things _will_ break if migrated to lazy imports. Whether they should have been written in Python in the first place is a separate question that isn’t relevant to this discussion.
Maybe the package that requires lazy can somehow declare that requirement, so another package that tries to force not lazy will fail early and realize it needs to replace this dependency with something compatible or change its ways. It definitely adds complexity, though.
Or check at runtime if it's running with the lazy import feature active. Then instead of breaking in mysterious ways in production it would crash on startup, during development.
Theoretically the implementation may use the approach "as lazy as possible". Traverse lazy imports until you encounter a regular one.
I doubt it will make much difference, but at least it gives an option.
I find it telling that the original creators of electron are now writing a new editor with native code because even they can’t stand electron. It’s like they are trying to write a wrong they did to the world.
Xcode, Visual Studio (the original I mean), PyCharm et al., Eclipse, vim, emacs, Notepad++, Sublime… hmm that’s all the IDEs and text editors I can remember using significantly in a professional context. I prefer VSCode to those.
compared to... nothing... I love it. It's subjective. I love what it does and it's my favorite piece of software because it does what i need it to do, every time, all the time.
When you are writing and thinking about code, you are making progress. You are building your mental model and increasing understanding. Compile time is often an excuse to check hacker news while you wait for the artifact to confirm your assumptions. Of course faster compile times are important, even if dwarfed relatively by writing the code. It’s not the same kind of time.
The only thing I feel like is missing from niri is a scratch layer. There are some apps that just don’t need to be tiled and it’s nice to have access to them immediately no matter “where” you are. Perfect example is matrix client. If the wife texts me I want to become able to pop that sucker up immediately and reply, not find the “matrix client workspace”. Plus it’s tiny and doesn’t need to be tiled. Same with media players.
Yeah, I have been wanting this. The way it works on Sway is "okay", but it would be nice to have a floating workspace that can be shown or hidden on top of whatever your active workspace is. The workaround most people are using seems to be a named workspace for scratch.
In my case I've found niri's workflow quite nice for these scratch windows, since every new window opens to the immediate left of the currently focused window, and doesn't affect the size or tiling of any other windows, they're just shifted to the right.
Many of those apps minimise when closed and reopen when calling, so often it is not really an issue (although it's sometimes annoying that you have to specifically tell the apps to exit when you do want to close).
reply