6 ms·

Portability of software is a language problem. Some languages make it extremely easy. Others, like C and Go, make it difficult to be correct across all platform

by nynx 5y ago

Portability of software is a language problem. Some languages make it extremely easy. Others, like C and Go, make it difficult to be correct across all platforms.

rectang 5y ago
C and Go got nothing on Swift. Or .NET which is tantalizingly partially portable.
junon 5y ago
> Portability of software is a language problem I think this is one of those statements that sounds good at face value but doesn't stand up to scrutiny.
Hooray_Darakian 5y ago
Hard disagree there. Trying to write cross distro cli tools can get really hairy really fast when you need to deal with distro inconsistencies in file locations, default configs/permissions, systemd vs not (maybe that one is past now), etc...
omnicognate 5y ago
I wrote an iOS app. I ported it to Android. The only part that didn't need to be rewritten from the ground up (and it worked completely unmodified) was the part written in C. If you have the same APIs available (OpenGL in this case) C is the most portable language there is. Which proves it's not a language issue, it's a platform issue. In fact the owners of the platforms care so little about (indeed actively oppose) compatibility between them that increasingly they make their higher-level APIs only available to a single language so you can't even share the parts of your code that aren't dependent on their APIs. Unless of course you drop into the one language that works everywhere and which they have no choice but to support: C (or something else that compiles natively and can present a C API like C++, Rust or Kotlin native). Java's "write once run everywhere" has become a sad joke.
- rectang 5y ago
  > the one language that works everywhere and which they have no choice but to support: C I've been tinkering with Rust bindings for Apple Core Audio. AUGraph, which has a C interface, was deprecated a few years ago. Its replacement, AVAudioEngine, has an Objective-C/Swift API. :( There are a lot of generalized cross-platform libraries for guis, audio engines, etc, which attempt to abstract over the differences between native libraries. While noble, these are always going to be very limited and difficult because the library interfaces may make radically different assumptions and have very different high-level structures. To me it seems as though the best strategy to help programmers who want to do cross-platform development similar to you is to focus on providing complete bindings for the platform-specific native libraries (for me the bindings language is Rust but it could theoretically be another one like Go). Once those exist, it expands the amount of code you write that can be shared. It also becomes more straightforward to write cross-platform abstraction libraries. However, my sense is that the platform vendors are heading towards a future where C ABIs are eschewed and where sharing code will be utterly impossible.
  - pjmlp 5y ago
    Here is another one for you, the modern networking stack is also Objective-C/Swift.
  - weq 5y ago
    Exactly what Microsoft does with Xamarin, has extensive tooling to generate platform bindings on every update. I can interop with RUST with no-low overhead as needed.
- sumtechguy 5y ago
  At one point I was porting between different C stacks. I found they would compile just fine. It was when you looked into the details of the different CRT functions you would have some real fun. For example printf is an evil function of randomness, where the parameters are identical but the way it would decode that input string was highly dependent on when it was written and which stack it was in. Now today you have basically 3 different compilers you have to worry about and they mostly act the same now. It is just as you move between libs that it can sometimes get a bit crazy if they use any sort of if/def to change the way some features work (glaring at you pthreads).
sdfdf4434r34r 5y ago
C is the most portable language in practice, so that can't be true.

by nynx 5y ago

Portability of software is a language problem. Some languages make it extremely easy. Others, like C and Go, make it difficult to be correct across all platforms.

rectang 5y ago

C and Go got nothing on Swift. Or .NET which is tantalizingly partially portable.

junon 5y ago

> Portability of software is a language problem I think this is one of those statements that sounds good at face value but doesn't stand up to scrutiny.

Hooray_Darakian 5y ago

Hard disagree there. Trying to write cross distro cli tools can get really hairy really fast when you need to deal with distro inconsistencies in file locations, default configs/permissions, systemd vs not (maybe that one is past now), etc...

omnicognate 5y ago

I wrote an iOS app. I ported it to Android. The only part that didn't need to be rewritten from the ground up (and it worked completely unmodified) was the part written in C. If you have the same APIs available (OpenGL in this case) C is the most portable language there is. Which proves it's not a language issue, it's a platform issue. In fact the owners of the platforms care so little about (indeed actively oppose) compatibility between them that increasingly they make their higher-level APIs only available to a single language so you can't even share the parts of your code that aren't dependent on their APIs. Unless of course you drop into the one language that works everywhere and which they have no choice but to support: C (or something else that compiles natively and can present a C API like C++, Rust or Kotlin native). Java's "write once run everywhere" has become a sad joke.

rectang 5y ago
> the one language that works everywhere and which they have no choice but to support: C I've been tinkering with Rust bindings for Apple Core Audio. AUGraph, which has a C interface, was deprecated a few years ago. Its replacement, AVAudioEngine, has an Objective-C/Swift API. :( There are a lot of generalized cross-platform libraries for guis, audio engines, etc, which attempt to abstract over the differences between native libraries. While noble, these are always going to be very limited and difficult because the library interfaces may make radically different assumptions and have very different high-level structures. To me it seems as though the best strategy to help programmers who want to do cross-platform development similar to you is to focus on providing complete bindings for the platform-specific native libraries (for me the bindings language is Rust but it could theoretically be another one like Go). Once those exist, it expands the amount of code you write that can be shared. It also becomes more straightforward to write cross-platform abstraction libraries. However, my sense is that the platform vendors are heading towards a future where C ABIs are eschewed and where sharing code will be utterly impossible.
- pjmlp 5y ago
  Here is another one for you, the modern networking stack is also Objective-C/Swift.
- weq 5y ago
  Exactly what Microsoft does with Xamarin, has extensive tooling to generate platform bindings on every update. I can interop with RUST with no-low overhead as needed.
sumtechguy 5y ago
At one point I was porting between different C stacks. I found they would compile just fine. It was when you looked into the details of the different CRT functions you would have some real fun. For example printf is an evil function of randomness, where the parameters are identical but the way it would decode that input string was highly dependent on when it was written and which stack it was in. Now today you have basically 3 different compilers you have to worry about and they mostly act the same now. It is just as you move between libs that it can sometimes get a bit crazy if they use any sort of if/def to change the way some features work (glaring at you pthreads).

sdfdf4434r34r 5y ago

C is the most portable language in practice, so that can't be true.