A Golang pipeline abomination

https://poxate.com/blog/golang-pipeline-abomination

by kermerlerper • 2 years ago

21 8 2 years ago

38• 2 years ago

The problem is 100% ffmpeg, Go has nothing to do with it other than it's being used as a better shell script. Also some errors are checked and not others, and a large amount of files are opened and never closed

vrosas• 2 years ago

The fact that this is on top of HN is absurd.

Raed667• 2 years ago

i think it reflects how some people feel about go, where every complaint is treated as ‘skill issue’ so things like this bubble up out of frustration

kermerlerper2• 2 years ago

I agree that Go is not at fault here. However, I don't think FFmpeg is at fault either. It's just a fact of life that you can't seek in a stream with no buffer. As for the error handling, I purposely leave that out of my articles. Obviously, you shouldn't do this in production code.

fragmede• 2 years ago

In this particular case, it's just combining two tracks though. Could just do this directly in golang without using ffmpeg and not deal with it's shortcomings in such a manner.

C-programmer• 2 years ago

ffmpeg has libraries. Why are you forking a separate process to call a single function? This is a very common problem I see in high level languages with poor C interoperability. Although cgo works fine, so what gives? Less code for more problems.

treyd• 2 years ago

cgo doesn't just work fine, it's still treated very much as a second-class citizen by the Go tooling. It doesn't integrate with the standard build tooling properly and requires additional manual steps. You also can't really have an upstream dep that uses cgo internally, the burden falls onto the end binary to manually set the flags correctly.

A Golang pipeline abomination

Related Stories