Yes, Synaptics produces closed-source drivers for Windows and ChromeOS. ChromeOS also uses its own low-level input/graphics stack, not X11, so even if you had the code to it you wouldn't be able to just compile it on GNU/Linux.
2,630 karma · joined October 31, 2018
fastcgi applications can "scale to 0" and cost nothing when they are not used. An application server must always have at least one open socket on a running machine.
fastcgi would probably do better over http/2 than other protocols not designed for multiplexing.
I think it might have been Zoom a couple years ago. If I install a desktop application that isn't some command line utility, it's a big deal, like a new girlfriend, feels like a committment. It better be a real appliance that actually requires access to hardware and would need to stay open most of the day.
I struggle to think of the audience for these kinds of concerns about "desktop GUI". If the customer is enterprise, government, etc., then they will want WinForms/C# or Java/Swing and you simply don't get to pick Rust, Go, etc.
If you just need a user interface, GUI nowadays means web or mobile (ideally SwiftUI).
Let's face it, in 10 years, there aren't going to be many people using desktops. The people that will be using desktops (like me) probably will be fine with and prefer curses interfaces that run in a terminal emulator. There you go, that's your cross-platform GUI.
Reproducible builds (as in bit-for-bit) means I can trust a (secure) checksum of a binary I downloaded somewhere, let's say from IPFS. This is defense-in-depth, adding another layer of security to prevent sabotage.
Reproducibility means the whole system can reliably be built from source and I don't need to manually make sure the system has the correct constellation of implicit dependencies and their version numbers. This saves time and money in deployment and will pay off in a very big way 10 years down the line when that code is still in use somewhere.
Also dynamic typing is more productive (for application code, not talking bootloaders here). It's a measurable fact and apparent to anyone who has written code long enough. Writing out types for everything is mostly pointless clerical work which should be able to be done by computers.
This will be in VS Code one day, except when it's there it will be for all languages (some neural code completion engine) and do much more.
There are times you need manual memory management. Then there are other times you don't (the vast majority of use cases). Rust forces you to constantly pretend that memory management matters, which gets quickly tiresome.
Not everyone is working on Chromium or Windows. The reality of the matter is that for most real-world software development security doesn't matter at all.
- Fast compile times
- Easy build system. Must be parallel, saturate all cores, and handle distributed builds as a built-in first-class feature. Should be able to produce static binaries or dynamically linked binaries. Should be able to consume binary dependencies (that means a stable ABI).
- Optimized, fuzzed, highly-tested, standards compliant web stack built-in
- Ability to compile CUDA kernels, built-in
- Automatic memory management with an escape hatch for where manual is necessary
- Rich metaprogramming and compile-time reflection
- Created by or funded by a large U.S. corporation so that PMs are likely to choose it.
- IDE/LSP language server/editor plugins maintained by the language designers
Failing this, you are an academic language, not a real world industry programming language in 2020.
There's nothing wrong with that. If string interpolation is really useful, then Java will add it some years down the line.
It's cheap to add features but literally impossible to remove them. There's no way to undo a mistake in language design. That's an asymmetry. I'd rather err on the side of caution than kitchen-sinking it.
#include <cstdio>
int main() {
auto square = [](double x) -> double { return x*x; };
printf("%f\n", square(10));
return 0;
}
I prefer the Go approach which lets you host or import packages via a HTTP or git URI. If you have to have packaging built-in to the standard toolchain these days, then please use already well-known and existing protocols like DNS and git. Java also figured this out years ago (com.sun... etc).