3 ms·

I don't disagree, I see an expectation on the part of driver/API providers that you can write (probably in C) and adapter layer that can talk "glorious language

I don't disagree, I see an expectation on the part of driver/API providers that you can write (probably in C) and adapter layer that can talk "glorious language" on the input, and then do the naughty bits and talk to the C API on the output. My position is that this is less of a burden than writing something that goes from the "glorious language" into machine code. Understanding why that is less of a burden is gained by writing a compiler where you go right from "expressing what you want" to "machine code that does that".

dzaima 5y ago
I mean, a C interface is better than a machine code interface. The problem with that is that, unless you include a C compiler (or at least a thing that understands the 176 C ABIs) with your language, you can't use it. (not that machine code would be better at that, but I'm sure that if people actually intentionally attempted to make a global cross-platform ABI, they'd easily make something much better than C)
- Koshkin 5y ago
  > a C interface is better than a machine code interface The last thing I want when I write code in assembly is to have to call a C library just to invoke a system function.
  - dzaima 5y ago
    You'd obviously prefer calling into things made in your own language than some other. But, from any other language you'd much prefer a C interface over having to explicitly describe which registers & stack slots to put things in and read from.
    - mcronce 5y ago
      I did this once trying to mitigate Go's FFI performance cost. It wasn't great but it wasn't awful either. If I had to do it again I'd generate the assembly trampolines.
      - robocat 5y ago
        > Go's FFI performance cost https://news.ycombinator.com/item?id=17165179 https://news.ycombinator.com/item?id=17165179
        mcronce 5y ago
        There are a couple solid summaries in that thread based on my experience going through that exercise - thanks for the link In case anybody wants to go down the rabbit hole of shit you should definitely not use in production (but we did anyway), this was my starting point: https://words.filippo.io/rustgo/ https://words.filippo.io/rustgo/ I did not, however, `no_std` or avoid heap allocation on the Rust side. Everything worked great, including running a multithreaded tokio runtime. Still do not recommend in prod ;)
lmm 5y ago
> My position is that this is less of a burden than writing something that goes from the "glorious language" into machine code. I disagree. Machine code has a small stable surface area. Compiling to a bootable image for a single-tasking machine is easier than compiling to a well-behaved userspace unix program that operates the way users expect.
aidenn0 5y ago
> My position is that this is less of a burden than writing something that goes from the "glorious language" into machine code. It's only less of a burden if you're guaranteed to have a C compiler hanging around any time the C ABI breaks. If you aren't guaranteed to have a C compiler hanging around any time the C ABI breaks, then you are probably just as well off generating C-ABI compatible machine code from an ABI description written in "glorious language" and updating it when the C ABI breaks. Non self-hosting languages distributed as source code can just lean on the C compiler for everything. It's also quite feasible to target Linux without worrying about the C ABI, as the Linux system call interface is famously stable, but that is not true of any BSD.

dzaima 5y ago

I mean, a C interface is better than a machine code interface. The problem with that is that, unless you include a C compiler (or at least a thing that understands the 176 C ABIs) with your language, you can't use it. (not that machine code would be better at that, but I'm sure that if people actually intentionally attempted to make a global cross-platform ABI, they'd easily make something much better than C)

Koshkin 5y ago
> a C interface is better than a machine code interface The last thing I want when I write code in assembly is to have to call a C library just to invoke a system function.
- dzaima 5y ago
  You'd obviously prefer calling into things made in your own language than some other. But, from any other language you'd much prefer a C interface over having to explicitly describe which registers & stack slots to put things in and read from.
  - mcronce 5y ago
    I did this once trying to mitigate Go's FFI performance cost. It wasn't great but it wasn't awful either. If I had to do it again I'd generate the assembly trampolines.
    - robocat 5y ago
      > Go's FFI performance cost https://news.ycombinator.com/item?id=17165179 https://news.ycombinator.com/item?id=17165179
      - mcronce 5y ago
        There are a couple solid summaries in that thread based on my experience going through that exercise - thanks for the link In case anybody wants to go down the rabbit hole of shit you should definitely not use in production (but we did anyway), this was my starting point: https://words.filippo.io/rustgo/ https://words.filippo.io/rustgo/ I did not, however, `no_std` or avoid heap allocation on the Rust side. Everything worked great, including running a multithreaded tokio runtime. Still do not recommend in prod ;)

lmm 5y ago

> My position is that this is less of a burden than writing something that goes from the "glorious language" into machine code. I disagree. Machine code has a small stable surface area. Compiling to a bootable image for a single-tasking machine is easier than compiling to a well-behaved userspace unix program that operates the way users expect.

aidenn0 5y ago

> My position is that this is less of a burden than writing something that goes from the "glorious language" into machine code. It's only less of a burden if you're guaranteed to have a C compiler hanging around any time the C ABI breaks. If you aren't guaranteed to have a C compiler hanging around any time the C ABI breaks, then you are probably just as well off generating C-ABI compatible machine code from an ABI description written in "glorious language" and updating it when the C ABI breaks. Non self-hosting languages distributed as source code can just lean on the C compiler for everything. It's also quite feasible to target Linux without worrying about the C ABI, as the Linux system call interface is famously stable, but that is not true of any BSD.