Drawers were a big feature of early MacOS X, as an alternative to NEXT's multiple columns. App's inherited from NEXT (email, finder, etc.) used columns still, but newer apps used drawers.
It was really well integrated, if the window was too close to the edge, the window would move as the drawer opened in a single smooth animation.
XCode in particular had drawers everywhere.
As iTunes became successful, and everything wanted to be brushed metal, drawers began to disappear in favour of columns.
The core language has been static for ages, and breaking changes are handled by the edition system so you can use a modern compiler to build code on old syntax. Since the 1.0 release ten years ago there have been four editions.
It's absolutely not changing too fast
> depends on third party libraries that change faster than I can breath
No it doesn't. The standard library is already sufficient for a lot of work; and there is an unhosted version with a "core" version of that standard library which has zero dependencies.
Modern Rust, Java, Python, TypeScript etc. developers choose to use a lot of third party libraries; but that's only because the tooling and ecosystem are both good enough to facilitate that. Nothing about the language forces it.
Not sure if you mean proof of changing too fast …or not fast enough?
Linux has a wishlist of features they want for kernel development, and Rust has been working towards adding them.
Here's the paradox: Rust is very careful about compatibility and stability, the stable releases are changing slowly. But the Rust for Linux project wants to use the newly prototyped features right away, so they depend on not-yet-released features from unstable nightly versions of Rust.
> the Rust for Linux project wants to use the newly prototyped features right away
> they depend on not-yet-released features from unstable nightly versions of Rust
This is not true. Since kernel 6.11 they have specified a minimum version that is already stable. The strategy for the Rust kernel is to use the version of Rust that ships with Debian Stable. That is very far from using "the newly prototyped features right away".
Rust For Linux has a hard dependency on unfinished Rust features that were not released as stable in the Rust version that Debian has.
However, every build of rustc also needs to be able to build its own standard library and a future version of itself. To do this, rustc recognizes a special private env var that exposes compiler-internal language extensions and not-yet-stabilized features meant for the compiler itself, and not for end users.
Rust for Linux relies on using this private env var to bypass feature stability checks and trick the "stable" compiler from Debian into allowing use of compiler-private and experimental features that were suppressed to stay disabled.
RfL uses an old Rust binary from Debian, but still depends on experimental features that haven't officially shipped yet in any Rust version.
> Most managers are no longer technical, and just create bloated middle layers that slow everyone else down.
> The only managers that are decent are the ones that have kept their technical skills sharp.
Alex Ferguson was a terrible footballer when he was managing Manchester United. Yet they won the premiership in 6 of his last 10 years in that role, and have never won it since he left.
The skills that make one great at doing work on ones own aren't necessarily the skills that make a _team_ of 3, 6, 12 people all collaborate with one another, and with the other teams within the company.
Good management is rare, due to the tendency to promote engineers into the role instead of hiring people specifically trained in that discipline, but when you're in a well-managed -- and hence highly focused -- team the results you can all obtain together can be impressive.
He still had a decent player career, and anyhow, this is a completely different field. The issue is that good engineers are not promoted to management positions because their skills are needed or they don't want to get promoted because of politics. But one of the things that I noticed a lot is people "specifically trained" to be managers. Our company is full of project managers and POs that never built anything their entire life, they never led a team, they never did anything except start with something like an assistant or QA and then all of the sudden they want to manage people. This is what I find frustrating, people that never in their life did something productive or build or contribute to something, but their expectation is to be a manager, just because they were "specifically trained in that discipline"
A good manager understands the tech and what it takes to implement it on a high level, at least enough to not get BS'd.
This instinct can be developed due to direct experience as an engineer, but it can also be due to experience as a product manager or something else, as long as they have some curiosity to actually learn the big picture stuff.
Now with AI chatbots there's little excuse for a manager to be completely clueless about this stuff, but still there are a class of these people who just can't be bothered to care about anything other than moving units of work around boards.
Not a great example. Football doesn’t change much. You don’t need to actively play football to know how to lead a football team well.
Tech is very different… given the pace of change you quickly no longer have any clue what’s happening unless stay technical. Imagine being dropped in to manage an AI team in 2026 when you have no experience with LLMs and the last time you coded was Pascal. 1) Teams some respect you, and 2) You’ll have no clue what you’re doing. And yet there are tons of “tech leaders” that fit this profile.
Was in a company that didn't promote engineers (never saw this happen), only hired managers externally. Resulted in a management layer clueless about the work and product.
Good management is rare partly because nobody wants to take risks and hire inexperienced management.
This leads to a reluctance to promote people without previous experience into management roles. This in turn leads to a shortage of experienced managers.
Good management is rare because it's the wrong people doing it. The bigger problem is that we're all always told that we need "professional" management, implicitly people who's been to "management" schools, this dissuades promoting from within (that honestly can be equally disastrous).
The upside of people from within is that they know what the bottom line comes from, there's been some highlighting of the effects in terms of the founder-mode discussions.
Not all good footballers are great managers but many great managers were good footballers. Playing in the first or second division is already good in my books.
Telegram isn't even encrypted, at least not in the sense of the on-by-default end-to-end encryption used by WhatsApp, iMessage and Signal. In reality its selling point is that your chat records are placed in foreign jurisdictions so your local police can't easily access them.
Ultimately the only way to be completely sure is to use an open-source app like Signal that you've either built yourself from source you've inspected; or sourced pre-built from someone you trust.
Yeah, Swift looks like someone started trying to port a C# syntax onto an esoteric object-orientated C-dialect (similar to Vala and GObject) then at the last moment noticed Rust 1.0 had been released, tried to patch on some Rust features, and hit release before they were done.
It's quite deceptive. Rust seems initially hard to learn, but it's a small language, so you arrive at competency faster than you might think. Swift seems initially easy to learn, but is a broad language with lots of edge-cases, so you're never quite as competent as you think you are, or need to be
Ehh I have been using Swift from the beginning and I disagree with you and the parent. Swift was "good" before the addition of property wrappers and the result builder syntax. That's when lots of the weird "features" started being bolted on.
Before that it just felt like what a modern OO language with reference and value types, type safety, some very light "not truly functional but nice to have" functional programming features, and readable, "normal", dot syntax would be like. The language was basically complete at that point for the purposes of writing UI apps with the existing Apple frameworks.
In this particular case I believe the mountain is largely karst (limestone) and the panels substantially reduced erosion -- particularly of soil -- leading to an increase in fauna that thrive in the shade.
As others have said, it's hardly waste, it's an installation with a 30-year lifespan.
It was really well integrated, if the window was too close to the edge, the window would move as the drawer opened in a single smooth animation.
XCode in particular had drawers everywhere.
As iTunes became successful, and everything wanted to be brushed metal, drawers began to disappear in favour of columns.
It's quite hard on the modern internet to find images of that old UI, but here's Preview with its right-hand-side drawer: https://mac.elated.com/2007/05/09/displaying-images-in-the-r...
reply