here’s the same news, from a source less likely to be (or appear to be) biased (SCOTUS Blog): Parties file final briefs before Supreme Court hears TikTok case

and for my fellow primary source nerds, you can also read all the filings in this case. the particular filing that this story is based on is “Reply of petitioners TikTok Inc. and ByteDance Ltd” from Jan 3rd.

directly from the 31 page PDF:

The Government begins by claiming the Act’s TikTok-specific provision is subject to no First Amendment scrutiny at all—a position rejected by all three judges below. It argues ByteDance Ltd. has no rights because it is foreign, and TikTok Inc. has no rights because it has no authority over the algorithm and recommendation engine used on the U.S. platform.

as I’ve posted previously - news articles about this do a very poor job of explaining that the law applies primarily to Apple and Google. it requires them to remove the TikTok app from their respective app stores, with a fine of $5000 per user if they don’t comply. so “it only applies to foreign companies and they have no rights” is complete bullshit.

the DOJ’s position that this isn’t a 1st Amendment issue is laughable. they’re trying to ban force Apple and Google not to distribute the TikTok app, because they dislike the content published via the app. there’s a specific legal term for this - viewpoint discrimination - and it’s one of the clearest examples of speech restrictions that are forbidden by the 1st Amendment.

you will get better answers to your question, and a more productive discussion in general, if you leave your subjective opinion out of the question.

it’s not fully memory safe (there are some programming languages that are even safer, like Ada)?

for example, you might ask instead “why has Rust gotten widespread adoption, that previous safety-focused languages like Ada did not enjoy?”

this is a big ol’ “it depends”

if it’s a hobby project, then by all means rewrite it if you want to.

if it’s a commercial project of some kind - there’s a business that’s making money, and part of the business making money relies on this code working properly - then rewrites are almost always a bad idea.

read Things You Should Never Do, Part I, an almost 25-year-old blog post (man, that’s a weird sentence to write) about why giant rewrites in a commercial setting are a bad idea.

in general, people greatly underestimate how much work is involved in a rewrite. it feels like it should be simpler to start from a blank slate, and tell yourself you’re going to avoid all the mistakes that you hate with the existing codebase. maybe you’re writing it in a new language, or at least a newer dialect/version of the same language.

if the current codebase is a mess…how did it get that way? lack of engineering discipline? a “just make it work now, we can go back and tidy it up later” attitude towards accumulation of tech debt? if those same attitudes are present on the team doing the rewrite, you’re going to end up right back where you started after the rewrite is “done”.

the main things you need for refactoring to be successful is a) tests, and b) a plan.

the tests allow you to refactor with the confidence that if you break something, the tests will point it out for you. trying to refactor something that lacks tests is the worst place to be in, because you’ll want to add tests, and often adding tests requires refactoring the code to be more testable, placing you in a catch-22.

the plan allows you to make those refactoring changes gradually, over time, while still maintaining the system. in the context of a business that’s paying developers to do this work, the businesspeople tend to look poorly on an engineer coming to them and saying “we’re gonna spend the next year or two doing a big rewrite, so in the meantime you can’t ask us for any new features or bugfixes to the existing system. but once it’s done the new system will be really cool, trust me.”

successful refactoring is a Ship of Thesus - you can replace the entire thing, but you have to do it one component at a time.

oh golly why would anyone do such a thing

here’s a totally unrelated news article from about a year ago: UnitedHealth uses AI model with 90% error rate to deny care, lawsuit alleges

you read a post about how awesome C is, asking why more people don’t use it and instead gravitate towards replacements.

you ctrl-F for “security” - no mention

“buffer overflow” - nope

“memory safety” - nothing

“undefined behavior” - nada

this is sort of a reverse Chesterton’s Fence situation. the fence is getting replaced, and you’re talking about how great the old fence was, without understanding any of the actual problems it had.

you wrote some C and found it simple? OK, great, congratulations.

go work on a C codebase that spans 100 or more engineers all contributing to it.

go write some C code that listens on a TCP socket and has to deserialize potentially-malicious data received from the public internet.

go write some C code that will be used on an aircraft and has to comply with DO-178C.

and so on. after you’ve done that, come back here and tell us if you still think it’s “simple and effective” and “applicable everywhere”.

there is a reason C has stood the test of time over many decades. but there is also a reason it is being replaced with more modern languages.

it might be more complicated than you’re looking for (requires a self-hosted server instead of just a desktop app), but take a look at the ecosystem surrounding Subsonic

Subsonic did some licensing shenanigans, but there’s an actively-maintained GPL3 fork called airsonic-advanced

there’s also alternate implementations, Gonic and Navidrome, that maintain compatibility with the original Subsonic API

because they all work with a common API, there’s a variety of clients that can work with the backend.

I’m also a big fan of Beets for music organization, it’s not tied in to the Subsonic ecosystem so you can use them completely separately if you want. it handles tagging, can fetch lyrics, and can also transcode the library (or an arbitrary subset of it) if you want to send it to a portable device. (not sure if this is what you mean by compatibility)

I currently have Beets organizing everything, run Navidrome on my server pointed at the Beets library directory, then Ultrasonic on my phone, and the Navidrome web interface on my desktop. the combo is especially nice for streaming to my phone - Navidrome will transcode FLAC to Opus on the fly, and Ultrasonic has an option to cache those files locally, and to pre-download them over wifi instead of mobile data. so I have my full collection available on my phone, can stream it from anywhere, and the songs I listen to frequently are already downloaded and I don’t have to waste mobile data, or wait for them to load if I have poor cell signal.