4 ms·

While the Go community's dislike of CGO can be a bit unreasonable from time to time (in my humble opinion), the post does say that one couldn't build a CGO vers

While the Go community's dislike of CGO can be a bit unreasonable from time to time (in my humble opinion), the post does say that one couldn't build a CGO version of LAME binding, so turned to the (automated) source transpilation instead. This tells much about the "portability" of C in practice.

lelanthran 3y ago
> This tells much about the "portability" of C in practice. There are multiple products using LAME on Windows. You've mis-identified the product that isn't portable here. IOW, LAME works on Windows in products written in C, C++, Python, etc. It's just that this particular Go library doesn't support Windows. I fail to see how that is a C portability problem, when the C bits already work on Windows. [EDIT: Looking at the Go LAME project that he references, it appears he didn't even log an issue about whatever it was that went wrong on his Windows build. I'm more inclined to believe that he did something wrong than that LAME doesn't work on Windows using the referenced library.]
- lifthrasiir 3y ago
  Portability means many things beside from being cross-platform and compilable on some compilers for the target. Many cross-platform libraries are still cumbersome to compile on Windows, sometimes because they only provide Makefile and autoconf (sigh), sometimes because they have to fetch another dependencies, sometimes because those dependencies are actually system-dependent but can't be easily used [1]. Go has no such issue assuming CGO is not used, so this does relate to my point---source code portability is only a part of portability. [1] For example, Rust `openssl` crate was notably annoying to compile for a long time, even on macOS (it took literally years to make the typical experience smooth enough). And yet it was an essential component for HTTPS! Today we would use the `native-tls` crate instead that avoids OpenSSL on Windows and macOS.
  - lelanthran 3y ago
    > source code portability is only a part of portability. I broadly agree, but in this particular case: 1. LAME compiles just fine using multiple different compilers on Windows (including an older MSVC - newer ones will error out on the use of unsafe functions, fixed by passing a #define in a flag). 2. LAME has no dependencies to download. 3. LAME is successfully used from many other languages on Windows. So, yeah, if it's not working for him but works for everyone else, you can't blame C for portability here. OTOH, because LAME is written in C, you have even more options - don't compile it yourself. Download the compiled LAME .dll and just use it from Go. Author didn't even try the easiest option, said easiest option being possible only because it was written in C.

lelanthran 3y ago

> This tells much about the "portability" of C in practice. There are multiple products using LAME on Windows. You've mis-identified the product that isn't portable here. IOW, LAME works on Windows in products written in C, C++, Python, etc. It's just that this particular Go library doesn't support Windows. I fail to see how that is a C portability problem, when the C bits already work on Windows. [EDIT: Looking at the Go LAME project that he references, it appears he didn't even log an issue about whatever it was that went wrong on his Windows build. I'm more inclined to believe that he did something wrong than that LAME doesn't work on Windows using the referenced library.]

lifthrasiir 3y ago
Portability means many things beside from being cross-platform and compilable on some compilers for the target. Many cross-platform libraries are still cumbersome to compile on Windows, sometimes because they only provide Makefile and autoconf (sigh), sometimes because they have to fetch another dependencies, sometimes because those dependencies are actually system-dependent but can't be easily used [1]. Go has no such issue assuming CGO is not used, so this does relate to my point---source code portability is only a part of portability. [1] For example, Rust `openssl` crate was notably annoying to compile for a long time, even on macOS (it took literally years to make the typical experience smooth enough). And yet it was an essential component for HTTPS! Today we would use the `native-tls` crate instead that avoids OpenSSL on Windows and macOS.
- lelanthran 3y ago
  > source code portability is only a part of portability. I broadly agree, but in this particular case: 1. LAME compiles just fine using multiple different compilers on Windows (including an older MSVC - newer ones will error out on the use of unsafe functions, fixed by passing a #define in a flag). 2. LAME has no dependencies to download. 3. LAME is successfully used from many other languages on Windows. So, yeah, if it's not working for him but works for everyone else, you can't blame C for portability here. OTOH, because LAME is written in C, you have even more options - don't compile it yourself. Download the compiled LAME .dll and just use it from Go. Author didn't even try the easiest option, said easiest option being possible only because it was written in C.