Hacker News Reader

Comment by Pannoniae | Hacker News Reader

This blog post really feels like it was written for the sake of writing something. A C library mechanically translated to Go does not magically become a Go library, and the whole thing feels like cargo-culting. ("libc calls bad", "unsafe bad")

I would like to ask, why was this blogpost written? What is the purpose?

View on HN

> I would like to ask, why was this blogpost written? What is the purpose?

I think he's trying to show an alternative MP3 encoder to LAME for Go projects. It does seem that he has fallen foul of the Shine license though.

In his own words, he transformed Shine from C to Go mechanically, but he put the result under a license incompatible with Shine's original LGPL license.

(I wonder if he is reading this thread)

Yeah, the blog author should fix the license. Not ok at all. This is not the case of zero knowledge reverse engineering or something on those lines even.

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.

> 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.]

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.

> 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.

The author is trying to draw more attention to his Quite OK Audio Format which has received positive attention on HN in the past

https://news.ycombinator.com/item?id=34625573

Is it his format? From what I see, the names don't match up

It's not on Braha's own list of projects https://resume.braheezy.net/

It's not his format. He just created a go implementation of that format https://github.com/braheezy/goqoa

Reply on news.ycombinator.com