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 def

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.