2 ms·

Most languages don't have stable native ABIs.

olliej 5y ago
What? Define “most” here, because every actual system language has a stable ABI, otherwise they can’t be used for system libraries. If you include toy languages, you might get there. Even languages like Go and Rust recognize that at API boundaries you need a stable and defined ABI.
- fulafel 5y ago
  Most of today's apps languages, for example. But also Go documents that there's only a internal ABI that's not stable across versions, so it doesn't serve for most ABIy things, like system libraries. Rust seems to be similar. I wonder what the situation is like in GPU language land... These languages still allow you to consume and provide C compatible ABIs explicitly but this does not interfere with data optimizations for native data.
  - olliej 5y ago
    Again, provide an actual example. Many “modern” languages don’t ship in compiled form so the important part is mostly just API. Go and rust can’t be used for system libraries: you have to create C interface. This means that if you have two libraries, both written in rust then they have to communicate through a C layer. The alternative (what rust does) is to have every application contain a complete copy of every library it uses, which is horrific for performance.
    - deleted 5y ago
      [deleted]
    - fulafel 5y ago
      Modern applications languages: Clojure/ClojureScript, Java, F#, C#, Visual Basic, Python, Javascript, TypeScript, PHP, Swift, Dart, Go (included even if it's labeled as a systems language). Of those only Swift does stable ABIs. Yep, not shipping (native) compiled code is usually how you end up with no ABIs. But these these languages and runtimes still don't really support optimizations of data structures very well, I think it's largely because they weren't specified and implementerd to do it from the start and now there are all kinds of ingrained things about the semantics and estsabilished implementations and user expectations that get in the way of doing big things like feedback based rewriting of data layouts.

What? Define “most” here, because every actual system language has a stable ABI, otherwise they can’t be used for system libraries. If you include toy languages, you might get there. Even languages like Go and Rust recognize that at API boundaries you need a stable and defined ABI.

fulafel 5y ago
Most of today's apps languages, for example. But also Go documents that there's only a internal ABI that's not stable across versions, so it doesn't serve for most ABIy things, like system libraries. Rust seems to be similar. I wonder what the situation is like in GPU language land... These languages still allow you to consume and provide C compatible ABIs explicitly but this does not interfere with data optimizations for native data.
- olliej 5y ago
  Again, provide an actual example. Many “modern” languages don’t ship in compiled form so the important part is mostly just API. Go and rust can’t be used for system libraries: you have to create C interface. This means that if you have two libraries, both written in rust then they have to communicate through a C layer. The alternative (what rust does) is to have every application contain a complete copy of every library it uses, which is horrific for performance.
  - deleted 5y ago
    [deleted]
  - fulafel 5y ago
    Modern applications languages: Clojure/ClojureScript, Java, F#, C#, Visual Basic, Python, Javascript, TypeScript, PHP, Swift, Dart, Go (included even if it's labeled as a systems language). Of those only Swift does stable ABIs. Yep, not shipping (native) compiled code is usually how you end up with no ABIs. But these these languages and runtimes still don't really support optimizations of data structures very well, I think it's largely because they weren't specified and implementerd to do it from the start and now there are all kinds of ingrained things about the semantics and estsabilished implementations and user expectations that get in the way of doing big things like feedback based rewriting of data layouts.