6 ms·

To replace C, one must create a language which, first and foremost, can target shared libraries, because that's how most of systems software operates on virtual

To replace C, one must create a language which, first and foremost, can target shared libraries, because that's how most of systems software operates on virtually all current day's operating systems. This is by far the #1 requirement: extensions to all VMs and scripting languages are shared libraries. Plugins for various servers are shared libraries, heck pretty much everything which is not a web app is a shared library, either on windows or linux. In my life as a C++ developer (about 7 years) I have never, even once, worked on an executable. All my code, at all companies where I worked, always ran inside of either a DLL or a so-file loaded by some hosting process. In fact, I believe that so-files must have been the default compilation target for both Go and D. So millions of Ruby/Perl/Python/Java/<anything goes> programmers could have used those languages for performance-critical or OS-dependent code in their programs, after all that's what "systems languages" are for.

leon_ 15y ago
I know that shared libs are prominent and a better support for them would probably help Go's popularity. (Though the idea behind shared libs is somewhat flawed.) But it rocks to deploy a Go app by just sending the binary to a dozen of servers and never have to worry about any dependencies on shared libraries.
- mattgreenrocks 15y ago
  Savvy Win32 devs used static linking whenever they could to minimize deployment hassles way back when. :)
- deleted 15y ago
  [deleted]
masklinn 15y ago
> I believe that so-files must have been should, no? Considering you can not — as far as I know — compile to shared libraries in Go.
- delinka 15y ago
  You can compile your own packages to statically-linkable libraries. Code sharing is what libraries are all about. Now, if you want dynamically-loadable libraries (written in Go), Go's tools do not support that. (You can, however, link to dynamic libs written in C and that linking happens at runtime.) Static linking is precisely what prevents dependency hell. I'm somewhat hijacking the discussion with this, but with storage getting cheaper, why do we need dynamic linking anymore?
  - stonemetal 15y ago
    Plugins that don't require developer tools to relink your executable.
  - ajross 15y ago
    And when you have a security bug in your static library (let's call it "library Z", just for kicks), what do you do? Is it enough to just let the software know? What about big vendors, whose products might have 42 different copies of Z kicking around in the source base. What if they miss some? Wouldn't an architecture that allows the distribution to define and replace Z on its own be valuable?
    - roc 15y ago
      > "Wouldn't an architecture that allows the distribution to define and replace Z on its own be valuable?" In theory, sure. But how many more years of practice do we need before we accept that it doesn't work that way in reality? That any change in Z is as likely to break apps that use it, as save them some hassle?
      - ajross 15y ago
        Clearly I was too subtle. It, uh, wasn't actually a hypothetical: zlib had known exploits that bit Microsoft and others for years because they had cut and pasted the library into a zillion places. Linux distros just updated. There's no theory at work here. Static linkage of common components is a security vulnerability.
jerf 15y ago
It has become increasingly clear to me that C's influence on the systems landscape is even stronger than it would initially appear. Our ability to move beyond what we have now is not merely hampered by the fact that we have to create an entire systems infrastructure, it is hampered by the fact that we always get sucked into having to support C shared libraries in addition to that, and in general that requires certain things to be true of your language, which pulls you into the C local optima. And now you've failed to write a systems language that has moved fundamentally beyond C. In short, to be able to run a C library means that you language must hand over total control to that C library, who may then dance all over memory, if it chooses. You can't build a system that enforces any further constraints. And you don't have to be an "academic weirdo" language anymore to want to be able to enforce constraints; even something like Go has a significant runtime that you need to work with properly to get the benefits of go, and a C library simply expects to own its thread for as long as it wants, do whatever it wants to allocate memory, use whatever resources it wants, not be scheduled in any way by anything other than the OS, and just this immense laundry list of requirements that all looked OK 30 years ago, but it's increasingly clear that to get to the next step of systems design, some of those are going to have to be modified. And C is not the language that will allow this. The only language I know that manages to have radically different semantics that C at the deepest levels, yet can still talk to C libraries without (much) compromise of those semantics, is Haskell. Somehow we've got to escape from C-type linking dictating requirements to the deepest levels of the semantics of the new language, or we're not going to escape from the local optima we are in right now.
- haberman 15y ago
  Why are so many people intent on taking C away from us? The fact that you can run everything from Erlang to Python to Lisp to a JVM on the same machine and under the same OS is thanks to C, not in spite of it! C exposes the machine at a low level, which means that you can innovate in the language/VM space without having to beg the runtime gatekeepers to please implement your new experimental semantic. Anyone can generate machine code that will run directly on the hardware -- I recently wrote a JIT that parses Protocol Buffers 2x the speed of any existing parser. Don't take away from the the ability to do this! Higher level VMs like the JVM can impose further constraints -- this is already possible today. But those VMs can compete for popularity in user-space without imposing limitations on the kinds of VMs you can write directly on the hardware.
pcwalton 15y ago
This is, indeed, why Rust originally compiled only to shared libraries (that also worked as executables). We ended up distinguishing shared libraries from executables for performance and OS integration reasons, but shared libraries are still key to the design.
TheCondor 15y ago
Is there something fundamental in Go's symmantics that prevents dynamic linking? Or is this just a tooling issue? Personally, I think I might avoid a language that defined how the end product could be packaged, that just seems outside the range of what a good language should focus on. Go definitely bucks the trend in modern web age language development,for starters it generates raw binaries. That alone puts it in a different category than just about everything else of significance that has been developed over the last decade. Rather than coming out with a full auto-completing IDE from the start or a plugin for netbeans or eclipse, they've got a lightning fast object code compiler. The natural evolution of these things is to get raw binaries working, get the langauge pretty much stablizied, then add some default libraries and tools to make shared libraries and get dynamic linking and PIC code type stuff working and the language shouldn't have to actually change for that to happen, you just change the tools and create different ways to compile stuff. I'd expect shared libs to come along.

leon_ 15y ago

I know that shared libs are prominent and a better support for them would probably help Go's popularity. (Though the idea behind shared libs is somewhat flawed.) But it rocks to deploy a Go app by just sending the binary to a dozen of servers and never have to worry about any dependencies on shared libraries.

mattgreenrocks 15y ago
Savvy Win32 devs used static linking whenever they could to minimize deployment hassles way back when. :)
deleted 15y ago
[deleted]

masklinn 15y ago

> I believe that so-files must have been should, no? Considering you can not — as far as I know — compile to shared libraries in Go.

delinka 15y ago
You can compile your own packages to statically-linkable libraries. Code sharing is what libraries are all about. Now, if you want dynamically-loadable libraries (written in Go), Go's tools do not support that. (You can, however, link to dynamic libs written in C and that linking happens at runtime.) Static linking is precisely what prevents dependency hell. I'm somewhat hijacking the discussion with this, but with storage getting cheaper, why do we need dynamic linking anymore?
- stonemetal 15y ago
  Plugins that don't require developer tools to relink your executable.
- ajross 15y ago
  And when you have a security bug in your static library (let's call it "library Z", just for kicks), what do you do? Is it enough to just let the software know? What about big vendors, whose products might have 42 different copies of Z kicking around in the source base. What if they miss some? Wouldn't an architecture that allows the distribution to define and replace Z on its own be valuable?
  - roc 15y ago
    > "Wouldn't an architecture that allows the distribution to define and replace Z on its own be valuable?" In theory, sure. But how many more years of practice do we need before we accept that it doesn't work that way in reality? That any change in Z is as likely to break apps that use it, as save them some hassle?
    - ajross 15y ago
      Clearly I was too subtle. It, uh, wasn't actually a hypothetical: zlib had known exploits that bit Microsoft and others for years because they had cut and pasted the library into a zillion places. Linux distros just updated. There's no theory at work here. Static linkage of common components is a security vulnerability.

jerf 15y ago

It has become increasingly clear to me that C's influence on the systems landscape is even stronger than it would initially appear. Our ability to move beyond what we have now is not merely hampered by the fact that we have to create an entire systems infrastructure, it is hampered by the fact that we always get sucked into having to support C shared libraries in addition to that, and in general that requires certain things to be true of your language, which pulls you into the C local optima. And now you've failed to write a systems language that has moved fundamentally beyond C. In short, to be able to run a C library means that you language must hand over total control to that C library, who may then dance all over memory, if it chooses. You can't build a system that enforces any further constraints. And you don't have to be an "academic weirdo" language anymore to want to be able to enforce constraints; even something like Go has a significant runtime that you need to work with properly to get the benefits of go, and a C library simply expects to own its thread for as long as it wants, do whatever it wants to allocate memory, use whatever resources it wants, not be scheduled in any way by anything other than the OS, and just this immense laundry list of requirements that all looked OK 30 years ago, but it's increasingly clear that to get to the next step of systems design, some of those are going to have to be modified. And C is not the language that will allow this. The only language I know that manages to have radically different semantics that C at the deepest levels, yet can still talk to C libraries without (much) compromise of those semantics, is Haskell. Somehow we've got to escape from C-type linking dictating requirements to the deepest levels of the semantics of the new language, or we're not going to escape from the local optima we are in right now.

haberman 15y ago
Why are so many people intent on taking C away from us? The fact that you can run everything from Erlang to Python to Lisp to a JVM on the same machine and under the same OS is thanks to C, not in spite of it! C exposes the machine at a low level, which means that you can innovate in the language/VM space without having to beg the runtime gatekeepers to please implement your new experimental semantic. Anyone can generate machine code that will run directly on the hardware -- I recently wrote a JIT that parses Protocol Buffers 2x the speed of any existing parser. Don't take away from the the ability to do this! Higher level VMs like the JVM can impose further constraints -- this is already possible today. But those VMs can compete for popularity in user-space without imposing limitations on the kinds of VMs you can write directly on the hardware.

pcwalton 15y ago

This is, indeed, why Rust originally compiled only to shared libraries (that also worked as executables). We ended up distinguishing shared libraries from executables for performance and OS integration reasons, but shared libraries are still key to the design.

TheCondor 15y ago

Is there something fundamental in Go's symmantics that prevents dynamic linking? Or is this just a tooling issue? Personally, I think I might avoid a language that defined how the end product could be packaged, that just seems outside the range of what a good language should focus on. Go definitely bucks the trend in modern web age language development,for starters it generates raw binaries. That alone puts it in a different category than just about everything else of significance that has been developed over the last decade. Rather than coming out with a full auto-completing IDE from the start or a plugin for netbeans or eclipse, they've got a lightning fast object code compiler. The natural evolution of these things is to get raw binaries working, get the langauge pretty much stablizied, then add some default libraries and tools to make shared libraries and get dynamic linking and PIC code type stuff working and the language shouldn't have to actually change for that to happen, you just change the tools and create different ways to compile stuff. I'd expect shared libs to come along.