←back to thread

Mpv – A free, open-source, and cross-platform media player

(mpv.io)
1113 points Bluestein | 1 comments | 17 Aug 24 18:56 UTC | HN request time: 0.213s | source
Show context
etra0 ◴[17 Aug 24 20:20 UTC] No.41277640[source]▶
A fantastic mediaplayer, quite minimalistic and performant; it does what it's supposed to do!

Also has a fantastic commit where the author rants about locales: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02... worth a read for some chuckles.

replies(9): >>41277828 #>>41278169 #>>41278583 #>>41278590 #>>41279174 #>>41279269 #>>41280950 #>>41284633 #>>41288546 #
josephg ◴[17 Aug 24 21:33 UTC] No.41278169[source]▶
As strange as it is to say, I think avoiding problems like this might be one of the biggest productivity boosts from new languages like Go, Rust, Swift, etc. New ecosystems get a chance to “do over” the standard library and flush all the horrible legacy choices made before we knew better (locales, UTF16, etc).

The standard library in Zig, Go, Rust, and many others is miles ahead of the C standard library or posix api. That is reason enough to use them.

replies(2): >>41278391 #>>41290438 #
bbarnett ◴[17 Aug 24 22:07 UTC] No.41278391[source]▶
I'm skeptical that rust magically deals with, for example, character sets in 30 year old subtitle files, in a way that makes C seem inadequate.

Legacy compatibility has value.

replies(3): >>41278582 #>>41278614 #>>41279103 #
1. commodoreboxer ◴[18 Aug 24 00:09 UTC] No.41279103[source]▶
Not "magically", but more reasonably and without forcing your entire program into a different state, breaking any ability for libraries to work with a huge range of functionality consistently. C locale handling is basically impossible to work with robustly, even before you get into how it can't be effectively used at all in a thread safe way.