4 ms·

>A library written in C can be used by anyone else. This is because of how much of the unix clone ecosystem has been built around C workflows, and this wasn't

>A library written in C can be used by anyone else. This is because of how much of the unix clone ecosystem has been built around C workflows, and this wasn't true on Windows until linux compatibility was developed on it. >If you're one of the very many people who look down their noses at C and want to get rid of it, do your part. convincing linus and sysadmin greybeards to modernize linux and is no small task, until then we'll all still be just be scripting over archaic C apis "science progresses one funeral at a time"

notacoward 8y ago
> This is because of how much of the unix clone ecosystem has been built around C workflows Absolutely correct. > convincing linus and sysadmin greybeards to modernize linux That's not what I'm suggesting. Anything that's already written in C can and probably should continue to be so. What I'm suggesting is that people who prefer to work in other languages should have an easy way to make their work available beyond their own language community. I'm not talking about interpreted/scripting languages here. I'm talking about compiled/systems languages. Stuff that gets linked together, or that should be able to use some sort of dlopen/FFI back and forth fluidly despite multiple languages being involved. There's some work to be done there, but everyone seems to prefer hiding in their own language bunker instead of reaching out to others.
- pjmlp 8y ago
  There are solutions, but only at platform level. JVM, CLR, COM, UWP, DEX, TIMI, ILE are all possible approaches with various degrees of success and most of them also have C implementations available. It is almost impossible to get some kind universal ABI between OSes and languages without an extra level of indirection.
- slededit 8y ago
  The problem is that other languages necessarily place more restrictions on how their data can be used in order to gain all their nice features. Since you can't control the caller you lose all those guarantees. Because of that it will never be easy to interop across higher level languages. C works well here because its low level enough that it expects few guarantees. Just keep the stack aligned and balanced and it will mostly be happy.
user5994461 8y ago
>>> This is because of how much of the unix clone ecosystem has been built around C workflows, and this wasn't true on Windows until linux compatibility was developed on it. Windows is almost entirely coded in C. The Windows C API is one of the most depended upon API with the largest codebase and the longest documentation in existence.
- pjmlp 8y ago
  Kind of. After Longhorn's failure, they started to focus on COM to be the future of Windows APIs, leading to UWP. And if masochists can implement COM in C, they need to be quite pain resistant for the UWP update. In the meantime, the new C runtime was rewritten in C++, using extern "C" entry points. Windows drivers can be written in C++ since Windows 8, and since then they have been migrating the code to be compilable as the C subset from C++ as well.
  - user5994461 8y ago
    I meant the base Windows API. The MFC and COM were built to abstract it but never really took off. The low level API have been fixed for a very very long time. It doesn't really need to change, opening a file is not different now than a decade ago. It gets no love and no popularity, but it runs the world. Most development is done in higher languages nowadays, typically C#, java or python and all these languages rely on the Windows API to run. They are abstractions of C. P.S. Drivers could already be written in C++ since Windows XP. There were a lot of constraints though because of running in the kernel.
    - pjmlp 8y ago
      > The MFC and COM were built to abstract it but never really took off. MFC was the way to write real Windows applications until .NET came around. Visual Basic was mostly used by not so skilled developers, creating applications that IT department had to take care of, sometimes rewriting them into MFC ones. Delphi and C++ Builder were the only solid alternatives outside Microsoft world, but thanks to the way they drove prices upwards and the identity crisis from Borland, most developers went away to Microsoft products, as the platform is always a safer better for development tools. As I mentioned, since Windows Vista all new API are COM, and UWP, which is the future of the platform is COM as well. UWP is what .NET was supposed to be initially, COM+ Runtime, just that UWP uses .NET metadata instead of COM type libraries and allows for real instances, not only interfaces. COM is a first class type in .NET given its original design, many of the .NET APIs are COM objects underneath, including the whole CLR native APIs. Drivers written in C++ on XP only by adventurous coders with their own compilers or hacks somehow, as Visual C++ only supports kernel mode since Windows 8. > It doesn't really need to change, opening a file is not different now than a decade ago Actually it has changed. OpenFile() has been deprecated and replaced by CreateFile(), which was superseded by CreateFile2(). And on Windows 10, CreateFileFromApp() and CreateFile2FromApp() should be used instead, otherwise the application won't run from the store. And if you want to use any of the goodies from Windows 8 onwards, they are only available as UWP APIs.
matheusmoreira 8y ago
You don't need anybody's permission to do this. Linux has a language-agnostic system call interface. Everything that happens on the computer is accomplished through that interface, and to use it all you need to do is put some values in specific registers and issue a special instruction. This isn't the domain of C; the JIT compiler could have a special system call generation feature. You could get rid of GNU and write your own user space in Lisp if you wanted to.
- walterbell 8y ago
  Or in Go: https://github.com/google/gvisor https://github.com/google/gvisor
pizlonator 8y ago
> This is because of how much of the unix clone ecosystem has been built around C workflows, and this wasn't true on Windows until linux compatibility was developed on it. Because C (and its close relatives like C++) is still the only language suitable for systems development. Just booting any other language on bare metal is enough of an achievement that people loudly brag when they get it to just barely work. If you get it to work in C then nobody is surprised, because C is engineered for systems. Other languages aren't. > convincing linus and sysadmin greybeards to modernize linux and is no small task, until then we'll all still be just be scripting over archaic C apis I'm not sure replacing C with a worse language constitutes "modernizing".

notacoward 8y ago

> This is because of how much of the unix clone ecosystem has been built around C workflows Absolutely correct. > convincing linus and sysadmin greybeards to modernize linux That's not what I'm suggesting. Anything that's already written in C can and probably should continue to be so. What I'm suggesting is that people who prefer to work in other languages should have an easy way to make their work available beyond their own language community. I'm not talking about interpreted/scripting languages here. I'm talking about compiled/systems languages. Stuff that gets linked together, or that should be able to use some sort of dlopen/FFI back and forth fluidly despite multiple languages being involved. There's some work to be done there, but everyone seems to prefer hiding in their own language bunker instead of reaching out to others.

pjmlp 8y ago
There are solutions, but only at platform level. JVM, CLR, COM, UWP, DEX, TIMI, ILE are all possible approaches with various degrees of success and most of them also have C implementations available. It is almost impossible to get some kind universal ABI between OSes and languages without an extra level of indirection.
slededit 8y ago
The problem is that other languages necessarily place more restrictions on how their data can be used in order to gain all their nice features. Since you can't control the caller you lose all those guarantees. Because of that it will never be easy to interop across higher level languages. C works well here because its low level enough that it expects few guarantees. Just keep the stack aligned and balanced and it will mostly be happy.

user5994461 8y ago

>>> This is because of how much of the unix clone ecosystem has been built around C workflows, and this wasn't true on Windows until linux compatibility was developed on it. Windows is almost entirely coded in C. The Windows C API is one of the most depended upon API with the largest codebase and the longest documentation in existence.

pjmlp 8y ago
Kind of. After Longhorn's failure, they started to focus on COM to be the future of Windows APIs, leading to UWP. And if masochists can implement COM in C, they need to be quite pain resistant for the UWP update. In the meantime, the new C runtime was rewritten in C++, using extern "C" entry points. Windows drivers can be written in C++ since Windows 8, and since then they have been migrating the code to be compilable as the C subset from C++ as well.
- user5994461 8y ago
  I meant the base Windows API. The MFC and COM were built to abstract it but never really took off. The low level API have been fixed for a very very long time. It doesn't really need to change, opening a file is not different now than a decade ago. It gets no love and no popularity, but it runs the world. Most development is done in higher languages nowadays, typically C#, java or python and all these languages rely on the Windows API to run. They are abstractions of C. P.S. Drivers could already be written in C++ since Windows XP. There were a lot of constraints though because of running in the kernel.
  - pjmlp 8y ago
    > The MFC and COM were built to abstract it but never really took off. MFC was the way to write real Windows applications until .NET came around. Visual Basic was mostly used by not so skilled developers, creating applications that IT department had to take care of, sometimes rewriting them into MFC ones. Delphi and C++ Builder were the only solid alternatives outside Microsoft world, but thanks to the way they drove prices upwards and the identity crisis from Borland, most developers went away to Microsoft products, as the platform is always a safer better for development tools. As I mentioned, since Windows Vista all new API are COM, and UWP, which is the future of the platform is COM as well. UWP is what .NET was supposed to be initially, COM+ Runtime, just that UWP uses .NET metadata instead of COM type libraries and allows for real instances, not only interfaces. COM is a first class type in .NET given its original design, many of the .NET APIs are COM objects underneath, including the whole CLR native APIs. Drivers written in C++ on XP only by adventurous coders with their own compilers or hacks somehow, as Visual C++ only supports kernel mode since Windows 8. > It doesn't really need to change, opening a file is not different now than a decade ago Actually it has changed. OpenFile() has been deprecated and replaced by CreateFile(), which was superseded by CreateFile2(). And on Windows 10, CreateFileFromApp() and CreateFile2FromApp() should be used instead, otherwise the application won't run from the store. And if you want to use any of the goodies from Windows 8 onwards, they are only available as UWP APIs.

matheusmoreira 8y ago

You don't need anybody's permission to do this. Linux has a language-agnostic system call interface. Everything that happens on the computer is accomplished through that interface, and to use it all you need to do is put some values in specific registers and issue a special instruction. This isn't the domain of C; the JIT compiler could have a special system call generation feature. You could get rid of GNU and write your own user space in Lisp if you wanted to.

walterbell 8y ago
Or in Go: https://github.com/google/gvisor https://github.com/google/gvisor

pizlonator 8y ago

> This is because of how much of the unix clone ecosystem has been built around C workflows, and this wasn't true on Windows until linux compatibility was developed on it. Because C (and its close relatives like C++) is still the only language suitable for systems development. Just booting any other language on bare metal is enough of an achievement that people loudly brag when they get it to just barely work. If you get it to work in C then nobody is surprised, because C is engineered for systems. Other languages aren't. > convincing linus and sysadmin greybeards to modernize linux and is no small task, until then we'll all still be just be scripting over archaic C apis I'm not sure replacing C with a worse language constitutes "modernizing".