The keyboard controls to select a radio button shouldn't depend on the visual orientation of the radio buttons. Browsers get this right by default, but the radio buttons aren't implemented with `` and instead are just a row of plain buttons and a bunch of javascript. A quick check in the dev tools confirms the other widgets are similarly implemented :(

I love the look, though!

I found a talk with some history of the Spotify client's transition:

https://www.youtube.com/watch?v=9UsnX5X_DF0

It was originally native, then native with some web-based bits, and then the web-based bits slowly ate the whole thing. It seems the ease of development with web-tech compared to C++ (also the better font rendering and screen reader support) was just too tempting.

Interestingly the Spotify client was never based on electron but instead arrived independently at the "chromium + web app" architecture at around the same time as Atom did.

This seems like more of a complaint about egui's choice to re-implement all the widgets from scratch than its choice to use an immediate mode API. The two are orthogonal. The IMGUI idea has its roots in a community of people that like implementing things from scratch, but you could implement it on top of native widgets if you wanted to.

The choice to re-implement native widgets from scratch is justifiable if the egui devs think they can do better than the native widgets do. It's also nearly required in practice if they want the toolkit to have consistent behavior across multiple platforms (something people have learned the hard way multiple times across multiple different UI libraries).

It's hard to get it right, but that's why the egui devs are writing a library: so that others can benefit from that hard work. Many of the things you pointed out are just bugs, and bugs can be fixed.

> but you could implement it on top of native widgets if you wanted to

Is there an immediate mode GUI API that uses native widgets? I don't think I've ever seen that but would be curious to try it out. Does it work well in practice? If it doesn't exist, then it's kind of a moot point, isn't it?

I sympathize with wanting "consistent behavior across multiple platforms", but that usually just results in "consistently kneecapped behavior across multiple platforms".

I was also skeptical of this claim but managed to find someone who explains it:

https://downtownbrown.substack.com/p/five-fallacies-ai-and-d...

It's not that individual companies buy all copies of a given book, but that there's more than one book scanning company, and they aren't sharing the scans with each other. The result: books that were rare but nevertheless easy to find for purchase (thanks to the internet) are now vanishing off of the market, becoming de facto no longer accessible to the public.

Good article, but I still feel unsatisfied because even it cannot find an example of a book that’s actually been lost because of the destructive scanning frenzy (it only lists books that hypothetically could be lost because there’s not many physical copies available for sale online.).

If anyone has an example, I’d love to hear it.

Since we don't know what was actually purchased and what was actually destroyed, how do you expect us to furnish an example? This would require the destroyers to admit it, and beyond that it would require all of them to admit it since more than one of them might have been responsible for the extinction of one text. Seeing as they were already keeping this operation under wraps, I don't see that happening. "possibly extinct because no copies available online" is probably the best we can do.

The distributed nature of the problem and the utter lack of transparency are huge factors here too.

These companies are buying from small book stores; surely these collector types would know if they lost any one-of-a-kinds? Or at least someone would be keeping track of extremely rare books disappearing (especially now since this matter has been public for weeks).

Regardless I feel like they gotta figure this out for optics reasons. “So and so books are lost forever to Anthropic’s servers” is much more outrageous than “Anthropic is destroying a bunch of books that have other copies” imo.

Re-invested how? Many stocks still go up in value even without paying out dividends. Companies with such stocks are technically always re-investing their profits, even as their shareholders become billionaires. It seems to me like a world with the forced re-investment you describe wouldn't be significantly different to the capitalist one.

I don't think this is true. People like to scapegoat the JS standard library but in reality most JS implementations have pretty featureful standard libraries, especially browsers. I've never felt the need to use any third-party libraries in the javascript projects I've worked on (except for maybe `ws`).

There was a recent talk which explored this question (Dependency Cultures, by Richard Feldman):

https://www.youtube.com/watch?v=E82ly38YEEQ

Summary: it's cultural. Rust likely inherited the practice from Nodejs, who inherited it from Ruby. I think in Rust online spaces in particular there is also this undercurrent of "you're not smart enough to use certain parts of the language, so download libraries that handle that stuff for you."

The language also takes backwards compatibility very seriously, anything that goes into std "must be maintained forever". It is also argued that a large stdlib means the maintainers have less time to work on the language itself.

I understand not every language can have Go's amazing stdlib, but I would much prefer Pyhton's approach where every now and then some package/function from the stdlib gets deprecated/removed. Rust's 3rd party ecosystem is the worst thing from the language, worse than the compile times.

The "npm-ness" of Cargo (centralized and standardized dependency management used at every opportunity) is generally pitched as one of the primary developer experience advantages over C++.

For those missing the npm like experience in C, they can use apt, yum, dnf, winget, nuget, conan, vcpkg.

In a large enough C codebase, you may even find yourself somehow using all of these simultaneously. :)

Yep.

i'd like to welcome you to the hell that is c/c++ dependency management. Make? cmake? qmake? conf? autoconf? configure? autotools? submodules??? AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Conan, Meson, Ninja, Bazel, meta-build tool / dependency manager #231 etc. etc. And then you have to deal with all the modern C++ and STL footguns.

It never ends .·°՞(っ-ᯅ-ς)՞°·.

I'd just select a tool, vendor the libraries I need to the codebase and call it a day. Did these for Eigen, liboption++, Catch2, Easylogging++ (now archived and not maintained anymore, sadly).

Build a simple makefile, and you're off to the races.

At least, for my cases, that is.

vcpkg is pretty good. cmake is complex but very flexible. just need an llm to help and it's pretty much solved (if your dep is in autopkg)

All of those can (and some do) wget source code from the internet and run it if you kick off their build pipeline. People just tend to use these tools differently.

Nothing is preventing anyone from distributing Rust crates as standard system packages, like some distros do with Python.

I think Debian is actually shipping rust libs in their repositories: https://wiki.debian.org/Rust Now Rust developers can also enjoy having to deal with popular packages that are years out of date/missing from popular repositories/getting deleted.

Of course they can be made to do anything but that's not what they are designed for and as a result they also build a culture that frowns upon doing that. Debian and other Linux distributions would have never had the policy do handle dependency resolution themselves if contemporary build systems automatically fetched everything automatically rather than being designed to use dependencies provided by the user.

xmake, build2, whatever msvc and xcode insist upon…

> Without methods or overloading, you end up in the situation that C and Scheme are in

Well in C at least we now have this:

  #define clear(s) _Generic((s) \
          ,struct list: list_clear \
          ,struct queue: queue_clear \
          ,struct map: map_clear \
  )(s)

  clear(my_map);
  clear(my_list);
  clear(my_queue);

...although it turns out the other nice thing about methods is automatic namespacing.

Are these a thing outside the US?

For anyone who's not familiar: all over the place at tourist attractions and airports you can find mechanical presses that will squish a penny with an embossed image. You pick one of 4 images, put in your penny + a couple of quarters and then turn a big crank handle until your newly pressed penny comes out the other side. You'd then collect squished pennies in a little collector's folio/pouch/thing for later viewing.

I guess now that pennies are getting phased out they'll have to "upgrade" the machines to work with other coins...

Many traditional machines where you put in 2-4 quarters and a real penny have been phased out for credit card readers now that just drop a penny from inside the machine. It does kind of ruin some of the charm.

They're not even a penny anymore; they're using copper blanks.

That said, I have seen several that take a credit card (or dollar bills) but you still hand crank them, so you still get the experience.

Was just in vegas and one of them kept spitting out blanks. I have a feeling people swiped their card and didn't realize they needed to keep rotating and assumed it broke. Ended up with a whole collection before getting tired and leaving it. No telling how many more it would have spit out.

They do exist here in Germany as well, mostly in tourist destinations. The map does not show any outside the US, though. OpenStreetMap has 662 of them here.

For those who have not seen one in action:

https://youtube.com/shorts/HzCCsZB4jKg?is=377XKg7gUXfMHzA2

Definitely not common but I’ve seen a couple while traveling. I saw one in Gijón, Spain last week. I also remember seeing one at the Tower of London 10ish years ago.

I used a machine like that in Sweden or Norway once many years ago, but although it pretended to squish the coin you put into it I am almost completely sure that this particular machine was instead using a different piece of metal that was already flat and softer material than the metal in a real coin.

They have this sort of thing on the Canadian side of Niagara Falls, but I think they take nickels now (since pennies haven't been minted since 2012).

Lugo, Spain. At least two at souvenir shops at the cathedral. my daughter used both a few days ago :-)

I have seen them in Japan and many European countries, but I don't remember which ones :/

Destroying currency is crime in Australia, so no, this has never been a thing, here.

Same here in Canada. The solution is that the machines accept a Canadian quarter to run the press, but an American penny to be pressed. No Canadian currency is harmed!

It's technically a crime in America too, but I guess Americans are more outlaw than Australians in that rather specific regard.

Only with intent to defraud is it a crime in America to deface US currency. Shaving a bit of the copper off every penny you touch, to melt down and profit from? Crime. Scribbling off the 1 on a $10 bill and scribbling on a 2? Crime. Cutting up pennies to show off the unmatched strength of your shitty kitchen shears? Perfectly legal.

What about intent to gain power over others? https://www.youtube.com/watch?v=f9aM_dT5VMI

It's legal in America

https://www.parkpennies.com/-dl-disneyland-pressed-coin-guid...

> It's technically a crime in America too

I knew before even entering the comment section that someone here would be spreading this myth.

I saw one in El Salvador recently (they use US currency, including pennies).

There was one in Strasbourg, France, by the cathedral

There's one at the Leeds armoury in the UK.

Tower Bridge in London has several.

> random websites that LLM crawlers find but humans rarely see

If my experience on random niche web forums is any indication, future AI models will be biased towards the well-being of online casinos.