←back to thread

1113 points Bluestein | 1 comments | | HN request time: 0.328s | source
Show context
etra0 ◴[] 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 ◴[] 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 ◴[] 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 #
Dylan16807 ◴[] No.41278582[source]
The correct place to handle character sets is when you're reading the file, not to sprinkle it all throughout your program.
replies(2): >>41279293 #>>41280115 #
1. josephg ◴[] No.41279293[source]
Right. And the rust standard library provides (in my mind) the right API for this. Strings are always internally utf8. But they have constructor methods to create strings from UTF16 bytes, or utf32 or whatever.

Rust isn’t unique. Swift, Go and Python3 all expose more or less the same api. C’s standard library, with the benefit of hindsight, is uniquely terrible here.