5 ms·

Let's say you write the best image decoder library for the next great image format, and everyone wants it on every device that is connected to the internet. Wr

Let's say you write the best image decoder library for the next great image format, and everyone wants it on every device that is connected to the internet. Writing it in haskell would mean that only haskell users, or people willing to link in a large runtime, could use it. So, you write it in C or Rust, so anyone can link it in and not care what it was written in. Maybe also write a native Java version, because that can already run on billions of devices.

galaxyLogic 8y ago
Makes a lot of sense. Haskell comes with baggage and has an impedance-mismatch with other commonly used languages. Similar reasons must have been to blame for the demise of Smalltalk. The best solution of its time many believe, but not easy to integrate with other languages and other ways of doing things. Also let me add it was difficult to create small Smalltalk programs that wouldn't require most of the base-library to be tagged along. Then you couldn't import it to another environment where the base libraries were somewhat different.
vapourismo 8y ago
GHC can produce native libraries just like C or Rust.
- reikonomusha 8y ago
  But you carry around a runtime with managed objects that can’t be freely traded across the boundary to C libraries.
  - vapourismo 8y ago
    Certainly it isn't the most attractive solution - still it is possible and works well. When it comes to moving things across FFI barrier, that is also very possible as there are all kinds of types (including stable pointers) in the Foreign.* modules that map onto C types.
- wtetzner 8y ago
  But you have to link in the runtime, including the garbage collector.
  - vapourismo 8y ago
    I don't see how that is a big problem.
    - jeffdavis 8y ago
      It's a larger footprint, possibly drains battery when you don't expect, may mess with signal handlers and other global state. And it does not really scale to many libraries. What happens when eveyone thinks theor language is best and wants to link in a big runtime? You need 30 different runtimes for 30 libraries? Ouch. And if not careful about versioning, you could end up with symbol conflicts, etc. All these problems can be overcome, but are just not acceptable if you want to be a ubiquitous library like libjpeg. Needs to be super simple from a runtime perspective.
      - wtetzner 8y ago
        Not to mention trying to get different garbage collectors to play nicely together.
WalterBright 8y ago
D can also link to only the C runtime library.

galaxyLogic 8y ago

Makes a lot of sense. Haskell comes with baggage and has an impedance-mismatch with other commonly used languages. Similar reasons must have been to blame for the demise of Smalltalk. The best solution of its time many believe, but not easy to integrate with other languages and other ways of doing things. Also let me add it was difficult to create small Smalltalk programs that wouldn't require most of the base-library to be tagged along. Then you couldn't import it to another environment where the base libraries were somewhat different.

vapourismo 8y ago

GHC can produce native libraries just like C or Rust.

reikonomusha 8y ago
But you carry around a runtime with managed objects that can’t be freely traded across the boundary to C libraries.
- vapourismo 8y ago
  Certainly it isn't the most attractive solution - still it is possible and works well. When it comes to moving things across FFI barrier, that is also very possible as there are all kinds of types (including stable pointers) in the Foreign.* modules that map onto C types.
wtetzner 8y ago
But you have to link in the runtime, including the garbage collector.
- vapourismo 8y ago
  I don't see how that is a big problem.
  - jeffdavis 8y ago
    It's a larger footprint, possibly drains battery when you don't expect, may mess with signal handlers and other global state. And it does not really scale to many libraries. What happens when eveyone thinks theor language is best and wants to link in a big runtime? You need 30 different runtimes for 30 libraries? Ouch. And if not careful about versioning, you could end up with symbol conflicts, etc. All these problems can be overcome, but are just not acceptable if you want to be a ubiquitous library like libjpeg. Needs to be super simple from a runtime perspective.
    - wtetzner 8y ago
      Not to mention trying to get different garbage collectors to play nicely together.

WalterBright 8y ago

D can also link to only the C runtime library.