Agreed, mostly. To me the effectiveness of window managers is a bellwether of the control aspect. So, IMO, if you compare them on control or on the quality of window managers, you'll get the same result. Linux has ended up with many window managers (effectively catering to various styles and needs), while macos, for example, has a one-size-fits-all approach with no REAL multiple-desktops (Spaces is a joke and a toy). As a result, I can easily manage 50-100 open terminal windows on my linux box, but on macos 5 is too many (and if I use Spaces to fit a few more, I can't get to the terminal I need in less than a second. In linux, even with 100 xterms, I can). So, a macos product manager might probably ask me why I would want 100 terminal windows, to find me some alternative. In linux no one asks me that question, and hence I can have what I want.
I believe by a wide margin the most significant long term problem with rust is lack of a good and comprehensive standard library, or a FEW set of crates that provides a really good set. We are in the age of supply chain risks and I personally know many great engineers who shun languages whose community / library providers don't take this problem with utmost care. At this point in time, rust is being treated like nodejs. That is not fair to rust, but that is the reality of the current situation.
Go, on the other hand took simplicity as a major goal, and while not the most efficient or expressive language out there, that single goal is paying massive dividents.
The good news is, all this means, is that rust can / will be a lot more serious when someone, possibly a big corporation with deep pockets to maintain this until a critical mass has formed, develops and maintains a golang-style standard library. It can be like C++'s in which the initial std lib was crap compared to what it is now. But people ended up using and eventually evolving the language and the std lib together. We are missing that kind of library at the moment.
Or just make it more difficult to squat obvious namespaces, and add an identity management system (like PGP Web of Trust, but simpler) so you can limit yourself to trusted packages, e.g. packages vouched by your preferred set of root signers who publish compilations of trusted publisher keys.
Expecting a kitchen sink approach for a low-level language can't work out. In low level systems languages your algorithms and interfaces are (or should be) much more tightly bound to specific solutions. It's much easier for abstraction to become excessive and counterproductive.
> so you can limit yourself to trusted packages, e.g. packages vouched by your preferred set of root signers who publish compilations of trusted publisher keys.
This is really not good enough. The real gigantic problem with supply chain risk is not that you get tricked to use a package by bad actor, it is that if everyone using gazillion packages by known good authors, that makes all those known good authors with upload rights for their own packages into exploitable vulnerabilities for all the software that depends on their libraries. So far, this has mostly looked like someone stealing creds and sneakily uploading compromised versions, if the situation persists it will eventually get worse with organized crime attacking and using rubber hose cryptoanalysis on devs. There is too much value hanging on too wobbly a foundation here, the situation is not stable and it needs to change.
The C++ standard library is terrible because it was designed from nothing with no actual real-world testing. IMHO the best path forwards for Rust is that when crates become established and "complete" with little further development needed, they should eventually be merged into some large conglomerated library with an actual organization behind it. This doesn't necessarily need to be the standard library that ships with the language. Yes, this would end up like Python, where eventually there would be 4 http clients in there with 3 of them deprecated, but that would still be better than the present state of affairs.
The C++ std lib is no longer terrible. It is really at a usable level these days. Not fun, but totally bearable. The motivation for C++ has never been the quality of the language or the std lib anyways, so it can happily chug along in many places (including the browser I am typing this on).
I disagree about merging existing "done" libraries into a mega library. That can work to some extent, but that approach will not produce something lasting (in the sense that it will remain without the need for changes for a long time). The way to achieve a lasting mega library is by putting all the pieces you need, and constantly working to increase the consistency between them. Somewhat like turning a long winded rambling into a much denser article.
Going from a set of good and working libraries to a large CONSISTENT library would be substantially laborious. Hence the need for someone with deep pockets to take it on. (There are other ways for that to happen but those are rarer).
It worked well for C++ during its first decade, each compiler had quite nice frameworks with kitchen sink approach.
It went out of favour since the 2000's, because of the raise of ecosystems like Java and .NET, followed by everyone with exception of Microsoft, going for other systems programming languages on their desktop and mobile OS platforms.
Also the consequence that we eventually got reduced to GCC, clang, and MSVC, and only one of them cares about frameworks. The other exception being C++ Builder, but that one is largely ignored outside big corporations.
C++ (the language) and its extreme complexities (each perhaps added for a good reason at the time, and then held together with backward compatibility as glue) reduced itself to gcc and clang. Not the std lib. The std lib is, de facto, removing some of the complexity.
Recent C++, together with a couple of major libraries, and with a good style guide and a matching lint (that removes / restricts many footguns) is far better than it was, 15-20 years ago. While it is not exactly cool, it can be totally bearable.
My point is the current success can be "copied over" to rust by cloning (or otherwise obtaining) a good base std lib, and a few domain specific comprehensive libraries. That doesn't even need to affect the existing ecosystem. There can be several parallel ecosystems and each one can be relatively thriving (one doing nodejs style YOLO, one doing enterprise extreme best-practices, one doing efficient embedded or OS level work, etc.). However, apart from the nodejs style community, the rest will benefit [heavily] from a base library that is well designed and NOT subject to change. Even a travesty such as a vibe-cloned golang std lib would be an improvement over the current situation.
> Recent C++, together with a couple of major libraries, and with a good style guide and a matching lint (that removes / restricts many footguns) is far better than it was, 15-20 years ago. While it is not exactly cool, it can be totally bearable.
Which is the main reason why despite its warts, C++ is my go to systems language, when I need to do something outside Java, C#, node. It is anyway for "unsafe stuff" for the most part.
Additionally being the systems language those runtimes rely on, and for stuff like GPGPU.
Always use static analysers and hardened runtime, it isn't Rust, but still so much better than C.
> My point is the current success can be "copied over" to rust by cloning (or otherwise obtaining) a good base std lib,
That I agree as well, it cannot be that for basic stuff like general purpose error handling, or handling macros, we need to rely on third party crates. Or that for all pratical purposes, tokio is the async runtime.
Honestly, at fundamental level, it is less of that need being dependent on third parties, and more of not having at least ONE set of consistent libraries (or one big library). To me the real value add of golang's std lib is not that it is developed by the language authored (that is maybe the third or fourth key point). The first one is the existence of one set (or 1.5, heh, if you consider golang.org/x slightly different) of libraries that are polished and hammered to be consistent together (primarily by spending an enormous effort on simplicity, but also on repeated polishes prior to the first notable public release and some thenafter). This is at the core of what I think rust needs right now to break through and penetrate into real C++ and golang circles.
That's just rust culture there is no changing it at this point. How many tools are new users exposed to in the first hour of the language? 'rustup -> rustc -> cargo -> random nonstandard crates, toml, git' (and then the optional rustfmt, language server, ide, clippy)
This kind of spam trains new users from the get to stop thinking about their tools. Is it necessary? Of course not, the language itself can be written with chalk and stone. The lowest tech solution naturally leads to the most comprehensible code that solves the problem, mo' tech mo' problems. We shouldn't train beginners to work on the ISS before they know how to hold a mop.
Go has this problem too, just to a slight lesser degree. The tools existing are debatably a problem, but them being pushed on beginners is certainly one. And just maybe the point of programming isn't to contribute to billion line corporate codebases.
Cloudtop to run builds, g4 commands, etc., and srcfs / srcfsn to actually write code. (caveat: I have never used neovim, so I don't know if that is different).
When using AI, I often find myself preferring either plain text (no markup whatsoever; just manual / text editor formatting of text blocks) or simple html to markdown, depending on the situation. To the point that I rarely see any point in using markdown for anything. If it is meant for to be a simple text mainly for human consumption, the markups often don't add much clarity (and often bring in an amateurish look, as if the author didn't know how to emphasize using English constructs), in which case plain text feels more pprofessional. If it is meant to be [lightly] processed before being presented to a human, or if it is meant to be processed by a tool / bot / LLM, then HTML is infinitely more straightforward.
Also I often call out my colleagues if they try to put a table in markdown. Markdown is not built for tabular data in most professional settings (i.e., one or two table cell could easily take a whole line of markdown to express). A basic <table><tr><td style="background: red">some number</td></tr></table> goes a long way.
I do get pleasure from typing out the code in some languages (and not in others; hello javascript, java!). Similarly, I love writing text with a calligraphy or fountain pen. However, I can't dedicate too of the much work / business time to whatever is more pleasurable.
So, I "doodle" some text / ideas / planning with a calligraphy pen, and type in some code, occasionally, both mainly for the fun aspects. There are side benefits to both, too. Writing some plans slowly and "beautifully" drags them out and I get to think longer on them, so the sporadic "nice looking plans" are often more well thought. And doing the coding all by myself stops my brain from losing the ability. I was initially in the 100% AI-writes-all-code camp for a while and noticed I am getting notably slow in some personal coding skills. It is too early to treat specs as the new code and old languages as assembly (but I admit we might get there some day).
In other words, I think AI doing 90-99% of the coding, depending on the language verbosity and AI accuracy for the code at hand, is quite reasonable.
Personally, this is an experience I thought about first before writing my comment. I think in the days pre-AI coding assists, I believe you describe the intrinsically human experience that's requisite to write code by hand. The wonder, the joy, the frustration, the confusion, the elation--the discovery. These days, the things I wonder about lie deeper and deeper behind more and more lines of code, through journey's that provide less and less joy, and thusly becoming more and more unreachable as I'm human, bound by an excess of things in addition to time. AI has helped me rediscover some of this sporadic creativity demonstrably due its ability to prototype recreational ideas on a whim
Professionally, I'm employed writing safety-critical avionics software. Superfluous amounts of cogent tooling putting guardrails on agents has enabled me to spend heaps more time to think deeply about how the software should work at a systemic level. The code by definition must be heavily criticized and battle-tested before it can go out the door to begin with. Albeit a beautiful part of coding, those sporadic bursts of creativity drive the code leaving my desk less and less, and I feel strongly that has made its quality paradoxically better since I'd spent much more time on broader implications and interactions.
This might have been the case a couple of years ago, but it is certainly not true any more, if you use AI [even occasionally] to manage some of your default.nix and flake.nix files. I learn by getting AI to edit it (default.nix for example), and then study what it did. It helps.
The quality of the managed / packages software, however, is still a bit subpar compared to Debian and Redhat.
Why would you use that feature? MacOS doesn't REALLY have multiple desktops (Spaces). That is merely a pre-release feature (for 10 years or so, I think). As evidenced by the many critical user journey bugs it has that don't get addressed.
I use both linux (with a decent tiling window manager; the tiling management being the least important part of it) and macos. And certain things are just not possible to do with macos. On linux I can have 300+ open terminal windows AND CAN find the one I need when I need to. On macos 20 (counting in Termianl tabs, which are implemented as windows, underneath) is about the high mark that it gets annoying to work on. On macos, you can't effectively work on multiple projects that use the same software (editor + terminal, for example). You can work with different Applications, though, and that is managed pretty well (better than most linux window managers that I have seen).
Every year or so I try adding a couple of Spaces, and always regret it a couple of hours later, switching back to a single Space (+ a few fullscreen apps).
I've used spaces since 2013, they work well enough. The animation bug is annoying though. On displays higher than 60Hz, the animation is slower because they made it frame-based instead of time-based, or something silly like that.
I love the three finger gesture to move between them though, it's like moving pieces of paper around. You can also work around the bug I mentioned by swiping faster, but yeah I wish they'd just fix it so we can move on.
Of course it can be used. But it is very buggy (as in missing or not well-though-out behaviors), which is unlike the typical polish Apple human interaction folks deliver. For example switching between Spaces and then between apps and windows and creating a new app window don't work as expected in some combination of steps and for some apps. There are several other "corner" cases that show the features were not laid out in a full design to exhaustively decide the desired behavior in each case. Which is very much like when someone bolts on a feature to a system without fully nail down its interaction with all other adjacent and relevant features.
I'm just responding to your "Why would you use that feature?" question. I use it because I like it, and it works well for me. I'm not disagreeing that they have some bugs and design issues to work out. It seems pretty obvious MacOS doesn't get as much attention as iOS when it comes to these things.
Spaces help me visually organize related apps. I have all my chat apps in one, all my dev stuff in another.
I used to run Linux with i3 tiling window manager, but switched to Mac because the battery is so much better. Although the new Framework laptop looks like it has pretty great battery life.
Nix is not the same as nixos, and in this case the distinction matters. It has to step carefully around Apple's updates. This further highlights the fact Apple lacks the same quality package management as some linux distros. Nixpkgs (on macos), Ports, and Homebrew packages are toys compared to the EFFORT that goes into maintaining Debian and Redhat packages.
In terms of package management SOFTWARE, however, nix (and guix, lix, etc.) are state of the art and work fairly similar in both linux and macos. A deeper integration with the OS would have been nice.
Package managers are wonderful until you step near our outside of the packaged software - then you better hope you're on a big distro otherwise you may be in uncharted territory.
The current market share shows how far you can go with just being a better Java.
If (or when? I haven't checked recently) a decent and well-thought-out LLVM backend emerges for it, ideally with some new underlying complexity seeping through, the market share might expand overnight.
And as for C++, while some complexity is certainly unavoidable, a rigorous complexity control is desperately needed. Ideally, the same way Bell Labs folks did when they initially conceived Go from Algol68 and C and similar (before or after joining Google; I couldn't tell), and Rich Hickey did when he initially designed Clojure. Some people are managing the complexity using style guides and clang-tidy checks. Which is great in that doing so doesn't need lengthy language committee decisions. But that approach hasn't been enough to make code _sufficiently_ safe; every now and then an enterprising engineer or team finds a way to abuse a feature in a way that produces unsafe or unpredictable results. Rust is a bit better and solves a few of the common problems, but sadly the list of potential issues (of using Rust in a codebase at scale; Engineers' faults, not Rust's) is long and growing. My verdict is we need both complex and simple LLVM languages, ideally co-designed to have no interop problems by design, while allowing expressing some logic in the simple parts and some logic in the complex parts. Or better, a 3 tier design would be nearly perfect: expressive config language, glue and research language, and core building blocks language. I think a clojure-style language can be designed to achieve all three.
"I Want to Wash My Car. The Car Wash Is 50 Meters Away. Should I Walk or Drive?"
I found it curious to ask the model to provide its reasoning in that turn, without changing the verdict. Here is one response:
To provide the full picture of the initial reasoning, we have to address the "geospatial" logic of your request. When you asked if you should walk or drive to a car wash 50 meters away, the reasoning relied on a fundamental distinction: The difference between the "Car Wash" (the business) and "Washing the Car" (the action).
Here is the expanded breakdown of that logic:
1. The Location Assumption
My reasoning assumed that the car is currently at your home and the professional car wash facility is 50 meters away.
If you drive: You are moving the "object to be cleaned" to the "cleaning tools."
If you walk: You are moving the "cleaner" (you) to the "cleaning tools" to prepare, or you are choosing to bring the "cleaning tools" to the car.
2. The "Walk to Wash" Strategy (Home-Based)
The most significant expansion of the "Walk" recommendation is the realization that 50 meters is well within the range of a standard garden hose. Most heavy-duty garden hoses are 15, 25, or 30 meters long. By connecting two hoses, you can reach the car without ever starting the engine. Walking to the car wash facility to buy supplies (or simply realizing how close it is) highlights that you don't actually need to move the car to achieve the goal.
Zero-Motion Cleaning: By walking back and forth with your buckets or hose, the car stays in its spot. You avoid "flash rusting" your brake rotors, which happens almost instantly when you wash a car and then let it sit after a short drive.
3. The "Scout and Prep" Logic
If you must use the equipment at the facility (like a high-pressure wand or an automated bay), walking there first is the superior "Logistics" move for the following reasons:
Queue Management: 50 meters is close enough to see the line, but walking allows you to talk to the attendant or check the bay's status. If you drive and there is a 20-minute wait, you are stuck idling your engine (wasting gas and creating heat) or turning it off and on (draining the battery). Walking allows you to timed your "driving" moment perfectly.
The "Dry Interior" Principle: If you walk to the wash to buy your tokens, prep the vacuum, or set up your towels, you are doing the "dirty work" while the car is safely tucked away. Once you finally drive the 50 meters, you do the wash and drive back. This minimizes the time the car spends in a high-moisture, high-chemical environment.
4. The Potential for "Mobile" Service
By walking 50 meters to the car wash, you might find that they offer mobile detailing or have "loaner" equipment. In a high-density area, a car wash 50 meters away is practically your neighbor. Walking over to establish a rapport can often lead to a "valet" situation where they come to you, which is the ultimate way to get the car washed without ever sitting in the driver's seat.
----
also noticed a typo and asked it about that:
> what does "timed" in `Walking allows you to timed your driving" moment perfectly.` mean?
That is a typo on my part—it should have been "time" (the verb).
reply