12 ms·

What I don't understand is: where are all the portable, performant, alternative, user-friendly operating systems written in Pascal, Rust etc. Why are there nea

What I don't understand is: where are all the portable, performant, alternative, user-friendly operating systems written in Pascal, Rust etc. Why are there near zero alternatives to these "swiss-cheese" operating systems after all these years available for the mass-market? Surely backwards compatibility with existing user-space programs can't be the whole issue here. You could feasibly write an operating system with a Rust-based kernel, which allowed "unsafe" C/C++ programs to run in their own protected, virtual memory space, no? All you need to provide at the most basic level is a compatible system call interface. EDIT: to make my point clearer, there are really just two major types of attack surface for C exploits against UNIX (excluding obvious language-agnostic hardware issues eg. Meltdown): a) against the kernel (written in C) b) against userspace (the majority of which is written in C) Which class of exploits are we hoping to eliminate here, (a) or (b)? If the answer is the latter, then sure, write a replacement for libc, and the whole ecosystem that sits on top of that. When that is done, you still have a kernel written in C that is vulnerable to attack. If it is the former, then rewrite the kernel in Rust or whatever "safe" language you like. Provide an optional backwards compatible syscall interface for "legacy C/C++" or "unmanaged" code, and let users enable it at their own risk. This would provide a path forward for systems comprised of safe kernel and safe userspace, while allowing older code to be run where needed. I am eternally curious, when the UNIX design is approaching 60 years old, why the latter has not been done yet.

pjmlp 8y ago
It has been done, you just weren't paying attention. Burroughs B5500 was written in ESPOL, an Algol dialect for systems programming, later improved as NEWP. This is still sold by Unisys as ClearPath MCP mainframes. Xerox PARC initially used BCPL, but then created Mesa, used to develop their Xerox Star workstations, which then evolved into Mesa/Cedar. The Solo operating system was written in Concurrent Pascal for the PDP 11/45. IBM did all their RISC research using PL/8, a safe systems programming language based on PL/I with an architecture that you would find nowadays on LLVM. They only adopted C for RISC when they decided to bet on UNIX workstations as means to sell their RISC research. UCSD Pascal OS System was a mix of interpreted and AOT compiled environment, later adopted by Western Digitial for some of its firmware. Apple designed Object Pascal with input from Wirth, implementing Lisa and Mac OS on a mix of Assembly and Object Pascal, later switching to C++ as means to make the platform more appealing to other developers. None of IBM mainframes were developed in C, rather a mix of Assembly, PL/S, PL/8. They only started to move into C and C++ as POSIX compatibility on those mainframes became a selling point as well. There are plenty of other examples available. Backwards compatibility, lack of actual research on most companies with eyes only on short term profits, UNIX clones available for free, managers not willing to bet on the team even if it is an up-hill battle, there are plenty of reasons why we aren't still there, most of them not technical. There are alternatives to UNIX's design, hence why POSIX has been loosing relevance all these years. On Apple platforms, Swift is the future even if it takes a couple of years to reach there, that is clearly the way Apple sees it. "Swift is a successor to both the C and Objective-C languages." -- https://developer.apple.com/swift/ https://developer.apple.com/swift/ Even on NeXTSTEP, drivers were written in Objective-C, and UNIX compatibility was a way to embrace UNIX software then extend it with Foundation code. On Google platforms, the fact that the underlying kernel is an UNIX clone is irrelevant, the Web platform, Android Runtime or the NDK APIs don't expose any of it on the official APIs. On Windows, C is considered done and the future for systems programing on the platform is a mix of C++ and .NET Native. Many embedded vendors do sell Basic, Pascal, Oberon, Java and Ada bare metal compilers. It is slowly getting there, we just need a couple of developer generations to get it back on track.
- nineteen999 8y ago
  I'm well aware of many of the above systems. You may have missed the part where I specified "mass-market" though, right at the start. Perhaps you weren't paying attention. UNIX itself predates POSIX by a large margin and early versions were written in assembly, not C. I'm talking about the bulk of modern commodity desktop and web application development, which is really the lion's share of modern software development. This overwhelmingly occurs on and for workstations running Linux/Windows/BSD, all derived from C, with large parts of the userland still written in C code, or in languages which were bootstrapped from C, depend on C, or depend on a thin language-specific wrappers around existing C libraries. Many if not most of the popular languages supported by LLVM have a frontend written in C/C++. Sure these languages can become self-hosted, eg. Rust (albeit dependent on LLVM, written in C/C++), or Golang. But I posit that until large parts of these systems (kernel _and_ userland) and the extensive collection of C libraries which are used for application development today are rewritten or replaced, you will not see the huge paradigm shift in commodity application development you are describing. I think it's going to take longer than that. I am not as optimistic as you. Stakeholders, programmers and product managers alike tend to favour the path of least resistance. C is the lingua franca of these existing systems, and forms the common basis around which multiple higher-level languages currently wrap and leverage. Which new common denominator is going to take its place? LLVM bytecode? Are we going to rewrite libz/libpng in each new language-of-the-week instead? This is even before getting into embedded, where C is still king, C++ is really only starting to become more popular over the last 10 years or so, and Rust is barely a blip on the radar. Linux's popularity growth in this area is phenomenal, unmatched by any other as well.
  - pjmlp 8y ago
    On IBM and Unisys mainframes the common denominator is the "language environment", the intermediate format that has allowed them to evolve all these years since the 60's. On Windows the common denominator are COM and .NET, with COM upgraded to UWP on recent versions. On Android the common denominator is Dalvik bytecode. On macOS/iOS the common denominator could be indeed LLVM bitcode, depending on how much Apple would like to deviate from upstream to make their own toolchain actually hardware independent. Natural Linux's popularity has sky rocketed, UNIX's path to success and its clones, has always been free beer, which tastes even better when it comes with source code. I am optimistic, but I am also aware it won't happen on my lifetime, changing mentalities requires changing generations, one person at a time.

pjmlp 8y ago

It has been done, you just weren't paying attention. Burroughs B5500 was written in ESPOL, an Algol dialect for systems programming, later improved as NEWP. This is still sold by Unisys as ClearPath MCP mainframes. Xerox PARC initially used BCPL, but then created Mesa, used to develop their Xerox Star workstations, which then evolved into Mesa/Cedar. The Solo operating system was written in Concurrent Pascal for the PDP 11/45. IBM did all their RISC research using PL/8, a safe systems programming language based on PL/I with an architecture that you would find nowadays on LLVM. They only adopted C for RISC when they decided to bet on UNIX workstations as means to sell their RISC research. UCSD Pascal OS System was a mix of interpreted and AOT compiled environment, later adopted by Western Digitial for some of its firmware. Apple designed Object Pascal with input from Wirth, implementing Lisa and Mac OS on a mix of Assembly and Object Pascal, later switching to C++ as means to make the platform more appealing to other developers. None of IBM mainframes were developed in C, rather a mix of Assembly, PL/S, PL/8. They only started to move into C and C++ as POSIX compatibility on those mainframes became a selling point as well. There are plenty of other examples available. Backwards compatibility, lack of actual research on most companies with eyes only on short term profits, UNIX clones available for free, managers not willing to bet on the team even if it is an up-hill battle, there are plenty of reasons why we aren't still there, most of them not technical. There are alternatives to UNIX's design, hence why POSIX has been loosing relevance all these years. On Apple platforms, Swift is the future even if it takes a couple of years to reach there, that is clearly the way Apple sees it. "Swift is a successor to both the C and Objective-C languages." -- https://developer.apple.com/swift/ https://developer.apple.com/swift/ Even on NeXTSTEP, drivers were written in Objective-C, and UNIX compatibility was a way to embrace UNIX software then extend it with Foundation code. On Google platforms, the fact that the underlying kernel is an UNIX clone is irrelevant, the Web platform, Android Runtime or the NDK APIs don't expose any of it on the official APIs. On Windows, C is considered done and the future for systems programing on the platform is a mix of C++ and .NET Native. Many embedded vendors do sell Basic, Pascal, Oberon, Java and Ada bare metal compilers. It is slowly getting there, we just need a couple of developer generations to get it back on track.

nineteen999 8y ago
I'm well aware of many of the above systems. You may have missed the part where I specified "mass-market" though, right at the start. Perhaps you weren't paying attention. UNIX itself predates POSIX by a large margin and early versions were written in assembly, not C. I'm talking about the bulk of modern commodity desktop and web application development, which is really the lion's share of modern software development. This overwhelmingly occurs on and for workstations running Linux/Windows/BSD, all derived from C, with large parts of the userland still written in C code, or in languages which were bootstrapped from C, depend on C, or depend on a thin language-specific wrappers around existing C libraries. Many if not most of the popular languages supported by LLVM have a frontend written in C/C++. Sure these languages can become self-hosted, eg. Rust (albeit dependent on LLVM, written in C/C++), or Golang. But I posit that until large parts of these systems (kernel _and_ userland) and the extensive collection of C libraries which are used for application development today are rewritten or replaced, you will not see the huge paradigm shift in commodity application development you are describing. I think it's going to take longer than that. I am not as optimistic as you. Stakeholders, programmers and product managers alike tend to favour the path of least resistance. C is the lingua franca of these existing systems, and forms the common basis around which multiple higher-level languages currently wrap and leverage. Which new common denominator is going to take its place? LLVM bytecode? Are we going to rewrite libz/libpng in each new language-of-the-week instead? This is even before getting into embedded, where C is still king, C++ is really only starting to become more popular over the last 10 years or so, and Rust is barely a blip on the radar. Linux's popularity growth in this area is phenomenal, unmatched by any other as well.
- pjmlp 8y ago
  On IBM and Unisys mainframes the common denominator is the "language environment", the intermediate format that has allowed them to evolve all these years since the 60's. On Windows the common denominator are COM and .NET, with COM upgraded to UWP on recent versions. On Android the common denominator is Dalvik bytecode. On macOS/iOS the common denominator could be indeed LLVM bitcode, depending on how much Apple would like to deviate from upstream to make their own toolchain actually hardware independent. Natural Linux's popularity has sky rocketed, UNIX's path to success and its clones, has always been free beer, which tastes even better when it comes with source code. I am optimistic, but I am also aware it won't happen on my lifetime, changing mentalities requires changing generations, one person at a time.