7 ms·

Programming Language Fragility

30 points by da_big_ghey 6y ago

tyingq 6y ago
I haven't read it in-depth, but it's funny that Perl is marked as "not portable by default". But it runs on everything from z/OS, to VMS, to Unix, DOS, Windows, etc. By default. I do agree that it involves some pretty complex build and install tools and scripts.
watt 6y ago
What a hatchet job. Java software (JAR files) not portable and with licencing issues? It's like OpenJDK never happened.
fefe23 6y ago
I may be missing the point here but this postings makes little sense to me. There is nothing in the C standard that requires dynamic linking. In fact, I have been creating statically linked binaries with C for decades (and still am). Also the definition of portability used here is not helpful. If I take a program and put it on another computer, I can never just expect it to work. The other computer may be running OpenBSD when the first one was running Linux and we are talking about a Windows EXE. This metric makes no sense. The established meaning of portability is whether you can take the source code and compile it on a different platform (but also supporting a development environment for said programming language), and it will compile and work. This is not a function of the programming language. The "winners" of this blog post are winning because they contain compatibility layers. Those work as long as you have one for the target platform. If you don't you may actually be worse off with those languages compared to, say, a basic C environment that does not give you source code portability across all platforms but gives you a workable basis on each platform to bootstrap off of. Also note that being portable may actually turn out to be a downside, because it means you have to limit what you can do to the common denominator of all supported platforms. I recommend disregarding this blog post.
- pdonis 6y ago
  > The established meaning of portability is whether you can take the source code and compile it on a different platform Even this meaning only applies to compiled languages. If I want to run Python code, I don't need to compile it and I don't need a laundry list of supporting tools for compiling and linking; I just need the Python interpreter. Which runs on all common platforms and plenty of uncommon ones.
  - taeric 6y ago
    This is easy to tease out. Portability can be describing compilation or evaluation/interpretation. Take your python example, you don't just need the interpreter. You also need any supporting infrastructure that the libraries used will need. As a trite example, anything that reads from a camera will need a camera available to work. Indeed, some will need specific cameras, if they don't have a portability later. :) As such, portable goes across many layers and cannot be described at just the language level. Not even at a runtime level.
    - pdonis 6y ago
      > You also need any supporting infrastructure that the libraries used will need. This will also be true of a program in a compiled language, so I don't see that it differentiates between different languages.
      - taeric 6y ago
        I felt I was progressing your point. You can't answer if a program is portable based solely on the language.
        throwaway894345 6y ago
        You’re referring to a different definition of “portables than the concept TFA appears to be describing. Within the scope of TFA’s definition, a language (or more precisely, an implementation) absolutely can be portable. Any implementation that can bundle all dependencies (including the runtime) into a single artifact can said to be portable per TFA’s definition of the term. Python could even be portable in this sense if it could zip up the interpreter, libraries, and all so files (however, these bundles would be hundreds of megabytes compressed in practice).
- mikewarot 6y ago
  I tried pulling a C program from 2002 into the present world, it was a nightmare. C assumes word size, Macro functioning and the libraries are all radically different, it wouldn't even compile. C is definitely not portable. I had some Pascal code from 1994, when 16/32 bits ruled the world, I compiled/ran it in 64 bit glory, I did have to take out the one assembly optimization I wrote back then. If there were Lazarus/Free Pascal for the new Apple Silicon, I have no doubt that code would work there as well, with zero changes.
- megameter 6y ago
  Regarding linking: you seem to be conflating concerns with libc's portability with the linking of libc. Libc is a portability concern not because of linking but because it is a worse-is-better compatibility layer. There isn't just one example of it, and it straddles the boundaries of the language ecosystem and the operating environment. If I write C targeting WASM and try to call fopen(), the build system either has to say "no" somewhere along the way, or bamboozle me with a very specific interpretation of what I mean by that, effectively turning it into an unspecified interface. When a language builds on that foundation it gains temporary convenience but misses out on being more encompassing in its approach to compatibility. Your statement only makes sense within a "libc is just the standard" worldview, which I believe contributes to the fragility problem by offloading compatibility into a series of "good-enough" measures instead of documentable specifications.
- elcritch 6y ago
  The list certainly is confusing. It took reading it a couple of times, but now it makes more sense what they appear to be basing the list on. Most C builds default to dynamic linking, so while it's trivial it does take a few tweaks. Though that relies almost more heavily on the particular build system used with C. Actually in that regard Nim should be listed the same as C, as I had to pass a few C compiler options recently to allow running an executable compiled on Linux on amd64 to run on x86 Linux as well. So compared to Go's skipping of libc it'd seem to make sense. Maybe it'd be more obvious if the portability was an effort rating from 1-5. Go is 1, simple C is 2, Nim is a 2, and Rust is a 3, and complex/ancient C autoconf/make anywhere from 2-5. Elixir 2-3, Python 4-5. Based largely on the googling efforts I've done in the past. Regarding the compatibility layer though, the bootstrapping makes sense. Generally C and C compilers are going to be imminently more portable since some variant of C is likely yo be available. Python's standard library is likely going to be an enormous effort to port. Perl/Lua much less so but at the expense of the compatibility layer meaning more individual platform work. Most compatibility layers are going to be a pain or limiting as you say. I'd like to say I'm a fan of Nim's "open architecture" standard library (compatibility layer) having recently done a PR to add support for FreeRTOS. Much of the stdlib worked without modification due to "lazy compiling" of code, including the stdlib. It only tries compiling what you use. Skip the default networking and write a few C/C++ FFI calls networking for the platform and you've got a full library of containers, json parsing, etc. Then you can pretty easily add support for Nim networking compatibility later. For example the 'selector' library has support for various OS specific from ancient 'select' to 'epoll' to whatever Windows does based on what you choose to import. Pretty awesome for embedded. Overall it seems the article is considering portability in two narrow contexts. However, having both tried to ship say a scientific GUI program for non-technical users (e.g. using Python QT) on one hand the first definition is useful, while porting code to embedded projects the other can be useful.
vsareto 6y ago
>C#/F#/.NET - No (complex runtime) - No (fragile bundling) Dunno if I agree with the second column. .NET Core is cross platform now, but I'm not sure what fragile bundling really means here, but it definitely is portable with "effort".
ivraatiems 6y ago
"Fragility" is an interesting concept, but I don't agree with the criteria used here. There are also some severe misunderstandings of how the evaluated languages work. For portability, they ask: "If you write some software in a particular language, can you copy the compiled program to another computer and expect it to work?" This is the wrong question, but it also is answered incorrectly. You can certainly write JavaScript, Java, C#, on most modern platforms and have little trouble porting them. Java, as others have mentioned, is fully portable with JAR files. Node.js is literally JavaScript, which can run anywhere there's a JavaScript engine for the most part (with some asterisks for Node.js's particular flavor). C# compiles to an IL that can be used anywhere, so the parts of the code we're talking about as "not portable" are the binaries wrapped around that. For compilers, they ask: "If the internet stopped functioning, would you be left helpless?" By these criteria, their assessment of compilers is mostly accurate. But I'm not sure what they mean by "acquiring or setting up" the compiler? Presumably that means "copy the compiler manually to another computer" because this is a world with no Internet? In that case, the better question is "can I get an offline installer for these development environments", which is a fairly commonly available thing. Package restore is a bigger question, for those that use packages - but if you have the original binaries, you implicitly have the binaries for all the packages, so not overcomable. I think what this person really means by "fragility" is "survivability" or "disaster preparedness." That's an area of software work that's often undervalued, and I agree that if you are evaluating software on that basis, many of the languages listed with the tools listed are poor choices. But that's such a distinct area of software that its general applicability is limited, in my view.
munchbunny 6y ago
The portability category has some non-intuitive results. By that I mean that I think they're wrong, but it's a matter of how you measure "portability". The criterion the author uses is: > If you write some software in a particular language, can you copy the compiled program to another computer and expect it to work? I coalesced the two columns the author used because it was "No" for both in the four examples below: > Java No Complex and fragile bundling of a separate runtime (with licensing issues) > C#/F#/.NET No Complex and fragile bundling of a separate runtime (with licensing issues) > Python No Complex and fragile bundling of a separate runtime > Ruby No Complex and fragile bundling of a separate runtime I don't think that's how we generally think about portability. We usually consider installing the runtime as the platform dependent tax you pay to get your compile-once artifacts. Compiled JARs are generally considered portable. .NET Core binaries are generally considered portable. Python and Ruby scripts are generally considered portable. Requiring that the application be portable by only copying the files across (without installing the runtime or platform abstraction layer) isn't representative of how users or even dev ops teams that handle mixed-platform carry programs across platforms in the first place.
- throwaway894345 6y ago
  A lot of people are getting hung up on the definition of 'portability'. Yes, the author's definition is pretty obviously using a non-standard definition, but the question is whether the concept he's talking about is helpful. And I think it is--I would much rather have a language like Go where cross compiling is trivial and I can just send my colleagues (even my non-technical colleagues!) a binary file compared to having them install the right version of the runtime and the right dependencies (and probably a virtualenv so it doesn't bungle their system) and then the application code. I don't care very much about whether I can run a single set of artifacts on any target if it's burdensome to prepare the target platform--I'd much rather it be trivial to compile a single artifact for the target platform such that it can just run.
  - svrb 6y ago
    > Go where cross compiling is trivial If that's the criterion the author is using then I don't understand how Rust got a "no". Rust cross-compiling is also trivial and I can compile on one machine for a completely different one and send only the binary output.
6gvONxR4sf7o 6y ago
Not to make this too topical, but I wonder how much this has to do with why I see so many software developers using macbooks. Developing on one is closer to developing on a Linux machine, which is where the code will frequently deploy to. Then, with the rise of less portable languages like python, Microsoft felt the need to invest in the WSL.
nivenkos 6y ago
The standard way to make Rust portable would be to statically link with musl, not necessarily use no_std. It depends if you mean for embedded devices though (although Go is listed as portable, so I guess not). I think it's more useful to look at different use cases and possibilities - like having a GC or not and which deployment targets that affects, the possibility for static and dynamic linking, etc.
whateveracct 6y ago
For Haskell, the libgmp stuff is being solved in GHC 9.0 https://iohk.io/en/blog/posts/2020/07/28/improving-haskells-big-numbers-support/ https://iohk.io/en/blog/posts/2020/07/28/improving-haskells-... It is true that getting static Linux builds is nontrivial - but definitely doable [1]! But the demand is there so I'm guessing the elbow grease will follow in the coming few years :) [1] https://www.joachim-breitner.de/blog/776-Distributing_Haskell_programs_in_a_multi-platform_zip_file https://www.joachim-breitner.de/blog/776-Distributing_Haskel...
deleted 6y ago
[deleted]
anta40 6y ago
The tables says that Nim is both portable by default and with effort. C only portable with effort. This is weird, because Nim (AFAIK) still requires a C compiler like GCC or MSVC to do the final compilation. In fact, you can see how your Nim code is translated into C, something like this: nim c helloworld.nim
- tumult 6y ago
  Nim uses a C compiler, but produces dependency-free executables. This is not something you can do easily in C alone, unless you want to write your own standard lib. (Or on Linux, try to use musl, but that won't always work depending on what you want to do.)
crb002 6y ago
The opposite seems true on M1 support. C is always #1 followed by LLVM ecosystem languages, then the VMs.
eeZah7Ux 6y ago
The article takes an absurd angle at "fragility". It assumes that Linux distributions do not exist and we deploy applications by coping an executable around like people did in 1980. In reality I never had such "fragility" problem around Python. Some distributions did an excellent job at ensuring that all the dependencies are met at build time and that the build is deterministic and reproducible. And that the same dependencies will be available for 5+ years without breaking changes - while also receiving security fixes.
throwaway29399 6y ago
Apparently Go is good and C, C++, Java, Python, Perl, gcc, clang are all "fragile". This is not-so-subtle propaganda.

30 points by da_big_ghey 6y ago

I haven't read it in-depth, but it's funny that Perl is marked as "not portable by default". But it runs on everything from z/OS, to VMS, to Unix, DOS, Windows, etc. By default. I do agree that it involves some pretty complex build and install tools and scripts.

watt 6y ago

What a hatchet job. Java software (JAR files) not portable and with licencing issues? It's like OpenJDK never happened.

fefe23 6y ago

I may be missing the point here but this postings makes little sense to me. There is nothing in the C standard that requires dynamic linking. In fact, I have been creating statically linked binaries with C for decades (and still am). Also the definition of portability used here is not helpful. If I take a program and put it on another computer, I can never just expect it to work. The other computer may be running OpenBSD when the first one was running Linux and we are talking about a Windows EXE. This metric makes no sense. The established meaning of portability is whether you can take the source code and compile it on a different platform (but also supporting a development environment for said programming language), and it will compile and work. This is not a function of the programming language. The "winners" of this blog post are winning because they contain compatibility layers. Those work as long as you have one for the target platform. If you don't you may actually be worse off with those languages compared to, say, a basic C environment that does not give you source code portability across all platforms but gives you a workable basis on each platform to bootstrap off of. Also note that being portable may actually turn out to be a downside, because it means you have to limit what you can do to the common denominator of all supported platforms. I recommend disregarding this blog post.

pdonis 6y ago
> The established meaning of portability is whether you can take the source code and compile it on a different platform Even this meaning only applies to compiled languages. If I want to run Python code, I don't need to compile it and I don't need a laundry list of supporting tools for compiling and linking; I just need the Python interpreter. Which runs on all common platforms and plenty of uncommon ones.
- taeric 6y ago
  This is easy to tease out. Portability can be describing compilation or evaluation/interpretation. Take your python example, you don't just need the interpreter. You also need any supporting infrastructure that the libraries used will need. As a trite example, anything that reads from a camera will need a camera available to work. Indeed, some will need specific cameras, if they don't have a portability later. :) As such, portable goes across many layers and cannot be described at just the language level. Not even at a runtime level.
  - pdonis 6y ago
    > You also need any supporting infrastructure that the libraries used will need. This will also be true of a program in a compiled language, so I don't see that it differentiates between different languages.
    - taeric 6y ago
      I felt I was progressing your point. You can't answer if a program is portable based solely on the language.
      - throwaway894345 6y ago
        You’re referring to a different definition of “portables than the concept TFA appears to be describing. Within the scope of TFA’s definition, a language (or more precisely, an implementation) absolutely can be portable. Any implementation that can bundle all dependencies (including the runtime) into a single artifact can said to be portable per TFA’s definition of the term. Python could even be portable in this sense if it could zip up the interpreter, libraries, and all so files (however, these bundles would be hundreds of megabytes compressed in practice).
mikewarot 6y ago
I tried pulling a C program from 2002 into the present world, it was a nightmare. C assumes word size, Macro functioning and the libraries are all radically different, it wouldn't even compile. C is definitely not portable. I had some Pascal code from 1994, when 16/32 bits ruled the world, I compiled/ran it in 64 bit glory, I did have to take out the one assembly optimization I wrote back then. If there were Lazarus/Free Pascal for the new Apple Silicon, I have no doubt that code would work there as well, with zero changes.
megameter 6y ago
Regarding linking: you seem to be conflating concerns with libc's portability with the linking of libc. Libc is a portability concern not because of linking but because it is a worse-is-better compatibility layer. There isn't just one example of it, and it straddles the boundaries of the language ecosystem and the operating environment. If I write C targeting WASM and try to call fopen(), the build system either has to say "no" somewhere along the way, or bamboozle me with a very specific interpretation of what I mean by that, effectively turning it into an unspecified interface. When a language builds on that foundation it gains temporary convenience but misses out on being more encompassing in its approach to compatibility. Your statement only makes sense within a "libc is just the standard" worldview, which I believe contributes to the fragility problem by offloading compatibility into a series of "good-enough" measures instead of documentable specifications.
elcritch 6y ago
The list certainly is confusing. It took reading it a couple of times, but now it makes more sense what they appear to be basing the list on. Most C builds default to dynamic linking, so while it's trivial it does take a few tweaks. Though that relies almost more heavily on the particular build system used with C. Actually in that regard Nim should be listed the same as C, as I had to pass a few C compiler options recently to allow running an executable compiled on Linux on amd64 to run on x86 Linux as well. So compared to Go's skipping of libc it'd seem to make sense. Maybe it'd be more obvious if the portability was an effort rating from 1-5. Go is 1, simple C is 2, Nim is a 2, and Rust is a 3, and complex/ancient C autoconf/make anywhere from 2-5. Elixir 2-3, Python 4-5. Based largely on the googling efforts I've done in the past. Regarding the compatibility layer though, the bootstrapping makes sense. Generally C and C compilers are going to be imminently more portable since some variant of C is likely yo be available. Python's standard library is likely going to be an enormous effort to port. Perl/Lua much less so but at the expense of the compatibility layer meaning more individual platform work. Most compatibility layers are going to be a pain or limiting as you say. I'd like to say I'm a fan of Nim's "open architecture" standard library (compatibility layer) having recently done a PR to add support for FreeRTOS. Much of the stdlib worked without modification due to "lazy compiling" of code, including the stdlib. It only tries compiling what you use. Skip the default networking and write a few C/C++ FFI calls networking for the platform and you've got a full library of containers, json parsing, etc. Then you can pretty easily add support for Nim networking compatibility later. For example the 'selector' library has support for various OS specific from ancient 'select' to 'epoll' to whatever Windows does based on what you choose to import. Pretty awesome for embedded. Overall it seems the article is considering portability in two narrow contexts. However, having both tried to ship say a scientific GUI program for non-technical users (e.g. using Python QT) on one hand the first definition is useful, while porting code to embedded projects the other can be useful.

vsareto 6y ago

>C#/F#/.NET - No (complex runtime) - No (fragile bundling) Dunno if I agree with the second column. .NET Core is cross platform now, but I'm not sure what fragile bundling really means here, but it definitely is portable with "effort".

ivraatiems 6y ago

"Fragility" is an interesting concept, but I don't agree with the criteria used here. There are also some severe misunderstandings of how the evaluated languages work. For portability, they ask: "If you write some software in a particular language, can you copy the compiled program to another computer and expect it to work?" This is the wrong question, but it also is answered incorrectly. You can certainly write JavaScript, Java, C#, on most modern platforms and have little trouble porting them. Java, as others have mentioned, is fully portable with JAR files. Node.js is literally JavaScript, which can run anywhere there's a JavaScript engine for the most part (with some asterisks for Node.js's particular flavor). C# compiles to an IL that can be used anywhere, so the parts of the code we're talking about as "not portable" are the binaries wrapped around that. For compilers, they ask: "If the internet stopped functioning, would you be left helpless?" By these criteria, their assessment of compilers is mostly accurate. But I'm not sure what they mean by "acquiring or setting up" the compiler? Presumably that means "copy the compiler manually to another computer" because this is a world with no Internet? In that case, the better question is "can I get an offline installer for these development environments", which is a fairly commonly available thing. Package restore is a bigger question, for those that use packages - but if you have the original binaries, you implicitly have the binaries for all the packages, so not overcomable. I think what this person really means by "fragility" is "survivability" or "disaster preparedness." That's an area of software work that's often undervalued, and I agree that if you are evaluating software on that basis, many of the languages listed with the tools listed are poor choices. But that's such a distinct area of software that its general applicability is limited, in my view.

munchbunny 6y ago

The portability category has some non-intuitive results. By that I mean that I think they're wrong, but it's a matter of how you measure "portability". The criterion the author uses is: > If you write some software in a particular language, can you copy the compiled program to another computer and expect it to work? I coalesced the two columns the author used because it was "No" for both in the four examples below: > Java No Complex and fragile bundling of a separate runtime (with licensing issues) > C#/F#/.NET No Complex and fragile bundling of a separate runtime (with licensing issues) > Python No Complex and fragile bundling of a separate runtime > Ruby No Complex and fragile bundling of a separate runtime I don't think that's how we generally think about portability. We usually consider installing the runtime as the platform dependent tax you pay to get your compile-once artifacts. Compiled JARs are generally considered portable. .NET Core binaries are generally considered portable. Python and Ruby scripts are generally considered portable. Requiring that the application be portable by only copying the files across (without installing the runtime or platform abstraction layer) isn't representative of how users or even dev ops teams that handle mixed-platform carry programs across platforms in the first place.

throwaway894345 6y ago
A lot of people are getting hung up on the definition of 'portability'. Yes, the author's definition is pretty obviously using a non-standard definition, but the question is whether the concept he's talking about is helpful. And I think it is--I would much rather have a language like Go where cross compiling is trivial and I can just send my colleagues (even my non-technical colleagues!) a binary file compared to having them install the right version of the runtime and the right dependencies (and probably a virtualenv so it doesn't bungle their system) and then the application code. I don't care very much about whether I can run a single set of artifacts on any target if it's burdensome to prepare the target platform--I'd much rather it be trivial to compile a single artifact for the target platform such that it can just run.
- svrb 6y ago
  > Go where cross compiling is trivial If that's the criterion the author is using then I don't understand how Rust got a "no". Rust cross-compiling is also trivial and I can compile on one machine for a completely different one and send only the binary output.

6gvONxR4sf7o 6y ago

Not to make this too topical, but I wonder how much this has to do with why I see so many software developers using macbooks. Developing on one is closer to developing on a Linux machine, which is where the code will frequently deploy to. Then, with the rise of less portable languages like python, Microsoft felt the need to invest in the WSL.

nivenkos 6y ago

The standard way to make Rust portable would be to statically link with musl, not necessarily use no_std. It depends if you mean for embedded devices though (although Go is listed as portable, so I guess not). I think it's more useful to look at different use cases and possibilities - like having a GC or not and which deployment targets that affects, the possibility for static and dynamic linking, etc.

whateveracct 6y ago

For Haskell, the libgmp stuff is being solved in GHC 9.0 https://iohk.io/en/blog/posts/2020/07/28/improving-haskells-big-numbers-support/ https://iohk.io/en/blog/posts/2020/07/28/improving-haskells-... It is true that getting static Linux builds is nontrivial - but definitely doable [1]! But the demand is there so I'm guessing the elbow grease will follow in the coming few years :) [1] https://www.joachim-breitner.de/blog/776-Distributing_Haskell_programs_in_a_multi-platform_zip_file https://www.joachim-breitner.de/blog/776-Distributing_Haskel...

deleted 6y ago

[deleted]

anta40 6y ago

The tables says that Nim is both portable by default and with effort. C only portable with effort. This is weird, because Nim (AFAIK) still requires a C compiler like GCC or MSVC to do the final compilation. In fact, you can see how your Nim code is translated into C, something like this: nim c helloworld.nim

tumult 6y ago
Nim uses a C compiler, but produces dependency-free executables. This is not something you can do easily in C alone, unless you want to write your own standard lib. (Or on Linux, try to use musl, but that won't always work depending on what you want to do.)

crb002 6y ago

The opposite seems true on M1 support. C is always #1 followed by LLVM ecosystem languages, then the VMs.

eeZah7Ux 6y ago

The article takes an absurd angle at "fragility". It assumes that Linux distributions do not exist and we deploy applications by coping an executable around like people did in 1980. In reality I never had such "fragility" problem around Python. Some distributions did an excellent job at ensuring that all the dependencies are met at build time and that the build is deterministic and reproducible. And that the same dependencies will be available for 5+ years without breaking changes - while also receiving security fixes.

throwaway29399 6y ago

Apparently Go is good and C, C++, Java, Python, Perl, gcc, clang are all "fragile". This is not-so-subtle propaganda.