The bright yellow color can be used perfectly if the design style wasn't flat. It's incredible how much more legible UI elements can be if you add some shading, gradients, 3d borders, anything!
> It may sound stupid, but you can't have unhandled exceptions if you don't have exceptions...
> panic!() exists in Rust, but that's not how recoverable errors are handled.
This is the worst argument in the whole article, and this is the worst part of the language. Everyone says it's not like exceptions, but in fact it is much worse. Panic is stringly typed and you can catch_unwind it, just like with try/catch in any other language. And the actual worst part of it, you will never know if a panic can occur in any of the underlying functions until it is too late. Developers be damned if they want to choose different behaviour other than crashing the whole program.
Either double down on using the standard error handling everywhere, or put something like "throws panic" in the function signature (ala Java checked exceptions). Many parts of the language has strict checks for everything, why does panic has to be an outlier?
And then you encounter some ancient apps without GNU readline support (oracle sqlplus and mysql, I'm looking at both of you). No history support, cursor keys emit characters on the line, literal hell when trying to quickly fix remote database...
My idea is that a CPU is just a component and it's useless by itself without considering the rest of the computer system. ARM needs to dip more into standardising the rest of the picture, and the RISC-V guys could also start looking into creating an open computer architecture initiative/group to prevent further fragmentation.
> ARM's less open platform also comes with some advantages though. It's easier for ARM to prevent ecosystem fragmentation and non-standard instruction set extensions.
It's kind of funny way of looking at the core part of the ARM ecosystem while forgetting how much outside of the CPU is non-standard, undefined. None of the ARM devices share bootloader, device enumeration, and a plethora of things needed for an open, non-fragmented OS/Software ecosystem like how PC does.
Maybe you can run parts of the same ARM machine code on most devices, but it's not terribly portable to be honest, it has to be very generic. For example, Android devices end up in a pile of trash because you can't just upgrade the kernel to the latest version on a 1, 5, 10 year old smartphone without losing functionality or being stuck at step 1 for the lack of tools from broken forum links and shady fileshares. So much for software flexibility...
You should explain what's wrong with the argument instead of being a passive agressive asshole. It was a continuation of why it happens nowadays that people swing to static linking and then posts like this get shamelessly upvoted.
Tell me how much of the system libraries are written in C or C++, and how much of them are being written in newer languages.
C is the default choice because of its ABI, and the tooling around it is made for using shared libraries.
What can you say about modern languages? Each of the languages are designed to work in a silo and not much cooperation for let's say, system plumbing. Their own package manager makes it easy to pull in code, and only make code for that language only. You can't just create a package that works as a shared library for other programs without mushing around C FFI. They make it hard by default, which creates resistance in developers to make a piece of code usable by others other than their own language. This trend is pretty alarming, especially when hidden and manipulative language fanboyism is showing its ugly head everywhere.
I certainly don't want each installed desktop app to have a copy of base gnome/kde runtime and everything down to libc. And the implication is even the graphics would be duplicated, for example the Adwaita icon pack is huge. So if I have a full set of gnome applications (say 50) would I have 50 copies of Adwaita icon set? Suddenly disk space isn't cheap. Shared libs are good and we could do better than flatpaks and containers and static linking.
And just because shared libs are PITA it's not just because of their nature, it's the lack of tooling from supposedly modern languages, lack of guidance, lack of care for versioning and API stability, and distro agnostic convention. Each of these problems can be solved by not sweeping them under the rug.
> the amount of parallelism they were able to use, which was impractical in C++
You mean after not using OpenMP, basic multithreading core guidelines, and not doing the refactoring with sanity checkup in TLA+, tools that end up on the frontpage everytime people rediscover them.
Oh come on now. If it was really important for them then why did they chose C++ a long time ago after deciding to rewrite Netscape from scratch? Their history is full of dumb choices and now suddenly going full Rust is the most important thing because... the codebase is lousy? It's not gonna bring back any new/old users, and right now the web needs a healthy marketshare.
Who knew using already existing data race analysis tools is much more feasible than shoehoning a huge project into a brand new language. Way to go mozilla!
It's not just wayland. For every single thing you can do on linux there exists several hundred different implementations/projects with the same goal of do that thing, and it has led to bad cohesion between system components. Even Microsoft couldn't figure out how to drop Win32 and introduce other safer environments without alienating everyone. How can we expect Linux to survive and become better if we treat everything in it with such a garbage attitude.
You have been trying to reinvent the wheel for a decade and splitting the whole community on petty shit like this, halving development effort on an already non-popular platform, and yet you wonder why people are angry. Instead of evolving X11 and deprecating old features to drop tech debt over time, you went and created your snowflake project and paraded over how much more secure your project is when it doesn't have features to this day, features which are working perfectly on X11. This blog post is the epitome of the whole wayland development group's selfishness. You did this thing for yourselves, for your own comfort and feel-good bullshit, not for the whole community. The Linux ecosystem has suffered too much for no good reason, to the detriment of user experience and market share.
> pywebview is a lightweight cross-platform wrapper around a webview component that allows to display HTML content in its own native GUI window. You may think of as Electron for Python (minus huge executable sizes). It gives you power of web technologies in your desktop application, hiding the fact that GUI is browser based.
It's still as bad as electron and calling it native is a stretch.