5 ms·

A modern, ergonomic language with memory safety without GC is definitely better then anything C had to offer. You can easily write C code in Rust with unsafe; y

A modern, ergonomic language with memory safety without GC is definitely better then anything C had to offer. You can easily write C code in Rust with unsafe; you can't write C code that gives you the guarantees of Rust, no matter what you do.

pjmlp 8y ago
Even in the mid-90's, the only thing C had to offer over something like Turbo Pascal 6.0 on MS-DOS, was portability to other OSes. Feature wise it was just plain inferior, in safety, modularity, compile time, OOP support. Apple was on Object Pascal, then moved into C++. IBM was adopting C++ on their OS/2 tooling, everyone was building C++, Pascal and Basic frameworks on top of Win16, later BeOS also went C++. Then free UNIX clones happened.
- nine_k 8y ago
  Not that with Pascal you'd never had dangling pointers, double-free errors, uninitialized memory access, or smashed stack. Security-wise, Pascal offered vastly more sane strings (counter-prefixed, not null-terminated) and built-in support for access index checking and value range checking (at a constant runtime cost).
- jacksmith21006 8y ago
  Tell you what is most impressive with Turbo Pascal is the entire thing on a floppy was 32k. Do not know how possible. This was less than 1/10 of a 360k floppy.
- nineteen999 8y ago
  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

pjmlp 8y ago

Even in the mid-90's, the only thing C had to offer over something like Turbo Pascal 6.0 on MS-DOS, was portability to other OSes. Feature wise it was just plain inferior, in safety, modularity, compile time, OOP support. Apple was on Object Pascal, then moved into C++. IBM was adopting C++ on their OS/2 tooling, everyone was building C++, Pascal and Basic frameworks on top of Win16, later BeOS also went C++. Then free UNIX clones happened.

nine_k 8y ago
Not that with Pascal you'd never had dangling pointers, double-free errors, uninitialized memory access, or smashed stack. Security-wise, Pascal offered vastly more sane strings (counter-prefixed, not null-terminated) and built-in support for access index checking and value range checking (at a constant runtime cost).
jacksmith21006 8y ago
Tell you what is most impressive with Turbo Pascal is the entire thing on a floppy was 32k. Do not know how possible. This was less than 1/10 of a 360k floppy.
nineteen999 8y ago
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