ThatGeoGuy

You might be thinking: "But, if I see an result/error value that I didn't expect while running my program, the stack trace will help me track down the issue!" Yeah, no kidding. So, let's also start adding stack traces to our successful values, too! After, all, if I call my division function and get back a `Result::Ok` with a weird number that I didn't expect, I might want to trace that back, too, right? (This suggestion is sarcastic to prove a point. It should, hopefully, sound ridiculous to add stack traces to every return value from every function.)

I don't think I disagree with the ends you're proposing (don't add stack traces to every value, don't add stack traces specifically to Result::Err(E) variants); however, this is a bad way to justify it. Tools like dtrace / bpftrace do exactly this kind of stack tracing for both success and error cases across entire systems. This is a good thing™, and is actually very useful for both debugging, performance profiling, and understanding what your code is really doing on the hardware.

So I guess I disagree with how you're framing it. I would argue that adding stack traces to every value in Rust would be bad because it is a lot of overhead for something your kernel can and will do better.

The issue is that Rust's Result (and Java's checked exceptions) require a different paradigm. A Result is in the type signature because it's part of your domain's API design. It's just values. It's not for* debugging. You use a debugger for that or programmatically panic when something is truly unexpected and get the stack trace from that.*

This really is the gist of it. However, I will say that in my experience the reason that Result types are nice (over e.g. exceptions) is that putting the error cases in the type contract means that you can have the compiler check when someone hasn't handled an error case (? and unwrap are "handling" it even if they may not always be appropriate), as well as statically verify which variants may be unused. One very frustrating thing I've had to encounter in C++ is finding a whole list of different errors that have been duplicated as multiple different opaque (e.g. behind a unique_ptr<std::exception> or some such) exceptions across the codebase.

Being able to know what variants of error can come out of an API is great! It just happens that working with a rich type system like Rust makes it possible to do all manner of things that languages-with-only-exceptions cannot.

Thanks for the heads up! Seems my excerpt urls had some errors!

Quick nit/question. For the fold method, I don't think I've seen it called sentinel value. Usually it is seed or initial?

I think in Scheme it is common to call it knil, mirroring how lists use nil as the "sentinel" value which marks the end of a proper list. I opted to name it sentinel in that article (and in the docs) for two reasons:

1. Sentinel values are a common topic in many languages https://en.wikipedia.org/wiki/Sentinel_value

2. Transducers necessarily abstract across a lot more than loops / lists. Lisps do a lot of really cool (and optimized) stuff with lists alone and Scheme is no different in this regard. However, because of how Scheme primarily exports list operations in (scheme base) is really easy to run into a situation where lists are used in an ad-hoc way where another data structure is more appropriate. This includes vectors, sets, mappings, hashmaps, etc. Transducers-the-library is meant to be general across operations that work on all of these types, so I chose language that intentionally departs from thinking in a list-focused way.

Now, my main question. Transducer? I'm curious on the etymology of that word. By itself, I don't think I could ever guess what it was referencing. :(

This is from Rich Hickey's presentation: https://www.youtube.com/watch?v=6mTbuzafcII

It's not a reducer, because they serve as higher-order functions that operate on reducers. Instead, the values they accept are transient through the function(s), so they transduce. You should watch the video, I think Rich explains the origins of his language very well.

Author of the post here, hi! Funny to see this resurface again, I have made a number of changes to the transducers library since this blog post (see: https://wiki.call-cc.org/eggref/5/transducers).

A vector-reduce form would be trivial but icky, and I chose not to do it to not have to have the continuation safety discussion.

I am not sure what "continuation safety" refers to in this context but I wanted a library that would give me a good out-of-the-box experience and have support for commonly used Scheme types. I have not yet added any folders/collectors/transducers specific to some types (like anything related to streams or SRFI-69), but I think a broad swath of types and patterns are currently covered.

I think in particular my griped regarding vectors were that collectors such as `collect-vector`, `collect-u8vector`, etc. were not implemented. There is a chance to break out of these collectors using continuations but that's not really a good argument to not have them (I hope this is not what you're referring to!).

Anyway, if I read things correctly the complaint that srfi-171 has delete dupes and delete neighbor dupes forgets that transducers are not always used to or from a data structure. They are oblivious to context. That is why both are necessary.

I think this is exactly my argument: they are oblivious to context and actually do the wrong thing by default. I've seen this happen in Rust with users preferring `dedup` or `dedup_by` (from the Itertools crate) rather than just constructing a HashSet or BTreeSet. It almost always is used as a shortcut to save on a data structure, and time and again I've seen it break workflows because it requires that the chain of items is first sorted.

I think this is is particularly damning for a library that means to be general purpose. If users want to implement this themselves and maintain it within their own code-bases, they're certainly welcome to; however, I don't personally think making this kind of deduping "easy" helps folks in the general sense. You'd be better off collecting into a set or bag of some kind, and then transducing a second time.

From what I can see the only differences are ordering of clauses to make the transduce form generic and naming conventions. His library shadows a bunch of bindings in a non-compatible way. The transduce form is still not generic but moves the list-, vector-, generator- part of transduce into a "folder". Which is fine. But a generic dispatch would be nicer.

Shadowing bindings in a "non-compatible" way can be bad, but it also helps to make programs more clean. If you're using transducers across your codebase, you almost certainly aren't also using e.g. SRFI-1's filter.

As for generic dispatch: I agree wholeheartedly. I wish we had something like Clojure protocols that didn't suck. I've looked into ways to (ab)use variant records for this sort of thing, but you run into an open/closed problem on extending the API. This is really something that needs to be solved at the language level and something like COOPS / GOOPS incurs a degree of both conceptual and actual performance overhead that makes them somewhat unsatisfying :(

And also: thank you for SRFI-171. I disagree with some of the design decisions but had it not been written I probably wouldn't have even considered transducers as something worth having.

This is more or less what Sean Baxter was trying to do with https://www.circle-lang.org/.

Of course, this requires buying into a set of tooling and learning a lot of specific idioms. I can't say I've used it, but from reading the docs it seems sound enough.

I think in terms of use-cases there is bound to be a lot of overlap. Of course, in terms of comparable products, I'd have to mention that Luxonis sells a good number of different products, so understand that there's a necessary disclaimer here that HiFi isn't going to replace every possible option that Luxonis offers (especially their modules / full robot offerings, HiFi is just the sensor!).

In terms of how we differentiate ourselves, I think the main focus is going to be primarily in terms of depth quality and software. Our expertise in providing robust calibrations, combined with the improved optics on the HiFi allow us to produce much higher quality depth frames, more consistently, than what we see on the market today.

In fact, the whole purpose of building this sensor was to bring to market a 3D depth camera that provides good quality data, always, to better enable long-term autonomy. AI tools and capabilities enhance that data in a way that customers have told us existing market offerings are currently lacking.

As for software: We're a software company at heart, which helps, and HiFi is meant to be a flagship representation of what our software can power. We've used a lot of sensors, sensor APIs, SDKs, etc. and the number one thing we find is that these systems are complex, opaque, and difficult to debug or understand. A big part of designing software for me personally is producing software that is legible; not in the sense that one can literally read it (because reading code isn't easy), but in the sense that the software itself can be understood in the abstract. We're hoping that when we ship HiFi and the corresponding SDK that folks will appreciate the steps we've taken to make working with it understandable and obvious.

It would perhaps be more accurate to say that this is a big leap forward compared to most existing off-the-shelf depth cameras for robotics. To address the iPhone specifically: you probably aren't going to mount iPhones on a bunch of production robots in the field.

Comparing to other alternatives in the robotics space (I've listed RealSense and Structure above, but there are others), there is somewhat of a laundry list of potential pitfalls and issues that we've seen folks trip over again and again.

Calibration is a big one, and a large part of what we're doing with HiFi is launching it with it's own automatic, self-calibration process (no fiducials). There are some device failures that a process like this wouldn't be able to handle, but the vast majority of calibration problems in the field result from difficult tooling or requirements, a need to supply one's own calibration software, or a combination of hardware and software that make the process difficult. A nickel for every time someone has to train a part-time operator to fix calibration in the field, and I'd own Amazon.

Depth quality and precision is another big pitfall — there are folks out there today using RealSense for their robot, but we've talked to a number of folks who just don't rely on the on-board depth. It's too noisy, it warps flat surfaces, etc. Lots of little details that on the surface you might not think about when just looking at a list of cameras! Putting our edge AI capabilities aside, the improved optics and compute available on the HiFi allow us to build a sensor that always provides good depth. That sounds like a baseline for this kind of tech, but there's plenty of examples otherwise on the market today!

Software is probably the other last big thing that we really want to leap forward on. We don't have too much to say about our SDK today, but when we launch it we hope to make working with these sensors a lot easier. I work with RealSense quite a bit (I am the maintainer of realsense-rust), and quite honestly what has been a solid overall hardware package for many years (until HiFi, I hope) is let down by how confusing it is to use librealsense2 in any meaningful project.

Needless to say, I think HiFi stands on some solid merits and I'm not sure it can be directly compared to other 3D sensors in e.g. iPhones, mostly because the expected use-case is so utterly different.

Hey all, senior engineer on the Tangram team here — we're really excited to be launching HiFi today!

Through past work with similar sensors [0][1], we've heard a lot of feedback about what people want from a depth camera! With our expertise in calibration & shipping sensor SDKs in the past, we saw this as an amazing opportunity to ship what we think is a big leap forward in sensing: 1.6MP cameras, AI capability (up to 8 TOPS / 8GiB onboard memory driven via TIDL), and what is most relevant to me: self-calibration and rock-solid software support.

I've spent the better part of my career building and helping develop multi-sensor systems! We hope you'll pick HiFi for your project (and even if you don't, none of our software is locked to any specific hardware vendor). HiFi is a great chance for us to flagship our software on a first-class piece of hardware, and we want to share that superpower with all of you!

[0] https://gitlab.com/tangram-vision-oss/realsense-rust

[1]: Myself, as well as various members of the team used to work at what is now https://structure.io/

I think the core difference is that as a teen we see people reject tech and assume that it's the tech itself being rejected. That there is some underlying progress being shunned.

As an adult I realize that the tech is a layer of gloss and glamour on actively making the world worse than I knew it could be. I didn't have that perspective as a teen because as a teen I hadn't known the world.

but I have thought about generalising things like numerical ranges by having something like unfold-transduce.

This is more or less what I was wondering about. Numerics, ports, SRFI-41 streams, etc. There's a lot of stuff that isn't in e.g. r7rs-small but is more or less expected in most Scheme implementations.

An alternative, R7RS implementation that I also maintain for (CHICKEN) Scheme: <https://wiki.call-cc.org/eggref/5/transducers>

I believe I've submitted my own blog post on transducers in the past. See <https://www.thatgeoguy.ca/blog/2023/01/04/reflections-on-tra...>

To bjoli: Have you seen my library? Any intentions to update the SRFI and incorporate more types?

That's also an outlier, but less than 30k isn't which makes this post somewhat misleading (at best).

I don't disagree that this _isn't_ misleading in a way but it's also important to consider that most EVs are subject to what you said right after:

Ford's cars are probably too expensive because they ignored the EV market for a decade and it takes time to scale up production and reduce costs.

Notably that Tesla still isn't at a scale of production where walking off the lot with a < $30k vehicle is possible! There usually isn't a lot to walk off of, but its rare that the base model will be available at all!

Most of the cars they are producing are not the base package, and likely will never be. The thing about supply chains here is that the "base model" is a much smaller percentage of actual manufacturing. Most of the time if a manufacturer were to produce 1M units a year, less than 30% will be the very base model. I'm not sure there are clear numbers published anywhere, but you can bet that while the "base model" might seem affordable you're unlikely to find it due to the same supply chain constraints — Tesla would much rather up-sell you to some package above the base model and availability is restricted as-is, so which customers do you think they'll prioritize? Tesla isn't even producing millions of units yet (I think last year was just over 600k?), and this is just a drop in the bucket in the number of cars purchased each year.

I'd guess this is because Ford can't profitably make an affordable sedan (they can't do so without losing a lot of money) so they need to make a more expensive vehicle with better margins, Tesla did this too of course - they just had a decade head start while the legacy manufacturers did nothing.

They don't "need" to make larger vehicles with better margins, they just prefer to have better margins. A lot of this is a downstream effect of CAFE exemptions on "light trucks," which applies to both SUVs and modern pick-up trucks. I guess my disagreement here isn't that they "can't" make sedans unless you're defining "can't" in terms of "what the shareholders said." We can absolutely regulate these things and it would probably be beneficial to do so.

As for why Tesla isn't making massive trucks? EV physics (weight of batteries vs. amount of energy to move said weight) somewhat preclude this, but counterpoint there is that Tesla is making a truck and wants to be on top of that market. Sedans are in a weird space with EVs since the added weight kind of puts you in a range<->weight arms race. While most people probably don't need as much range as they think they do, you end up picking between the atrocious Hummer EV or a Model 3 (which is still very large for most of the trips you'd take with a sedan!!!).

System76 is based in Denver, Colorado. Presumably, this is where COSMIC is being developed.

Look I'm not exactly engaged enough to dismantle this piece by piece so this will probably be my last comment but:

Ambivalence is the human default, and logic requires it must be so.

You'd do well to do more than assert it. This is ideology.

You loudly proclaim your aversion to all human suffering, past and present, and claim to know how to fix it.

I said no such thing, and the remainder of your prior statements are also asserting I made any such claim. Making efforts to fix wrongs is not itself a moral failure, nor is it some kind of foolish pride.

We can't address ALL suffering. That doesn't mean that we can't address ANY suffering.

What is odd to me is that this is exactly my point. If you somehow think that racism isn't still "in front of us" as you so boldly claim, I encourage you to prove that substantially and convince the people who to this day still feel victimized by it.

But the solution to the KKK (the original recipe anti-black version) is not to invent a ~KKK (the crispy anti-white version) and tell whites that if they don't join ~KKK then they are in the KKK.

I haven't claimed this at all. For what its worth though — you are in some form invoking the paradox of intolerance here. I'm not sure why you felt the need to write this screed, it is entirely separate from anything I've said and completely off-the-rails.

I think it is probably unwise to pre-suppose an extreme here (that society will never "progress").

The default action today is "do nothing and don't acknowledge the problem." Suggesting any action be taken against that status quo does not in any way suggest that it is a permanent inviolable law that society must continuously optimize for nor does it suggest that it can't be done in tandem with other "progress" society may achieve.

Yeah, every time the discussion comes up about, for example, reparations for the descendants of slaves, I start out thinking: it's been 150 years!

Well, that might be a bit disingenuous. The "last chattel slave" was only freed around September 1942. I've seen this reference in several places, but the most direct one is a footnote on a wikipedia page [0].

Regardless, it is probably not worth putting a time limit on suffering. The children and grandchildren of enslaved black people are still alive today! Waving it away with "time has passed" seems more an attempt to bury the issue than to approach it with some semblance of acknowledging the wrong done.

[0] https://en.wikipedia.org/wiki/Beeville,_Texas#/media/File:Be...

In addition to this, I always think about Matt Might's "Parsing with Derivatives." [1]

I'll have to read about flap, as it seems to utilize a lexer based on derivatives.

[1] https://www.youtube.com/watch?v=ZzsK8Am6dKU

The incentive structures of the organizations producing the software.

If your software is slow, it's probably because nobody was incentivized to make it not-slow. There's plenty of software out there that's fast, but if perceived slowness isn't costing someone money and making a company's life harder, it's unlikely to get solved.

Two examples:

1. My gmail can be horrifically slow some days. It's not because Google is unable to make IMAP sync fast, or that there's some inherent protocol limitation for what I perceive as 'being slow.' I run my own mail on DigitalOcean and I consistently am faster to sync large quantities of mail relative to a gmail address. Google isn't incentivized to make their free service faster, since they aren't losing money when I complain that gmail is 5 seconds slower to sync similar or lower volumes of mail compared to my own personal server. Note: I understand why there's good reasons for this.

2. Netflix and Youtube have a ton of backend servers and services that can be selected to immediately stream to any given computer on the planet, should someone click on a video. These are extremely highly performant and allow basic compute-heavy loads to be spun up at literally the click of a button on a webpage. It is specifically some engineer's job to get delivery windows on videos down as much as humanly possible because the organization makes more money from users (people tend to avoid services with huge delays, thus decreasing ad / subscription revenue) and spends less money if they aren't wasting compute.

Software speed is entirely dictated by the incentive structure around it. If you want to complain about why software is slow, it is useful to understand who's problem that is, and whether perceived performance is enough of a blip on the radar to be worth investing someone's time in it.

If the solution is to ban cars because you don't like the noise, it sounds like you just don't like cars.

Guilty as charged. That said: the noise itself isn't entirely just the problem so much as how prolonged it is. Having buses and readily-available public transport that are only loud occasionally and on a fixed schedule isn't the same as a constant stream of traffic. Even if the bus or train is louder (and light rail is usually much, much quieter), it isn't all-day, only at fixed intervals.

There are marginal gains to be had. Reducing the amount of driving and traffic in our cities is good for a lot of reasons, but particularly with noise it's a combination of speed, vehicle size, and overall frequency of vehicles that makes a killer combination.

The solution is to place noise restrictions on vehicles (this goes against manufacturers putting off any kind of noise reduction), reducing speeds (this involves walkable / bikeable infrastructure), and expanding public transit like bus and light rail access to reduce the total number of personal vehicles on the road.

Yes, this will make things "worse" for drivers. But it's not the end of the world. If you ever visit Zurich or Geneva, you'll be able to distinctly tell the difference between an American city and a European city in terms of noise alone :) Zurich's tram system is honestly something that every city should dream of having, and it is as quiet as one could hope for.

Some of these are things we can control with infrastructure and regulation (e.g. why is your airport so close to housing?), and others aren't really what I would consider problematic noise.

Sirens are an unfortunate reality, but the reason they're so loud is because most cars have a ton of sound-proofing. I'm sure you know this, but you can hear sirens blocks away when they're trying to alert a driver... maybe 20 metres in front of them to move out of the way?

As for excitable drunks, I think there are places where that's a constant problem, but again, this isn't constant and permanent. Traffic noise and airplanes are pretty constant though - I live on what should be a pretty quiet stretch of land but the local stroad always has at least a few really loud cars in the wee hours of the morning. The rest of the day it's just lots of regular cars making a lot of noise as cars are want to do. At least with the excitable drunks they don't make noise all hours of the day, since they have to sleep or be drinking at some point!

An addendum to the posted article: https://www.youtube.com/watch?v=CTV-wwszGw8

Cities aren't loud; motor vehicles are. Tire noise near heavy stroads and highways are in particular egregious offenders. There's a lot of other points in the comments about some other urban nuisances (leaf blowers, anyone?) but I encourage anyone to walk around (yes, walk) while measuring the ambient noise levels with your smartphone's microphone.

It will be extremely obvious where the noise is coming from. This is an often misunderstood part of "the war on cars:" the stress gained from additional constant noise (e.g. like a highway) takes YEARS off our lives.

And don't get me started on how loud shops are in North America. For whatever reason they seem to always keep the volume three or four levels above comfortable, making it much harder to have a conversation without shouting at least a little.

It wasn't until I started traveling a lot that I started to notice any of this. You can have your quiet part of town, but often you get to your quiet part of town by driving through the noisiest part of town where a good number of people live and work.

I'm approximately in the 900-1100/month range.

Based on their existing pricing at the $10 plan, that's 700 searches plus up to 400 searches at 15c / search.

Total is ~$16 / month depending on how many searches I make. The unlimited plan is appealing, but I'm convinced paying something in the range of $16-$25 a month ($192 - $300 / year, or $163 - $255 / year with their 15% annual discount) is still a steep price.

Sure - search is valuable, and ~$160 / year could work for me, but the variable nature of the cost is off-putting. Part of the issue is the per-search unit pricing: why can't I pay up-front like in the unlimited plan for a whole year, at the benefit of a slight discount? As someone who does pay for SaaS plans and is willing, I'm not excited about surprise monthly bills as an individual user.

My advice to Kagi would be to find a way to do annual billing without resorting to such fine-grained unit pricing. Charge per every 100 searches instead of 15c/search (e.g. charge $1.25 for 100 /extra/ searches on top of whatever plan I'm on), and have a rollover period (e.g. two months) if I purchase an extra 100 searches but only use e.g. 20 of them.

This kind of billing (annual discount for all plans + broader unit pricing) would reduce the price shock and anxiety of worrying about how much a single search costs.

I think Kagi can be an interesting product, and even one I probably will pay for, but the amount of thought into their current pricing seems naive from my view...

It's not chargebacks specifically, but you can find a handful of articles and websites detailing how MasterCard and Visa in particular deciding that they will not allow certain kinds of adult content.

They flex this by putting leverage on the banks to not support this either, as they could lose the ability to work with Visa or Mastercard if they start doing banking outside their TOS.

There are some reasons why this could be a good thing - pornography is an industry rife with problems of trafficking, abuse, etc. and denying funding of that kind of behaviour is not without reason. But this tends to spill over to just about everything that /isn't/ abusive as well, which leads to adult sites and the like not being able to secure their own funding or get support from banks.

It is likely a function of density. India is particularly heavily populated and their cities are very dense.

Suburbia and lower-density neighbourhoods will necessarily reduce the number of chance encounters, and thus possibilities to make friends. In many developed nations the only places to "be social" can often also be places in which you can only participate in through the lens of commercialism (e.g. going to a sporting event, paying to play pool or darts at a bar, etc.). This is often described as the loss of the "third place." It's heavily associated with sprawl and car-centric development, but even without that there's tons of places that don't have nearby public parks or plazas that they can just go and exist in without spending money. The pretext of a place to socialize and hang out changes if you need to spend a significant amount of money to participate.

Another reason could be that having easy access to cheap digital entertainment probably reduces the number of times most people voluntarily leave their house to go be social. I know at least for myself that I can easily hole up in my home and avoid the outside world if I want to. You have to make a conscious effort to decide to go out and do social things, and that can sometimes be very difficult in tandem with my previous point about sprawl. Do I really want to drive somewhere and spend money to be social today or should I just find a new show on Netflix? A hard problem when we structure our own incentives against our desires to make more friends!

Someone else has already mentioned a bicycle, but my vote would be for a bicycle with an e-bike upgrade kit.

Do the hard work upfront to find something compatible, in particular around batteries (so they don't e.g. start a fire). From there, upgrading a regular bike to an e-bike and routing all the cables / logic circuits / etc. is a project unto itself. At the end this kid gets a fun and efficient means of transportation, as well as the satisfaction of knowing how their bike is put together both mechanically and electronically.

I still retain a similar model to patio11: https://twitter.com/patio11/status/1532509304846135296?s=20

Regardless of how you want to word it, or how you perceive it to play out socially, it does not diminish the act.

Tangram Vision [0] is also a startup and we also use Rust. We're using it to develop robotic / autonomous sensor calibration tools that would normally be written in a variety of C / C++ libraries.

For context: most if not all of our team has developed calibration tooling similar to what we're doing now in the past, just at different startups and very specific to certain robotic or sensing configurations.

If anything, once we got CI sorted and started using our own internal registry I would argue that we are significantly faster in terms of iteration time. This is partly because the team is small, but also because most of our tooling is consistent and easy to keep in lockstep. Pulling libraries is done uniformly across platforms and architectures, and our CI runs (through GitLab) stay up-to-date with the latest tooling without issue. Having a stronger type system to detect errors early and a compiler that actually tries to give human-readable messages (looking at you C++ linker errors) using that type system makes everything so much easier.

Compile time seems like it would be an obvious bit that slows one down, but in practice sccache [1] does what it ought to and we barely notice it (at least, I don't and I haven't seen team members complaining about build times). Mostly I'd argue that the real thing holding us back is tooling extant to the rest of the wider Rust ecosystem. Debugging and perf tools are great in Unix land, but if you're making anything cross-platform you need to know more than just perf. That might just be my opinion though, I'll admit I'm still learning how best to apply BPF-based tooling even in Linux alone.

I also realize I'm responding to steveklabnik, so I suspect most of what I'm saying is well-known and that this comment is really more directed at TFA.

[0] https://tangramvision.com

[1] https://github.com/mozilla/sccache

Vehicular cycling is such a ridiculous ideology and mantra. John Forester has done more damage to not-cars-means-of-transportation than pretty much any other person riding a bike, and many more outside of that group.

The "Well there's your problem" podcast goes over a lot of his ideas in great detail [0]. The crux of it is what the above study says: if you want to encourage cycling you have to build dedicated infrastructure (and maintain that infrastructure in all weather and conditions) in order for people to view it as something reliable.

The key is to avoid what the parent poster specified by just increasing supply: to assuage fears that there are "only a handful of bike lanes and paths (and thus cyclists fear they are confined)" is to just build more. It's vastly cheaper than our current car-focused infrastructure. Cities exist today that seem to figure this out without turning into Amsterdam, so surely the rest of us can figure it out as well.

[0] https://www.youtube.com/watch?v=zm29fd-s7tQ

Which starts to look an awful lot like dependent types. Unfortunately any sane use-case of that in 2023 looks like Idris or Coq and nobody in C++ today is switching to either of those.

Some parts are extremely Linux-centric.

I'd argue the better parts of systemd (it's not all bad but there's a lot of low-hanging fruit for all of us to gripe and bicker about) are the imaginings that came from launchd. That for sure was more UNIX centric than "linux" in particular.

You're right that the criticism "just become windows" seems weird - if anything else one should just say "get a mac" since that's where a lot of the launchd ideas originated.