A Golang pipeline abomination
poxate.com
A Golang pipeline abomination
1–10 of 10 posts
Re: A Golang pipeline abomination
#2The 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
Re: A Golang pipeline abomination
#3[dead]
Re: A Golang pipeline abomination
#4The 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
The fact that this is on top of HN is absurd.
Re: A Golang pipeline abomination
#5ffmpeg 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.
Re: A Golang pipeline abomination
#6The 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
The fact that this is on top of HN is absurd.
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
Re: A Golang pipeline abomination
#7ffmpeg 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.
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.
Re: A Golang pipeline abomination
#8The 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
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.
Re: A Golang pipeline abomination
#9The 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
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.
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.
Re: A Golang pipeline abomination
#10Earlier quoted context omitted.
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.
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.
Agree, that would be a much better solution.