4 ms·

In my opinion it's not the language, it's the libraries. Lets take Java vs Fortran and look at the language basics. They pretty much have the same basics: assi

In my opinion it's not the language, it's the libraries. Lets take Java vs Fortran and look at the language basics. They pretty much have the same basics: assignments, control structures, function calls. What makes Java rock isn't the language it's all the library code that comes with it. People are always saying "Look at me I can write a web server in six lines of code." No, you can call a web server library that someone wrote for you in six lines of code. Aftbit (some place in this thread) has a good point, some languages are better with some subject matters. I'd like to also posit that some languages have better libraries written for a subject matter which makes it appear they are better for that subject. We've seen lots of people port libraries to a different language to help them. While I do agree that some languages give you a boost up because the compiler is doing some heavy lifting in the background, it's the huge collections of libraries that we can call that lets us stand on the shoulders of giants.

derefr 10y ago
True; it's a crying shame, though. It's 2016: why are libraries still limited to the language-runtime they were written for? Why must there be more than one library ecosystem? Why can't I import Javascript libraries from Ruby, Python libraries from Java, Erlang libraries from Haskell, Go libraries from Rust? Why can't they all just be "libraries", fullstop? (Right now, we have to explicitly embed one runtime into another, creating programmer's turducken, if we want anything close. This, though, is an artifact of the way we think about efficiency as requiring address-space cohabitation. And while it's easy to set up a runtime-heterogenous melange using IPC, the default for that is inefficient serialized streams on sockets. Where's my zeromq-like zero-copy message-passing IPC as a batteries-included part of every runtime? Where's my binary wire-type-encoding standard aimed at producing "toll-free-bridged" native types in multiple runtimes? Where's my "managed" OS with malloc-time kernel-side type-tagged memory-buffers[1] that all runtimes for that OS support loading? Where are my multi-runtime application servers with jail/lxc-like application domains to isolate mutually-untrustworthy clients?) [1] Speaking of, whatever happened to capability-based operating systems? Hardware support for capabilities would basically let us get rid of the "process" abstraction altogether, and just have a big OS-wide heap with various units of concurrent execution holding capabilities on various memory-objects.
- mwcampbell 10y ago
  capnproto seems to get the closest to what you want.

derefr 10y ago

True; it's a crying shame, though. It's 2016: why are libraries still limited to the language-runtime they were written for? Why must there be more than one library ecosystem? Why can't I import Javascript libraries from Ruby, Python libraries from Java, Erlang libraries from Haskell, Go libraries from Rust? Why can't they all just be "libraries", fullstop? (Right now, we have to explicitly embed one runtime into another, creating programmer's turducken, if we want anything close. This, though, is an artifact of the way we think about efficiency as requiring address-space cohabitation. And while it's easy to set up a runtime-heterogenous melange using IPC, the default for that is inefficient serialized streams on sockets. Where's my zeromq-like zero-copy message-passing IPC as a batteries-included part of every runtime? Where's my binary wire-type-encoding standard aimed at producing "toll-free-bridged" native types in multiple runtimes? Where's my "managed" OS with malloc-time kernel-side type-tagged memory-buffers[1] that all runtimes for that OS support loading? Where are my multi-runtime application servers with jail/lxc-like application domains to isolate mutually-untrustworthy clients?) [1] Speaking of, whatever happened to capability-based operating systems? Hardware support for capabilities would basically let us get rid of the "process" abstraction altogether, and just have a big OS-wide heap with various units of concurrent execution holding capabilities on various memory-objects.

mwcampbell 10y ago
capnproto seems to get the closest to what you want.