Unless a Rust OS is created with an official toolkit, Rust apps will always exist on a platform that already has a native toolkit. Any custom framework will always feel wrong and out of place.
I use macOS, so apps should be written with AppKit. For Linux they should either be GTK or Qt, depending on desktop. Recreating widgets from scratch with GPU rendering is doomed to feel wrong to users.
> Recreating widgets from scratch with GPU rendering is doomed to feel wrong to users.
So following your argument, pretty much all apps I use on macOS are 'wrong' as far as GUI goes.
Off the top of my head from what I use most of the time: Maya, Houdini, Blender, Fusion360, Resolve, Darktable, Slack, Discord, VSCode.
Not a single one of them uses native Cocoa widgets. And I couldn't care less.
Some of these are top of the line apps for 2D/3D content creation on that platform.
If the vendors of these apps can afford to not care about UI nativeness, why should any single one or small group of developers working their asses off on GUI crates for Rust? Mostly unpaid no less.
> Not a single one of them uses native Cocoa widgets. And I couldn't care less.
Meanwhile I do care. My main reason being: macOS offers fantastic facilities for inspecting and scripting the native GUIs, think using the web inspector or GreaseMonkey, but across the entire OS - but of course it breaks e.g. on Electron apps. Other people will cite help menu integration, custom key shortcuts, accessibility (not only for the disabled), and - yes, resource usage. I remember being productive on a system with 256M of RAM, and before that - 4M, and before that - 64k. It's frustrating to see so much progress wasted, I shouldn't need to close ALL of the chat apps just to run StableDiffusion more smoothly.
Maybe Apple should write libraries for their GUI toolkits, then. It's awfully hard to beg people to write native apps for you when people need to learn a new language to do it.
That's more-or-less what I'm getting at. Apple can't replace Objective-C with Swift and expect people to not cock their head. They can either support a pre-existing language (like Microsoft with Rust) or home-bake something suitable for low-level development. Telling developers to not use the stuff they want to use sorta leaves their hands tied.
Microsoft's Rust support is basically non-existing for GUI applications, Rust/WinRT is miles away from achiving C++/WinRT parity, even more so with C#.
In its current state is only useful for CLI or services, unless you feel like doing WinUI team's work for free.
My main counter argument would be that most of the tasks I do on macOS require/are better done full screen.
And if you are on macOS doing any kind of design work, this is your mode of working. People using Photoshop or any 2D/3D DCC etc. You use all the screen space real estate on any number of screens you have.
But even if I write code I run VSCode in full screen. If I have a dual screen setup I usually have one screen with two code editors, mini map & folders + terminal on screen two. But that's it.
But even assuming you run apps side by side/stacked whatever so you could actually visually see how non-native/different they look. Is that the real issue on macOS today? Personally the main gripe I have is that -- and kindly pardon the tangent --
macOS native window management is shite.
One of the first things people that come from a *nix desktop buy/install, when they switch to macOS, is a proper (possibly tiling) window manager.
But back to widgets/look: in DCC apps the main sort of dialog you interact with are attribute editors where you change properties of an object or node.
I like to refer to an issue on the egui crate which has some of the best out-of-the-box support for this kind of widget composition[1].
Apple Human Interface (AHI) guidelines do not have any handrails on how these attribute editors should look or be done.
The best you can do is go with dialog AHI guidelines and these fall short for this sort of window.
I can go into great detail here why but it's beside the point. If you read my comment on the egui issue I linked above (same handle I use on HN) you may get an idea where I am coming from.
Most Human Computer Interface (HCI) guidlines for various platforms are based on typical late 90's early 2k desktop apps.
They were never updated to reflect on newer paradigmns for UX that evolved in recent years. Blame the fragmentation of the desktop and Electron & co.
IMHO this is the first problem the OS vendors need to solve before we can blame developers of UI libs to not make them look 'native enough'.
I should probably have said patterns, not paradignms but this beside the point.
I mean stuff that is common enough to deserve a defintion and a best practice laid out in a human computer interface (HCI) guideline document for a platform/OS.
Off the top of my head:
Tab closing behaviour on Chrome/FF. Close a tab, other tabs shift but don't change size immediately so you the next tab's close button is directly under the mouse and can bel clicked to close another tab (and another, and ...).
Another one: the typical chat app with servers/groups/contacts on a list on the left and the chat on the right (and possibly threads on the far right).
There is no good standard for this, everyone cooks their own soup so stuff you learned for Slack doesn't apply in Discord etc. I.e. it's a pattern of some sort but there are no Windows/macOS/Qt/GTK interface guidelines covering this case and/or suggesting best practices.
This includes e.g. platform standard keybindings to select stuff in such apps (at best Tab switching works).
Another one is use of (some) Markdown-inspired stuff in chat apps. I.e. `monospaced` ```monospaced multline``` or even ```<language for syntax highlighting> ...```.
In Slack ``` works but ```<lang> doesn not (but does in Discord, used to work in Slack in the past, I think).
I think there are many such patterns that are maybe not as groundbreaking than the invention of tabs (90's?), combo boxes/menus (also 90's? When there are too many choices for radio buttons) etc.
But beause they are used in some form (or another, unfortunately) by many apps now, the OS vendors should define a best practice for implementing their end-user facing functionality/behavior in their HCI guidelines.
Even if the platform itself doesn't provide a ready-made widget for each such case.
It seems to me Mac users care about using native UI toolkits more so than Linux or even Windows users. I would suppose that has to do with how polished and integrated that platform is.
As a Linux user I really don't care if you use GTK for the UI. I've long given up on customizing the look and feel of my system to the point that application integration matter.
For many decades, there have existed commercial apps native to the Apple ecosystem, often from small/mid-sized studios, which would use native UI to signal their premium craftsmanship. I think that for many long-time Mac users, seamless/native UI is still a signal of quality in third-party software. However, this sentiment is moribund. That entire market is now dwarfed by the ecosystem of “cross-platform apps” (formerly Windows ports, now usually web apps) and Unixy OSS tools; all the while the Mac App Store now peddles lots of native-UI apps of deeply questionable quality.
long ago, the integrated feeling of Apple MacOS was a great selling point; decades later, daily use of the web, more phone than desktop, Windows low-bar junk and other factors change the equation.
If a smart user here today says that recent network-centric apps are OK with him visually, then maybe they are OK?
I think Apple made a strategic error when they failed to embrace DOM/browser engine-based toolkits like Electron on the Mac. If they had applied their leverage, of which they have plenty, the technical challenges of better native integration and support for the wide range of traditional Mac affordances would seem to have been quite manageable.
There's some reason to your proposition. Directly integrating/"embracing" foreign toolkits/web engines is the last thing Apple would ever do, but exposing more of the underlying machinery to allow third parties to integrate better - yeah, sounds good.
On the topic of Rust GUIs on Mac, this was recently in the news:
This. It’s so lame when UI elements can’t hang outside the bounds of the window (i.e. menus, tooltips, dropdowns, popovers) because everything is rendered like a game…
There's no reason Rust toolkits can't use separate windows for elements like menus and tooltips, and I know this is planned for at least some of the toolkits discussed in the post.
The problem right now the separation of concerns for GUIs is a complete shitshow on ALL platforms.
Even such "simple" tasks as how to composite a window, a video in that window, and a floating menu over that window are not very well specified in any OS (try resizing that window and watch the fun). Or, for example, your floating menu--should the parent window resize itself and paint with transparent pixels in the extra area or should that menu be a separate "window"? And, what does being a "window" even mean?
Add into that the fact that we really should be making multithreaded GUI systems at this point and it's very clear that GUIs are stuck in a local minimum that's really hard to get out of because GUI systems require so many lines of code.
Window resizing works perfectly fine on macOS if you use the native AppKit framework. It’s only when you try to embed a whole different world (Qt, GTK, Flutter, Electron) in your window via an opaque OpenGL/Metal surface that things break/lag/distort on resizing the window, which again is another reason to stay away from these cross-platform GUI shims.
I don’t really see the reason for multithreaded UIs either. A single UI thread works perfectly fine if you move your business logic off to a separate thread. Most people are just too lazy to do that, and start developing their app with the business logic running synchronously on the UI thread; which works for a while, but eventually reaches a point where it starts blocking the UI event loop; then they try bandaging it by moving certain pieces to a background thread and they shoot themselves in the foot with thread-safety issues. The way to solve this is not by making the UI framework multi-threaded… Simply be disciplined with UI ↔ business logic separation from the get go and all these problems go away. Yes, I know it’s so tempting to call the database directly from the button click handler - but don’t do it.
The only cross platform toolkit that pulls it off well is Java. IntelliJ feels good on every platform. Qt apps can also feel native if a little effort is put into it. Rust GUI frameworks are one of its weaker areas IMO.
The next time you use a Swing app, look for these examples of how it "pulls it off well":
* The first time any particular window is opened, Swing draws the contents but then changes its mind about the window size, recalculates the layout and then redraws the contents again slightly differently.
* When Swing creates a window, you can sometimes observe how creates it in the wrong spot and then moves it to where it was supposed to be created.
* Alt-tabbing quickly between two windows in a Swing application doesn't always work. It sometimes just glitches and leaves you in the window you started with. (Confirmed just now on Windows 10 with Java 17. The bug has been there for many, many years.)
* When opening a submenu of a menu, Swing does nothing to handle the problem of the menu closing again as you're moving towards it but accidentally mouse over an adjacent item. Platform GUI toolkits solve this either with a delay or by tracking the direction of the movement. IntelliJ implements its own menu bar to make this work.
* Try to find an example of a window that is resizable in only one direction or only up to a certain maximum size. As far as I can tell, this is not possible in Swing, and applications handle this limitation by designing all UIs to be resizable even when it doesn't make any sense.
I have never had anything other than a terrible experience with a Java app, under Windows, Linux (in GNOME 2 and Unity most of a decade ago, i3, or Sway). They always disregard platform conventions in both look and feel to a painful extent. But I will declare that I haven’t ever used IntelliJ, and I have no idea what it uses for its UI. But out of the box, Qt seems vastly better at matching platform look and feel, and generally gives you decent control over matching or not to match your requirements.
It looks mostly ok, but on Linux it doesn’t support smooth scrolling (even though this is supported by gtk). You also can’t use the meta key (windows key / cmd) as a modifier key for keyboard shortcuts. So I can’t configure intellij to use all the keyboard bindings I’m used to from macos. Again, this isn’t a problem with other gtk apps. It’s just (apparently) a platform limitation of whatever Java toolkit they’re using.
So in my experience it’s 95% of the way there. I certainly prefer it over Xcode, but it has issues that native apps don’t have.
First of all, up-to-date official packages are now published to Maven Central as part of the release process, so you can just add it as a dependency as easily as with any other library. Until recently you would have had to either fiddle around with Eclipse's alternative package management system, download it manually or use someone's unofficial Maven artifact. But that's now resolved.
Secondly, if you bundle a Java runtime customized with jlink (as is recommended these days), an SWT application is actually smaller than a Swing application. When you don't use Swing, you can exclude the entire "java.desktop" module, which is slightly larger than the SWT libraries.
Regarding Java I think that's more of a Jetbrains thing that IntelliJ feels good on every platform than Java per se. Contrast it with Netbeans for a more "pure" Java desktop experience.
I've been an JetBrains (IntelliJ and these days CLion) user since about 2004 and what I'd say is this was a hard fought and slow incremental advancement. Back in the 00s, IDEA's UI experience was really sub-par and its foreign nature on the platform was very very clear.
It's amazing the amount of work JetBrains has put into this.
It’s mostly an IntelliJ thing. All other Java apps are ugly and weird.
And there are non-native behaviors in IntelliJ too. For example you can’t close windows by double-clicking the window icon on Windows (a feature of Windows since Windows 1?).
> Unless a Rust OS is created with an official toolkit, Rust apps will always exist on a platform that already has a native toolkit.
If the toolkit is good enough it's entirely possible that a platform or platforms may adopt it as their native toolkit. In any case, these are really competing with electron which is already non-native. If Rust toolkits can get to electron-like quality but with lower resource usage and better hooks into the underlying platform then I'd consider that a success.
Can you provide any source/documentation on how to achieve this?
As far as I know Electron is based on Chromium. And Chromium doesn't use native controls, it has its own custom controls that sometimes look similar to native controls.
Depends. Highly specialized apps (Blender comes to mind) fare better using custom toolkits. Anything else probably should use the platform-native one, not only for looks (lots of really great mac-only apps use customized widgets, see Things as example), but feel and integration as well.
I feel like it's a spectrum. The simpler the app, the more likely it's better to try an integrate with a closer to native look. I always found the issue of "native" to be a bit funny to me as someone coming from the 3D/VFX space, since all of the applications are built to be multiplatform and don't give a hoot about "native". Consistency of the application experience across platforms trumps all. The number of people I've seen complain about this? Zero. Usually the only issues arise around file pickers (some have custom ones, others use platform ones which have differences).
Granted these applications boast a ridiculous amount of features and are incredibly complex putting them on the opposite end of the spectrum compared to simple GUIs and chat/productivity applications.
To me, it's nice that platforms provide native toolkits* to provide this level of integration. But I don't view any app as "native" unless it comes from the party making the platform, as they are really the only ones that actually have to adhere to their human interface guidelines to the fullest extent.
* On Linux this is more up-in-the-air. I personally don't consider GTK and Qt as native toolkits, but the foundational pairing for things like libadwaita and KDE Frameworks which provide the associated platform widgets and HIG. Using the toolkits directly is fine and will mostly work, but it's not the same as a "native" application.
This was my experience as well. Simple windows with a button that increments a number are nice and understandable but if you try to get more complex controls working, you run into docs.
With C code often being unreadable, I found that Vala applications often have readable examples of how to use UI components. However, tooling support for Vala is extremely limited so experimenting with existing code may be a annoying. That said, I've had good experiences with opening these projects in Gnome Builder (once it got updated to work on my computer again).
If your component of choice doesn't have a Vala example, I'd resort to reading the documentation. Reverse engineering the API from the docs is often quite doable if you first look at how a component you do understand.
I've had similar problems, but worse, when I tried mixing Rust and Qt. I've never used Qt before so that doesn't help, but I found the API even less predictable in many cases, with some docs and examples several versions out of date.
I'd seriously consider just shipping a WINE'd Windows binary (using a tool like https://winepak.github.io/) for Linux targets with the current state of Rust GUI platforms. The amount of game UI/custom UI libraries out there is impressive but they all feel terribly wrong when I try to use them, in the same way most Flutter apps are terrible to use on desktop.
> Any custom framework will always feel wrong and out of place
Pretty sure that's the wrong metric. Users don't care if the interface doesn't look exactly like the rest as long as it's good looking and feels familiar.
As a heavy VSCode user for example, I don't think it feels out of place on a mac for example. The UI is consistent in itself, and the UX is consistent with the global UX of the OS (more so than some native mac apps like Finder for instance).
The main reason I hated Java Swing apps was that they were ugly as hell, not that they didn't feel native.
I'm the author of cacao, which is the first thing in this blog post - and is a Rust wrapper around native AppKit. Anything built with it feels fine on macOS and gets most things "for free", but the issue is that nobody wants to write AppKit anymore. ;P
You can blame a variety of things for this, but it's the reality. Apple doesn't really make it easier with the newer UI approaches creeping in.
>For Linux they should either be GTK or Qt, "depending on desktop"
That's bad... ideally there should be a runtime choice between GTK / Qt.
side note... I know many people that would prefer apps on MacOS to behave like Windows/Linux (mostly about the keyboard)... and also the reverse (those are louder to complain, but a minority in my case).
I think, now in 2022 it is time to let go of this idea (for cross-platform applications). What you propose means that any app that wants to be available on "all" desktop platforms has to be written at least 4 times (macOS, Windows, GTK, Qt) and few developers or organizations have the resources for that.
> Recreating widgets from scratch with GPU rendering is doomed to feel wrong to users.
Yes, and no. When these widgets try to mimic platform-native widgets we have the uncanny valley problem which makes everything feel out of place like you describe. But if we drop this constraint and design widgets with their own consistent style within the same app, we don't have this problem. Apps like the JetBrains IDE's and Todoist show that this can be done.
To me the middle-ground solution is a UI toolkit with its own widget style, that has some tie-in with platform-native things and conventions like windows, menus, notification trays and keyboard shortcuts. Essentially GTK or Qt without the focus on pixel-perfect matching of platform-widgets. I think this is what Druid is doing. Rust is in a good place for this as it is a modern language that works well on all of these platforms, with no native UI toolkit yet and a package-manager/build-system that supports multi-platform library configuration.
There will always be a place for platform-native apps but cross-platform apps have different requirements. I don't care that my todo list application or IDE does not look exactly "native" on my Macbook. However I do care that these applications look and feel similar when I use them on my Macbook vs on my Linux machines or Windows laptop. Preferably without dragging in a full web-based rendering engine a la Electron.
> But if we drop this constraint and design widgets with their own consistent style within the same app
Style is just one of many things. And it's extremely hard to properly code your own consistent UI toolkit.
On top of that every platform has a myriad of platform-specific behaviors that people expect and that you will get wrong in yours. Accessibility is the big elephant in the room. But even things like secondary focus in prompts/dialogs on MacOS (that Apple's own Catalyst and Swift forget about) is a bitch and a half to get right.
I agree, which is why I'm not advocating writing or designing your own toolkit. Instead we as a developer community should focus on the "next generation" of toolkits for the modern cross-platform world. Take all that we have learned from GTK, Qt, Flutter and all the web stuff and incorporate it into something new for the next 10-20 years.
Rust is a nice language for that since it is already a "next-generation" language in terms of memory safety and its momentum is still building. Projects like Druid, while far from ready, are a good starting point.
The problem with this is unless you drag in something like Electron, you're inevitably going to end up using (or writing) something that just doesn't have the number of maintainers and quality development as either the native UI or an embedded webview. There's nothing with the level of development of e.g. Qt for Rust.
Which means "unsexy" things like accessibility get left by the wayside. And your users suffer.
Writing a UI kit is a huge task. It's one of those things (like so much else in our industry) where you can fairly quickly climb "stupid mountain" by getting a pile of shiny widgets on the screen; but then you look out over the valley below and realize that, holy, crap there's a whole other mountain range of things that a UI kit has to do.
It's also a tough story for Rust, in particular, because copying what other people have done with other toolkits won't really cut it. Rust's ownership semantics and general opinions don't necessarily accord well with the highly object oriented and event-loop / object-tree structure of most existing GUI toolkits.
Aside: I still don't understand why things like Electron based apps are so bloated. They seem to static link whole chunks of their own (forked) Chromium. But both Windows and Mac OS ship native webview components as part of their system which can be used instead. I've done this myself (used Edge's Chromium webview component in a VST synthesizer, and equiv webkit stuff on Mac) and binary sizes were entirely reasonable. Linux was a slightly more complicated story.
It's a tough story indeed, but every existing toolkit had to start from scratch at some point. If I'm not mistaken Druid had its start in 2017 (I personally contributed some stuff on the GTK bits around 2019) and it is far from ready but I see it progressing in the right direction. Accessibility is on its roadmap as well I believe.
This is why Rusts' "Are we GUI yet?" and posts like this are a good thing. Eventually some new toolkit will arise that ticks all the boxes. We are not there yet and it will require a huge amount of work.
-> Nurses don't get paid enough, and should be paid like tech workers for the work they do
-> Demographics changes means there simply aren't enough bodies to become nurses. This is especially true in the west now. Ontario in Canada is facing the same problem[1].
> Demographics changes means there simply aren't enough bodies to become nurses.
True. This is a direct consequence of people refusing to have kids. What may be a sensible decision at an individual level is going to have disastrous consequences for societies; particularly the advanced homogeneous ones who have the unique combination of falling birthrates, generous welfare programs which need taxpayers and who are averse to immigrants from a very different culture.
Countries like USA should fare relatively better since it is easy to assimilate young people from any other country. My prediction is that small nation states in Western/Northern Europe will be the first ones to break.
Canada is a terrible example. Like 90% of applicants who try to get into nursing school are rejected... Plus wages should be higher. Plus the work kind of sucks. It's a crisis that's *entirely* our governments' doing.
Indeed. This problem was foreseen years ago, and the fix is easy. Increase seats in schools, pay more, provide better hours. It's not rocket science. The resistance comes from just not wanting to do any of things because its expensive.
So what your saying is that instead of paying more we should import cheap labor at the expense of anyone who might be a nurse locally? Therefore depressing all wages across the board?..
That is not how I read it. I understood if you only have X people licensed as nurses you cannot hire X+Y people to be nurses where Y is greater than zero, even if you increase wages for all nurses.
I think the idea is that if you pay more, people will switch careers and become nurses. This isn't a great argument when it takes years to make a nurse, but you could at least get some people out of retirement or to afford childcare and come back to work.
This also includes people that went through schools in Finland and would be paid the same money as a native.
There just a massive issue with our immigration service running out of capacity to handle applications in a timely manner and some stupid laws that need changing/updates.
Basically applications for a work permit can take somewhere between 3 to 9 months currently. A lot of people can't live that long in the country without a job so they will just go to some other EU/EEA country. Norway is a very popular option for example and will give you a yes or no decision in a week or two instead of half a year.
You seem to think there's a solution that doesn't get implemented at someone's expense.
You may import cheap labor at the expense of local nurses.
Or you may import expensive labor at the expense of the foreign patients and local taxpayers.
Or you may do nothing at the expense of local patients.
The harsh reality is that there's not enough people being allowed to fill the jobs, and you can't create them without changing something - your policies or your standards.
Don't forget that every healthcare practitioner the West imports - I'm sorry "encourages to immigrate" - they remove a healthcare practitioner from a country that educated them, trained them, invested in their residence/practicum/rotations, and almost certainly needs them more than the West.
After all, why grow your own capacity to train and retain health care practitioners, when you can just take the non-Western world's instead?
Just say every productive young person. West has decided to not have babies of its own and instead just import them from poorer parts of the world. As an immigrant myself, I'd say it is a good deal for the West and those immigrants, but will need homogeneous cultures to be open to cultural changes.
This. It's the same in a country where I live in which has a sociliazed health care.
Nurses and young doctors are paid like shit so they're obviously all quitting and those that remain get so much more workload they they eventually also quit.
And then the ministers/politicians complain that "the doctors and nurses have no right to protest again" lol.
You can either have well paid healthcare personal or socialized health care you can't have both, specially when population is shrinking which is why healthcare across Europe (and Canada) are having the same issues.
Of course, even in the US where we pay twice as much for healthcare for the same outcome compared to CA and EU, doctors and nurses are in short supply. Seems like something else may be going on.
No, but while offering more pay might bring back nurses who have left for other careers, it will not bring new nurses on quickly as training takes a lot of time.
Governments don't have unlimited money and hospitals aren't run to make profit which could translate into wage rising (or not). There is a reason people who want to make bank are in the private sector (In my country doctors can work both, so they make bank in the private side)
For governments ro invest more in nurse/doctor wage with a decreasing population they would need to collect more taxis (or implement copay), none are popular among the voting people.
Another reasons is that healthcare is run by policians and mostly don't know how to run things without it being at a loss.
(1) Governments don't need unlimited money, just to allocate what they have better
(2) For-profit hospitals don't pay better wages because they are for-profit. They exist for the owners/stock-holders, not the employees, who are viewed as 'human capital', not partners. There is no reason a for-profit hospital would pay its workers any more than any other, and many reasons why it would pay less
(3) People who want to 'make bank' are not nurses -- they just want to be paid fairly for the work they do, and to be able to have decent work conditions. The ones who are in it for the money are not going to be in the intake at the emergency department no matter what country or profit/social system is in effect
(4) Why would they need more taxes to pay more wages? They could take taxes they already spend on something and move it to wages, or they could borrow money, or remove inefficiencies, or print more money, or invest in the economy which will bring in more taxes -- it is not a binary decision
(5) And you think that running healthcare with CEOs and stockholders in charge who require profit growth every quarter and are used to working their staff to the point where it is just barely enough to not have everything break because that is the most profitable way to run a business -- is better?
With population decline and a shrinking workforce, the labor market takes time to readjust to the new norm of lower wealth (because lack of labor in one area means less output of services/goods).
For wages to increase taxes have to increase which also reduces viability of certain low margin businesses and further decreases societal wealth in that area of the economy. It’s all a trade off under the new reality.
You don't need to increase taxes to increase wages - you could actually collect the taxes that are due but being funnelled off into offshore accounts, you could limit the bonuses being paid to CEOs while workers struggle to heat their homes, you could cut military spending, you could not give £35B of public money to a few mates in exchange for them pretending to supply PPE. The list goes on.
You do for public workers assuming all else equal; if you fix the corruption you point out, that will always help regardless of the situation present and it would constitute a new baseline from which taxes would have to be risen.
In the long-run, but this also works both ways. On one hand the recent years have resulted in hospitals rapidly going over capacity, and nurses quitting from overwork. But nurses have negotiated higher pay in general, on top of things like hazard pay. That can lead to shortages if hospitals can't/won't afford to pay for sufficient staff. Moreover, hospitals (particularly places like US) seem to have an economic incentive to keep staff low during tighter periods because good nursing staff does not reflect billable service.
Well yeah, that's exactly the case. There might be a shortage of affordable homes in big metropolitan cities, but there's certainly no shortage of houses in general.
No market can respond instantly to changes in demand. Nursing’s lead time is less than many other goods, just look at how long it took Tesla to ramp up production.
What’s illustrate is the supply of new nurses isn’t dramatically increasing suggesting the market is roughly happy with their current numbers.
Free markets don’t instantly respond to changes in demand, but they do respond to price signaling. The fact that the number of nurses isn’t increasing dramatically suggests the market is reasonably happy with their numbers.
NYC’s housing issues can’t get solved by people trying to toss money and manpower at the problem if the city doesn’t let them. Regulate away the free market and you don’t get to blame the free market for the resulting failures.
This is usually the correct take. Labor shortages are typically propaganda for below-market wages. This should be your default assumption whenever you hear about any labor shortage until there's evidene otherwise.
Here I think it's a little different. First, you can't just mint new nurses. That takes time. Second, a lot of nurses have left the profession (or at least specialties like ER and ICU) because of years of stress dealing with the fallout of the pandemic.
Nurses were at one point and in some locations quite literally choosing who gets to live and die. If you don't think that puts stress on someone, combined with being overworked, I'm not sure what to tell you. So it's not just an issue of money to lure them back, particularly when (later on) so much of this death was entirely self-inflicted (ie people choosing not to be unvaccinated).
You shouldn’t put so much blame on individuals. The excess death are mostly a result of really poorly executed public health policies and messaging. Government officials, lied to everyone and sowed a lot disinformation and that caused mistrust and poor infection control. The resulting public health chaos resulted excess death, and people believing all sorts of wacky stuff.
That doesn't really apply when your labor pool requires years of training for a job. In such case you very much can have labor shortages disconnected from wage.
I agree completely. Also, it would also help if we didn't treat nurses like garbage. If we offered stuff like paid time off, sick leave, and appropriate levels of staffing. If we didn't lay off half of them and expected the other half to do twice the work.
There would still be if it took years to get a nursing certification and essentially everyone with one was already employed. I can't just decide that I'm a nurse tomorrow and start on Monday, no matter what they pay.
If you never fixed the criterial pipeline sure you would have a temporary shortage because that was your bottleneck. But there are plenty of people with equivalent skills, past or military experience that could do the job or be trained quickly to do it. It’s just a lack of desire to actually deal with the problem
You don't need to pay millions. But when you pay the minimum wage and exploit those people to the maximum, you get what you sowed. When they find a minimum wage job with better working conditions, they flee.
In Italy IT salaries are going up, well above nurses ones, still there's not enough IT people. There simply isn't the people. Almost no one really grasp how bad is italian demography.
That's pretty much exactly what happened. Nurses demanded higher pay. Government said no. Nurses threatened to strike. Government said they can't do that. Nurses threatened to resign in mass. Government passed a new law forbidding that. Now the government is trying to replace them with 20,000 nurses from third-world countries. And do note that this is all under the left-wing coalition currently in power.
I'm sorry but this is a really poorly informed opinion. You actually can have a shortage of labor - see e.g. countries like Japan and Russia, where the demographics are very skewed towards the geriatric, and you literally have more jobs than people to do them. Birth rates in these countries have been too low to keep populations stable, and as people retire you wind up with a labor shortage.
This is starting to happen all over the world as the global baby boomer generation is aging into retirement. It's started to happen in most of western Europe, China, Japan, Russia, even the US. It's absolutely not a wage issue, it's a demographic issue.
So more people learn that trade and another one loses its staff.
Labor shortages aren’t just money. Nauru has tech labor shortages. Singapore has notable farmer shortages. There are teacher shortages in the US even where wages pay well because teachers are sick of regulations or students. Korea has such an inverted population pyramid that its only possible future is half the country devoting their lives to caring for old people at the expense of either industries having no workers, and immigration isn’t a solution because other countries will be hitting similar problems at the same time.
Depending on the labor market in question, there could still be a labor shortage though. Those new nurses aren't just appearing from the aether. In places with very low unemployment they'd likely be leaving other jobs. You're then only moving the labor shortage to some other area of the economy.
Sure, now you might have enough ER nurses, but maybe now you've got a lack of primary care nurses. Or nurses at nursing facilities. Or maybe instead of just drawing from the pool of nurses you've now got fewer doctors or PA's, since you've now incentivized nursing over being an MD.
Sure, but what's the lag time on that? Four years? Ten?
It's possible to claim they should have paid more in the past, and that's part of the problem, but unless you're going to help immigrate already-qualified nurses from another country you can't simply increase wages and solve the problem you're having today.
You can kind of. You can raise the pay for nursing assistants and lower the credential bar for actual nursing, and raise pay to entice those that quit to come back. There are probably enough skilled folks out there to make that happen
Not really. If its appropriately staffed for most of the year, then there is a crunch period its realistically better to suffer the crunch than have excess staff for most of the year.
I am a decently experienced NYC cyclist. Not Terry Barentsen or anything, but pretty decent at biking both in fitness terms and in practical urban NYC riding.
The biggest problem with e-bikers, and general e-thing riders, as a population, is that they haven’t built the bike skills equivalent to the speed that they can go at. I can ride 20mph if I want to, but it took a long time for me to be able to do that. I had to ride a lot. In doing so, I got a lot of practice.
E-bikes allow you to do that with basically no practice. The resulting behavior is not good. They ride erratically. They ride with AirPods. They salmon. They salmon at night with no lights. They salmon on roads that aren’t even one way! They shoal at every intersection.
So this thing will make them double wide as they salmon… I don’t want to be opposed to e-bikes but the practical effects on cycling, for those of us that were already doing it, since the pandemic explosion, haven’t been great.
There was a recent case that made me think it was just inexperience with speed on an ebike, some of the canyons in southern California are pretty scary even if you are used to racing due to having to worry about a car in the wrong lane on every blind corner or cars pulling out from driveways no matter what a cyclist is doing.
The company's defense is no one under the age of 18 is suppose to use these.
What does 'salmon' mean here? The first time I read it above, I thought you meant 'slalom' but then you repeated 'salmon' several times so it seems deliberate.
Salmoning is going the wrong way. It’s ridiculous in NYC, especially on streets, a street going the other way is almost always one short block away.
Shoaling is cutting in line at lights. Inexperienced cyclists/e-whatever riders are notorious for this. It’s not dangerous but is very poor etiquette if you are not going to absolutely blow away the people you cut when the light goes green.
So, if you cut someone on a Citibike (local terrible heavy bike share bike) on your Specialized Tarmac SL7 in full kit, then, like, whatever. Not that bad. The Citibiker probably doesn’t even realize it’s rude.
But if you cut in front of kitted up people on road bikes on a Citibike, you better have some monster legs.
Anyways I notice this a lot with e-bikes recently. But the thing is that I am actually faster than them, despite riding a “regular” bike. So it’s very annoying.
And half the time they’re wearing AirPods and are just completely oblivious as they do this. Honestly the median Citibiker is not much better, but at least they only go like 8mph.
3000km seems ridiculous as the lifetime for a bicycle, and to make it worse an e-bike will be e-waste. That would mean it was trash in a year for my commute alone, and this is in NYC where commutes are pretty short. That doesn’t even account for recreational riding.
That being said a puncture is just a normal bicycle problem. Does Rad offer tubeless compatible components? I’m guessing e-bikers may be less “normal bicycle maintenance” oriented than your average road/gravel/mountain bike owner and tubeless would nearly eliminate punctures.
Haha yes. There was always a lot of drama at Facebook about “leakers”. People HATE them, they don’t understand why they have no “honor” and don’t quit if they hate Facebook so much. They call for witch hunts in comments whenever something leaks.
People seemed completely unable to connect the dots, that if you think Facebook is evil, why not leak all their stuff to the press, and get PAID to do it?
I use macOS, so apps should be written with AppKit. For Linux they should either be GTK or Qt, depending on desktop. Recreating widgets from scratch with GPU rendering is doomed to feel wrong to users.