
Ask HN: What are the less-mentioned drawbacks of acclaimed software / libraries? - higerordermap
There are some projects often mentioned for their technical superiority. Eg:
    * LLVM
    * Rust
    * Qt
    * F#
    * Mac OS<p>And there are many more in the list.<p>Now, apart from non technical things (eg: license complications of Qt), what are the drawbacks of such &#x27;acclaimed&#x27; software programs or libraries that people should know?
======
PaulHoule
Maybe Qt is better than GTK. Does anybody claim Qt is better than the native
widgets on any platform that has native widgets?

With Rust you can write safe and fast programs but you will spend a lot of
time and mental energy fighting with the compiler. Go ahead and write C/C++
but remember that your life insurance doesn't pay out if you get killed
playing Russian Roulette. For many cases people are happy with managed
languages such as Java, C#, Python, etc.

F# is a similar story. It has benefits, but they really aren't enough to
displace other languages.

MacOS? I like APFS. On MacOS they always reserve enough space for the text on
a button in the UI. Send in a ticket for a problem like that to RHAT and you
will get verbal abuse before they close it. (e.g. the 'Linux Desktop' is a
Potempkin village) Windows sometimes gets confused when you have a large
number of monitors with different dpi plugged in but it is nothing a reboot
won't fix.)

Inside the dirty secret is that there is not a big difference in how modern OS
really work. They all divide interrupt handlers into a top and a bottom, they
all support POSIX system calls or something that is a POSIX rip-of (e.g. look
at the MS-DOS syscalls) "Microkernels" are usually huge and wracked with
optimizations, in real-life Unix has become "Plan 9 in Userspace".

A really superior OS would have to remove bloat, maybe the die-area eating
space heaters such as the MMU and TLB. It would probably have a different
viewpoint about synchronous vs asynchronous. If it was different enough to be
"superior" than old code wouldn't run, you'd have to write the whole userspace
-- so you'll stick to a POSIX API.

IBM knew how to make a universal instruction set architecture in 1965, but had
no vision of a general-purpose mainframe OS until academic researchers
invented "VM" which let them run three or five different OS on the machine so
they didn't have to pick just one.

By 1995 the POSIX API is established and it is about as universal as the 360
instruction set. It is used in my car stereo, home theater receiver, TV set,
tablet, internet router, PC, server, etc.

Even the "real time" or "reliable" OS used in a spacecraft or automotive
application is likely to present itself as POSIX.

MacOS uses mach to emulate POSIX and mach lets you do a bit more than POSIX,
but Linux has been subdividing the 'process' concept for a long time as has
Windows NT. FUSE descends into microkernel insansity
("Plan999999999999999999999 from userspace")

------
phendrenad2
Anyone who says something has "technical superiority" is living in a fantasy
world. Everything has pros and cons, and it's impossible to account for every
variable upfront. You may be 99.999% done with a project only to realize that
another language/framework/OS/etc. would have been better.

