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 `<input type="radio">` 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 think the narrator is the murderer and is lying about the man in the gray tracksuit. The repeated criticism of Aaron's moral character is a sort of rationalization for having killed him, with the underlying motive actually being a combination of greed and envy. Remember that the funds used to kick-start the trading platform came from a hackathon win that Aaron "stole".

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.

> 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.

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++.

The thing is, just having a centralized standardized dependency manager doesn't in itself force your ecosystem into this dangerous "micro dependency" pattern. Java'd Maven is also a centralized standardized dependency manager, as is Python's PyPI. However, neither the Java nor the Python ecosystem have devolved into having dependency libraries with 4 methods in them becoming used and required by major libraries.

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…

> 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.