bouncing

The problem with the suggestions here is that it puts all your eggs in the same basket. 1Password TOTP? If both your password and the TOTP are in your password manager, you arguably really just have a single factor, delegated to a third party (your password manager). PassKeys? Same problem. Storing your recovery keys in your password manager? You again just have 1 factor.

SMS is bad and should go away, but it isn't so clear what the replacement needs to be for most people.

I'd say Electron apps would exist regardless of the native toolkit quality. The business case is that you're probably already building a website, and if that's the case, why not offer native apps too with almost no added development time? The value of Electron is that you don't have to hire development teams for each platform.

And yes, Windows development is a mess. Mac less so. KDE and Gnome have their strengths and weaknesses. Ask around the average Mac, Gnome, and Windows user what they think of Electron apps. Windows users are probably the most positive, because their desktop experience is garbage anyway.

Does that make JavaScript actually better? Win32/WPF/UWP meet Angular/KendoUI/Sencha. React and Vue are slightly less messy, admittedly. But it's still a very fragmented landscape.

The same could be said of America in general. It’s totally unpredictable, and the people in charge are not especially reasonable.

However, assertions that web apps are inherently inferior and that web apps are only written by people who couldn't bother to learn native technologies is at best ignorant and at worst lacking empathy with the requirements and constraints, and in turn with end users empowered with choice.

Well, "inferior" is always a subjective claim. The real problem with Electron, besides perhaps resource consumption, is that web apps are not native apps and native apps have all kinds of idioms, integrations, etc. A selling point of Electron is that it has "native menus." That's it. Just native menus.

They do not have, for example, proxy icons. They usually don't have system-wide services integration. They can't be automated with AppleScript. The print dialog are almost always weird, etc.

There are similar idioms on Gnome, KDE, etc. Think about header bars or Adwaita in Gnome. Or ssh filesystem support in KDE.

All these things make users more productive. If you really know your way around a desktop environment, and you know all the tricks, you can be massively productive with native apps. You'll never be similarly productive, however, with even the best Electron apps.

The mistake the author is making here is conflating a "good" app in isolation with a good app in a desktop environment. An Electron app which is an amazing app in isolation, with thoughtful design and efficient code and useful features, is always a bad app in any actual desktop environment. Putting an Electron app in MacOS or Gnome or KDE is like putting gummy bears in tacos or lasagna. Gummy bears are good. Tacos are good. But they don't belong together.

So where are Electron apps actually good? I'm guessing ChromeOS. Otherwise, they always kind of suck, even the $25k Electron apps at Bloomberg. And while I hesitate to make blanket statements, I have yet to use a single Electron app I actually want to use, ever. They're always, and this is without exception, garbage on any desktop environment I actually want to use. Full stop.

I’ve seen projects do the same, but also issue passkeys. That lets them seamlessly sign in across ecosystem devices.

The account recovery process for commercial email providers usually involves you photographing your ID. Presumably the post office, in person, would be far less likely to be fooled.

And what does the Australian government know? Could it collect who you identified with?

The walrus operator is nice, except in comprehensions. f-strings are great, except for the `=` debugging operator. Dictionary merging and update operators contradict the "one way to do it" with weird and confusing syntax that's completely redundant to methods that already exist.

Type hints are a sore spot for me. They're good enough when you just don't remember whether an argument is an object or a string, for example, but once you start type hinting deep into data structures, your hints become a mangled soup of nonsense for basically no real benefit. Typing errors are a rare occurrence—perhaps once a year in most projects—yet we clutter our codebases with verbosity to satisfy type checkers instead of prioritizing clarity for developers.

There's a lot that's just straight up redundant. Dicts are ordered now, but is OrderedDict deprecated? No, because it's just slightly different in weird and mostly unimportant ways. `frozenset` is a builtin, for all 3 programmers worldwide who use it. Python resisted match/case syntax for decades, but when it finally arrived, it did so in a way that’s anything but standard—good luck figuring it out without consulting the documentation.

Obviously some improvements are real. Every new version of Python brings valuable enhancements. But just go back to Python as it used to be -- pseudocode that runs. That's just not true anymore. The simplicity has slipped away and will never ever come back.

And the standard library? A very real problem, right now, in computer security is the software supply chain. Remember polyfill from like, yesterday? This is the era when we should double down on having a million dependencies from all over GitHub, from unknown developers with no commitment, because ... npm's hellscape is a model to follow?

I would argue the contrary. There's dependency hell, of course, but there's also dependency risk. If you were evaluating a product right now, and you saw its lockfile depended only on a specific version of the Python Standard Library, that gives you exactly 1 product to evaluate, exactly 1 team of developers to depend on. pip is great and all, but dependency resolvers have quietly let in a hundred trojan horses and a thousand unmaintained dependencies into tons of projects, and no one noticed it was even happening.

Python in 2005, when everyone depended on the standard library, was a safer place than npm is today.

It was happening a lot under Guido too, but IMO, Python was arguably a better language (at least in some ways) 10, 15, even 20 years ago. Python's three super powers were readability, simplicity, and a vast standard library that negated the need for most projects to seek out third party modules.

All three of those have declined. It's less readable than it used to be, it's definitely more complicated (not just complex, complicated), and the standard library is declining rapidly in relevance as it ages.

And it wasn't just Guido. Tim was a big advocate for all three of those super powers when he was more influential. They banned Tim and they censored Guido, so go figure.

What performance fixes do you think were being slowed down by the community?

Pretty much every heavy traveler I know strives for carryon only. It isn’t always possible and sometimes you check a bag, but if you can do it, the benefits are real.

It’s mostly just that you want to travel light. It gives you more freedom of movement and flexibility to have just one suitcase or backpack. But that means everything from your computer to your prescription drugs to your socks and underwear is in there, so checking it isn’t an option if you travel light.

Runtime and download time are two different things.

Pyodide runs at least ~10MB. That's a lot for a web app to handle, for sure. The use case there is most likely either scientific computing/data science (where JavaScript is just an obvious non-starter), or it's line of business somewhere where someone downloads an ERP app and just runs it. Those are already huge, as anyone who uses the stuff from ERP companies can attest.

No one is seriously proposing that you should use Pyodide, with the whole Python standard library, to add interactivity to a regular newspaper website or something like that.

MicroPython might be a good fit for that though. It's ~100k -- smaller than a lot of JS tooling.

But usually when we say "fast language" or "slow language," we're talking execution speed, not runtime size.

I'm not sure what you mean. The PyScript website?

You're replacing one interpreted language for another.

Yes, Python is among the slower interpreted languages out there, but still. The debate between fast execution and programmer productivity is not a new one. Given Python's popularity, I'd say it's settled.

If I may toot my own horn, I wrote a somewhat more opinionated, reactive, frontend framework using PyScript. It's inspired by Vue.js, a bit: https://puepy.dev

Pyodide is a runtime.

PyScript can use Pyodide or MicroPython. MicroPython is actually quite small.

On top of the runtime, PyScript gives you some pleasantries and a lot of quality-of-life improvements for actually using Python for web programming, not just being able to run Python code.

I wrote one. https://puepy.dev

I mean, maybe, but you'd have trouble with sandboxing when you try to open a socket.

I'm curious what widgets/frontend tooling you use.

This is, I assume, Visual Studio for Windows. Have you tried it at all in VS Code or is that a non-starter?

If the military has fighters that can refuel in the air, why does United refuel on the ground like chumps?

First of all, sometimes even AWS makes mistakes and has downtime. They have downtime (usually unplanned) fairly often. Companies like VISA, that do payment processing, where countless dollars could be lost in just a few minutes of downtime, almost never update their old systems. They still have programs running FORTRAN. When they do update, it's complicated.

You can try to get really good uptime by doing things like forking your database and replicating your commit log to the fork. You can do rolling updates, where different customers are served different versions of a system. You can do extremely thorough testing.

But are you? Can you afford to do that and do you even have the engineering talent to make it happen even if you want to? Are you going to pass on new business opportunities and new features just to avoid a 20 minute downtime for a database migration at 2am? I suspect you are not.

Apple's been kicking around the idea of adding ads to maps:

https://appleinsider.com/articles/22/08/21/apple-maps-could-...

Makes more sense if you consider that.

> We hear so much talk about urban congestion, with cities ranked by the hours drivers “lose” being stuck in traffic. How much should we care about congestion levels?

I would say almost not at all. > ... All the cities that have solved congestion have only done so because it’s a city where nobody wants to be.

Maybe no one has really "solved" congestion, but the places with the worst congestion are objectively worse places to be because of it. Mumbai, New Delhi, Lagos -- places in the developing world where there was never really even an attempt to reduce congestion.

In terms of world cities, New York and Los Angeles aren't even that bad. Compared to New Delhi, commuting in LA is a delight. And LA is still definitely a safer place to be a pedestrian. And even if you don't drive to work, congestion harms you, because you rely on services that use roads.

A more nuanced take would be that easing congestion matters, but we shouldn't design meta-cities with the idea that everyone should drive to work every day.

At first glance, these tools seem to be a bit behind the likes of GitHub Pull Requests combined with any number of the great review tools out there. Not to say reviewers at Google aren't doing quality work, and ultimately the tool itself doesn't matter as much as people think, and I don't see any special sauce here.

A lot of big tech companies have developed totally in-house tools and procedures for basic software development that mirror, but aren't quite the same as, widespread industry practice.

Before the Google Way of doing things, there was the Microsoft Way. Before that, there was the IBM Way, etc.

Several studies show that people who live near parks, canals, rivers – any green space – are less likely to struggle with mental health issues. And this is the case even after we account for individual differences in socioeconomics. The risk of developing depression is about 20% lower in people who live near or spend a significant amount of time near green spaces. But what we don’t know is which specific aspects of the natural environment are beneficial.

So when you control for socioeconomic status, and an effect remains, is the remaining actual effect 20% or something much less? Worth asking anyway.

Well, Volvo had a presence in the US long before it became a Chinese subsidiary.

Of course some Chinese companies might try to penetrate the US market by manufacturing in North America, and that's already what a lot of foreign (but not Chinese) car companies do. Mazda, Toyota, BMW, etc all have factories in North America.

When I've used it, I've used it in conjunction with a table that maintains state.

So basically the notify keeps other processes from having the poll the table for updates, but the table itself still acts as the queue.

All cool stuff.

But to my mind, the main advantage for this postgres workflow is that you get something simple without adding a ton of stuff to your stack.

So the components are all imported from China, then assembled in Mexico. Maybe that's an improvement, and it keeps Chinese brands from establishing themselves, but does it really matter?

"American" manufacturers obviously have no problem sourcing parts (and labor) from China. Why should "American" consumers?

Because at least presumably, the American companies sourcing parts and labor are overseeing the final product. A lot of products are made in China, sold at Target or Best Buy, and quite good.

Whereas if you buy some "random China" toodad off of Alibaba or Wish, who knows what you're getting.

To put a finer point on it, would you trust Random Chinese Business to definitely install airbags correctly without Ford or Toyota looking over their shoulder? I doubt you would.

It's not a hating on China thing so much as it's an acknowledgement of the fact that domestic Chinese brands generally tend to make absolute garbage.

Sure.

I'm just pointing out that regardless of branding, the quality of the products is (1) not equal, (2) still correlated with where the vehicle is assembled.