4 ms·

The history of computing has many examples of products and languages winning out over technically superior alternatives for non-technical reasons. Like Linux ga

by ajxs 2y ago

The history of computing has many examples of products and languages winning out over technically superior alternatives for non-technical reasons. Like Linux gaining a lot of momentum because of the BSD lawsuit. This[0] is one of my favourite comments on HN. It shows us one of the paths not taken in the evolution of operating systems. > It's okay to like the project strictly because of the language chosen. I think that the massive groundswell of interest around Rust will end up being positive overall. At this point I can't see us going back to the way things were. I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust. 0: https://news.ycombinator.com/item?id=32604842 https://news.ycombinator.com/item?id=32604842

bigstrat2003 2y ago
That comment was great. It's so hard for me (raised on Windows and now immersed in Linux) to imagine something so foreign to the OS paradigms I'm used to. It just goes to show how much the things you are used to can limit your thinking.
- beagle3 2y ago
  Windows NT was supposed to be a modernized VMS (And legend has VMS+1=WNT, each letter individually…) - and given a face similar to Win 3.1 (and then 95/98/Me and then they were unified in XP) It has a lot of the VMS features, and most of them are unused or effectively only used by malware (e.g. alternate file streams). I did not get a chance to use VMS myself, but I did use Unix (and VMS/CMS, and a bunch of other OSes) at a time VAX was still a viable alternative even for greenfield projects. My impression is that it is sort of like J/K/APL - powerful, compact, coherent, got almost everything right from a technical standpoint - but not friendly, feels foreign, and not liked by anyone who has ever used a Unix, or Windows, or a Mac - which is 99% of the relevant population since about 1985. (Added): Macs also had multiple file streams (“forks”). It doesn’t anymore, for many reasons, but the chief one is interoperability. Less is more, worse is better.
  - pasc1878 2y ago
    Re file streams yes classic macOS did have them current macOS does not but it does not need them as you can use Bundles instead which are Unix directories that are treated as a whole by the SDKs.
  - SirHumphrey 2y ago
    Which goes to show why *nix won over more feature rich alternatives - the human element. Being feature rich makes the learning curve (usually) much steeper but tends to help in the long-term, while shifting the complexity in to userland means that if I don't need a feature, it needn't concern me. You trade ability for reduction of complexity - getting an operating system that you can learn in months instead of years, which - since the tech industry has been in hipper-growth phase for much of the last 30 years, was more important.
    - EVa5I7bHFq9mnYK 2y ago
      Being free didn't hurt either.
      - pjmlp 2y ago
        Indeed, had AT&T been able to sell UNIX at VMS prices (or whatever else OS from those days) from day one, without access to source code, and history would have taken a different path, regarding UNIX and C adoption.
  - fuzztester 2y ago
    >Windows NT was supposed to be a modernized VMS (And legend has VMS+1=WNT, each letter individually…) - and given a face similar to Win 3.1 Same with HAL (1) and IBM, I read somewhere once. (1) The one from https://en.m.wikipedia.org/wiki/2001:_A_Space_Odyssey https://en.m.wikipedia.org/wiki/2001:_A_Space_Odyssey Google hal ibm connection.
  - p_ing 2y ago
    > Windows NT was supposed to be a modernized VMS Given Cutler hated UN*X, that only makes sense. NT did a lot of things right at the kernel level. > and most of them are unused or effectively only used by malware (e.g. alternate file streams). "Most of them unused"? ADS was added to NTFS to support Mac OS file sharing over AFP ("Services for Macintosh"). Microsoft makes use of it for downloads from Edge, among other things. It's otherwise not a supremely useful feature and one that you'll silently lose data when moving to another fs/www further degrading it's usefulness.
b112 2y ago
I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust. Am I allowed to sigh here? It's a good thought, but this is humanity we're talking about here. All it requires is some big-project, some big-corp creating some essential ecosystem with lame-language-A, and now it's got traction. And frankly, look at rust and its weird crates. Weird as in "Let's make a super-safe language, then import random stuff from unknowns, unaudited, and just hope it all works out." If rust was really serious about security, only signed crates from validated developers, with code review would be the norm. Oh but wait, that'd be "not easy".
- pdimitar 2y ago
  What's your suggestion, exactly? Vetting code is extremely expensive in terms of human time and human energy. Sadly it's not only a problem for Rust, it's a problem for every single programming language out there.
bawolff 2y ago
> The history of computing has many examples of products and languages winning out over technically superior alternatives for non-technical reasons. While this is undoubtedly true, i suspect that there are also many cases where people presume the reasons are non-technical but when examined closly turn out to have hidden technical issues.
lII1lIlI11ll 2y ago
> At this point I can't see us going back to the way things were. I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust. Zig seems to be gaining traction. Hard to predict whether it will succeed or slowly fizzle out after the initial excitement phase though.
- dralley 2y ago
  Is Zig gaining traction? It almost seems like the project has gone radio silent in the past year. It's hard for a language to get traction when it's not even 1.0 and there's not much of a roadmap on how and when they'll get there.
Galanwe 2y ago
> I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust. I don't think safety is a 1 dimensional spectrum (say from 0% to 100%). I view it more as a multidimensional thing, and tradeoffs between these dimensions. Rust invested a lot on _some dimension_ of safety, which is essentially static borrowing and aliasing. And the tradeoffs for this are numerous: Dynamic safety is either much harder in Rust (due to unsafe being vastly more dangerous and hard to get right vs say, a C program), or at the expense of performance (I.e. just Arc<Mutex<>> or copy everything). That also comes at the expense of an immense cognitive burden for the programmer. I see a lot of space for different tradeoffs on different dimensions of safety.
- oneshtein 2y ago
  > due to unsafe being vastly more dangerous and hard to get right vs say, a C program It's not true. Both C (clang), C++, and Rust use same LLVM compiler, so both have same constraints in the unsafe mode. C/C++ developers just not care.
  - cataphract 2y ago
    I don't think this is true. Rust has constraints that C/C++ doesn't have. For instance, it's undefined behavior to create more than one exclusive (mutable) reference to the same object or to create one where a shared reference already exists. This is not necessarily easy to ensure. The aliasing rules in C are much more lax: you only can't have several pointers of different types pointing to the same object, except if one of them is a character pointer (ignoring the restrict keyword, which is opt-in and rarely used).
    - mrcsd 2y ago
      I don't think this is quite the same comparison. In Rust, multiple mutable pointers to the same object can exist at the same time. So, it's similar to C in this way. It is mutable references that must be exclusive.
      - 2y ago
cardanome 2y ago
> At this point I can't see us going back to the way things were. I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust. I see Rust being used in many context where it's safety features aren't really needed or even a hindrance like game dev. Honestly the safety is overstated in importance. The amazing tooling, decent package manager, great error messages, the inclusive community, the type system that took the low hanging fruits from the academic functional programming world, are much more relevant for its success. The problem with Rust is that it made using languages without automatic garbage collection acceptable again and I am not sure if this is good. The borrow checker is a neat solution and might be a good fit for certain niches but automatic garbage collection is just vastly more ergonomic to use. We had Lisp Machines, we need to go back to future.
- the__alchemist 2y ago
  I'm with you - I like Rust for the overall pros/con balance, in context of with its alternatives. Safety is one thing. The tooling, error messages, type system etc you mention is another. Having mutable references as function parameters is another big one, shared by surprisingly few alternatives.
  - vlovich123 2y ago
    Safety and the hype reels you in and the qol hooks and keeps you.
    - lproven 2y ago
      Is that QOI or QOL, and what does it stand for?
      - vlovich123 2y ago
        Quality of life
- zozbot234 2y ago
  GC implementations are widely available in Rust. You don't have to use garbage collection in Rust, but it doesn't stop you either. You just have to import some custom crate and 'implement' tracing for your own data types.
baranul 2y ago
> The history of computing has many examples of products and languages winning out over technically superior alternatives for non-technical reasons. Unfortunately, the history shows that such technically inferior languages and products winning out are also because of outright market manipulation by their corporate backers, tons of money in ads, or attacks on competitors. The elephant in the room, is to look at what's generating or paying for the hype and marketing behind recent programming languages like Rust and Zig (for example). > I think that the massive groundswell of interest around Rust... A review of the groundswell, around Rust or Zig, is its not attributable to just grassroots or genuine interest, and can significantly be the result of outright astroturfing and artificial brigading. Sadly, many people follow along with the marketing or are bombarded into submission, "must rewrite in X" or "GC all bad and manual all good" foolishness, versus actual use case and legitimate examination of language tradeoffs.

by ajxs 2y ago

bigstrat2003 2y ago

That comment was great. It's so hard for me (raised on Windows and now immersed in Linux) to imagine something so foreign to the OS paradigms I'm used to. It just goes to show how much the things you are used to can limit your thinking.

beagle3 2y ago
Windows NT was supposed to be a modernized VMS (And legend has VMS+1=WNT, each letter individually…) - and given a face similar to Win 3.1 (and then 95/98/Me and then they were unified in XP) It has a lot of the VMS features, and most of them are unused or effectively only used by malware (e.g. alternate file streams). I did not get a chance to use VMS myself, but I did use Unix (and VMS/CMS, and a bunch of other OSes) at a time VAX was still a viable alternative even for greenfield projects. My impression is that it is sort of like J/K/APL - powerful, compact, coherent, got almost everything right from a technical standpoint - but not friendly, feels foreign, and not liked by anyone who has ever used a Unix, or Windows, or a Mac - which is 99% of the relevant population since about 1985. (Added): Macs also had multiple file streams (“forks”). It doesn’t anymore, for many reasons, but the chief one is interoperability. Less is more, worse is better.
- pasc1878 2y ago
  Re file streams yes classic macOS did have them current macOS does not but it does not need them as you can use Bundles instead which are Unix directories that are treated as a whole by the SDKs.
- SirHumphrey 2y ago
  Which goes to show why *nix won over more feature rich alternatives - the human element. Being feature rich makes the learning curve (usually) much steeper but tends to help in the long-term, while shifting the complexity in to userland means that if I don't need a feature, it needn't concern me. You trade ability for reduction of complexity - getting an operating system that you can learn in months instead of years, which - since the tech industry has been in hipper-growth phase for much of the last 30 years, was more important.
  - EVa5I7bHFq9mnYK 2y ago
    Being free didn't hurt either.
    - pjmlp 2y ago
      Indeed, had AT&T been able to sell UNIX at VMS prices (or whatever else OS from those days) from day one, without access to source code, and history would have taken a different path, regarding UNIX and C adoption.
- fuzztester 2y ago
  >Windows NT was supposed to be a modernized VMS (And legend has VMS+1=WNT, each letter individually…) - and given a face similar to Win 3.1 Same with HAL (1) and IBM, I read somewhere once. (1) The one from https://en.m.wikipedia.org/wiki/2001:_A_Space_Odyssey https://en.m.wikipedia.org/wiki/2001:_A_Space_Odyssey Google hal ibm connection.
- p_ing 2y ago
  > Windows NT was supposed to be a modernized VMS Given Cutler hated UN*X, that only makes sense. NT did a lot of things right at the kernel level. > and most of them are unused or effectively only used by malware (e.g. alternate file streams). "Most of them unused"? ADS was added to NTFS to support Mac OS file sharing over AFP ("Services for Macintosh"). Microsoft makes use of it for downloads from Edge, among other things. It's otherwise not a supremely useful feature and one that you'll silently lose data when moving to another fs/www further degrading it's usefulness.

b112 2y ago

I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust. Am I allowed to sigh here? It's a good thought, but this is humanity we're talking about here. All it requires is some big-project, some big-corp creating some essential ecosystem with lame-language-A, and now it's got traction. And frankly, look at rust and its weird crates. Weird as in "Let's make a super-safe language, then import random stuff from unknowns, unaudited, and just hope it all works out." If rust was really serious about security, only signed crates from validated developers, with code review would be the norm. Oh but wait, that'd be "not easy".

pdimitar 2y ago
What's your suggestion, exactly? Vetting code is extremely expensive in terms of human time and human energy. Sadly it's not only a problem for Rust, it's a problem for every single programming language out there.

bawolff 2y ago

> The history of computing has many examples of products and languages winning out over technically superior alternatives for non-technical reasons. While this is undoubtedly true, i suspect that there are also many cases where people presume the reasons are non-technical but when examined closly turn out to have hidden technical issues.

lII1lIlI11ll 2y ago

> At this point I can't see us going back to the way things were. I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust. Zig seems to be gaining traction. Hard to predict whether it will succeed or slowly fizzle out after the initial excitement phase though.

dralley 2y ago
Is Zig gaining traction? It almost seems like the project has gone radio silent in the past year. It's hard for a language to get traction when it's not even 1.0 and there's not much of a roadmap on how and when they'll get there.

Galanwe 2y ago

> I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust. I don't think safety is a 1 dimensional spectrum (say from 0% to 100%). I view it more as a multidimensional thing, and tradeoffs between these dimensions. Rust invested a lot on _some dimension_ of safety, which is essentially static borrowing and aliasing. And the tradeoffs for this are numerous: Dynamic safety is either much harder in Rust (due to unsafe being vastly more dangerous and hard to get right vs say, a C program), or at the expense of performance (I.e. just Arc<Mutex<>> or copy everything). That also comes at the expense of an immense cognitive burden for the programmer. I see a lot of space for different tradeoffs on different dimensions of safety.

oneshtein 2y ago
> due to unsafe being vastly more dangerous and hard to get right vs say, a C program It's not true. Both C (clang), C++, and Rust use same LLVM compiler, so both have same constraints in the unsafe mode. C/C++ developers just not care.
- cataphract 2y ago
  I don't think this is true. Rust has constraints that C/C++ doesn't have. For instance, it's undefined behavior to create more than one exclusive (mutable) reference to the same object or to create one where a shared reference already exists. This is not necessarily easy to ensure. The aliasing rules in C are much more lax: you only can't have several pointers of different types pointing to the same object, except if one of them is a character pointer (ignoring the restrict keyword, which is opt-in and rarely used).
  - mrcsd 2y ago
    I don't think this is quite the same comparison. In Rust, multiple mutable pointers to the same object can exist at the same time. So, it's similar to C in this way. It is mutable references that must be exclusive.
    - 2y ago

cardanome 2y ago

> At this point I can't see us going back to the way things were. I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust. I see Rust being used in many context where it's safety features aren't really needed or even a hindrance like game dev. Honestly the safety is overstated in importance. The amazing tooling, decent package manager, great error messages, the inclusive community, the type system that took the low hanging fruits from the academic functional programming world, are much more relevant for its success. The problem with Rust is that it made using languages without automatic garbage collection acceptable again and I am not sure if this is good. The borrow checker is a neat solution and might be a good fit for certain niches but automatic garbage collection is just vastly more ergonomic to use. We had Lisp Machines, we need to go back to future.

the__alchemist 2y ago
I'm with you - I like Rust for the overall pros/con balance, in context of with its alternatives. Safety is one thing. The tooling, error messages, type system etc you mention is another. Having mutable references as function parameters is another big one, shared by surprisingly few alternatives.
- vlovich123 2y ago
  Safety and the hype reels you in and the qol hooks and keeps you.
  - lproven 2y ago
    Is that QOI or QOL, and what does it stand for?
    - vlovich123 2y ago
      Quality of life
zozbot234 2y ago
GC implementations are widely available in Rust. You don't have to use garbage collection in Rust, but it doesn't stop you either. You just have to import some custom crate and 'implement' tracing for your own data types.

baranul 2y ago

> The history of computing has many examples of products and languages winning out over technically superior alternatives for non-technical reasons. Unfortunately, the history shows that such technically inferior languages and products winning out are also because of outright market manipulation by their corporate backers, tons of money in ads, or attacks on competitors. The elephant in the room, is to look at what's generating or paying for the hype and marketing behind recent programming languages like Rust and Zig (for example). > I think that the massive groundswell of interest around Rust... A review of the groundswell, around Rust or Zig, is its not attributable to just grassroots or genuine interest, and can significantly be the result of outright astroturfing and artificial brigading. Sadly, many people follow along with the marketing or are bombarded into submission, "must rewrite in X" or "GC all bad and manual all good" foolishness, versus actual use case and legitimate examination of language tradeoffs.