tolmasky

Separately, it’s weird that a joint account is insured to 500K but a business account stays at 250K. It actually does weirdly favor wealthy individuals vs. working capital accounts for businesses that might represent many employees.

BTW, in my experience many many people are risk averse in specific things they see that others don’t. It’s super hard to be an expert on everything. Talk to someone that knows about construction and they’ll have similar laments about home maintenance. Is it bad to “bail out” people that have their homes washed away in a hurricane? I honestly don’t know. But what I do know is that I’m definitely not jealous of them for making a silly location choice and “not paying the price”. That experience is not fun. I promise this episode was fairly disruptive even with this outcome. It is much better to look on from the outside than wonder whether a bunch of people you don’t know will save you. You’ll feel really bad if the next one isn’t bailed out because something is different and it gets you because you stopped doing something that aligned with your values just because of this thing this time.

To be clear, Etsy is not my concern here. They will probably survive just fine regardless of whether we deem them to be responsible or not. That's part of the point. The sole question was the sellers, and trying to examine why they inspire more sympathy to similar-sized companies that may be directly banking with SVB. Hence my question of whether the mere existence of a legal entity is the difference, given that in fact many Etsy sellers do of course have simple LLCs set up. I would fine "Hey, Etsy sellers need to look into Etsy's bank to be responsible too" consistent with "3 person YC companies need to be responsible about the bank they choose", or acknowledging that's a tall order for both. But not one and not the other, was my only point here.

> Yes... That's what SV just did to its ecosystem due to over-reliance on one bad bank because "optimization is king" is the mantra of the whole machine.

If it puts your mind at ease, I think the result is going to be the same regardless of what happens to depositors: everyone now will try to spread out their money and sweeps will become part of startups 101, etc. In that sense, the system has worked: the irresponsible bankers are being punished, they and their investors lost their bank. I promise no one is going to wake up and say "well, glad that got magically solved" and not be super paranoid going forward. If anything, if depositors aren't made whole, this particular demographic is more likely to, to your point, over-optimize in that direction (perhaps create investment vehicles to short regional banks or something, who knows).

Without derailing the discussion into whether Etsy "should have known better" (which to be clear is an argument that would be made in a simplified vacuum given the complexity of them probably just being an intermediary between a credit card processor and the sellers and thus it being fairly logistically complicated to set up that intermediary as some sort of multi-bank-account system or whatever), but regardless, even if that is the worst way to do it in the world, the point is that that's not the individual sellers' fault, and they shouldn't be punished for it. Again, as I mentioned in my comment, the position that "Well individual Etsy sellers should really do a financial analysis on the host platform's bank, quarterly, to account for interest rate changes, and if they independently conclude that that bank is unhealthy, they should pull their store off Etsy and... ???" is a bit hard to swallow, and I'm not sure if a world we really want to create.

Just so I understand correctly, if the seller has an LLC they made through legalzoom.com for their Etsy bowl business (which is very common and highly recommended), then does your sympathy for them immediately evaporate since they now have a “responsibility to manage their finances effectively”? Why exactly is the Etsy seller off the hook in this scenario? Is it a headcount requirement? If the Etsy seller LLC is 3 people (two sisters and their mom), now are they irresponsible for using Etsy? Are all those 3 person startups in YC different somehow? Only in that they make “useless” things and the Etsy people make “useful” things, and that translates to whether a corporation needs to be responsible?

> Here's the question. Now that this happened, do the rest of us just accept that this is how it works? Because if we do, nothing changes, and we just get to sit back and wait for the whole system to unspool again.

Accept that what is how it works? It depends on the solution. If the solution is providing temporary backstops to depositors so that a sale to another private bank can be more attractive, then I don’t think that’s anything earth shattering to accept? Especially considering it would probably result in a private solution happening faster at little to no cost to the taxpayer. If congress empowers the FDIC to claw back SVB share sales to help make depositors whole, I think that’s also not anything that people would have a problem accepting? Like part of the problem here is that completely different parties are lumped together and in this fury the only acceptable answer is “no help!” No one is arguing for SVB to be bailed out. Those shares are going to zero. That is a sufficient market result. Enabling a bunch of assets that still have value to be maximized to avoid the philosophical dilemma of our Etsy seller doesn’t seem to be the “end all” nightmare scenario it’s being chalked up to be here. If anything, maybe the focus should be on plummeting interest rates to zero making precisely the kinds of “full liquidity paid for checking accounts” become an endangered species in the first place. Or maybe then raising rates at break neck speed despite having questionable results on the inflation they’re targeting, while clearly affecting random pieces of the economy.

> Or, we could stop treating the machine in California like it's better than a Vegas slot machine for most players and start building something better.

It seems like choosing a random 30% of Silicon Valley companies to put in hard mode is a close approximation to the Vegas slot machine than fad imitating zero interest checking accounts that were in no way high risk irresponsible investments that had the chance to wildly benefit the depositors if the bet would have “paid off” vs. if it crashed to zero. Especially given the high likelihood that there are sufficient assets to make depositors either whole or almost whole, it seems even more the case that those disproportionately affected will be workers, and not companies. Not to even mention the fact that those most responsible (Thiel) aren’t going to suffer, nor are the mega tech companies that can easily survive this, and may even end up just absorbing some of these companies and consolidating even more.

I am super curious as to what “something better” looks like though. Because right now, the world 6 months from now where a random subsection of tech and wine workers had their year ruined, while big tech companies and VCs are still doing just fine, doesn’t exactly seem like fertile ground for whatever amazing new system you have dreamed up.

The majority of your argument revolves around the idea that only rich people in this “rotten system” will be affected, or that this is an important lesson. When it’s pointed out that there are many types of employees who aren’t rich, you say they don’t count because they’re contractors, ignoring that even if true, which I’m not necessarily granting, it still doesn’t matter since that contracting job will still probably disappear and there is a high likelihood that they can’t just be immediately positioned somewhere new. The rich developer may have an easier time landing a new position than the cook getting a new shift from the contracting company somewhere new. But I suppose that’s irrelevant, because the point about cooks being contractors actually had nothing to do with the topic at hand of whether they deserve to be colateral damage. Rather, it was meant to derail the conversation into a long digression about how these contracting agreements further prove how “rotten” these startups are… and thus deserve to learn a lesson about treasury performance.

If you stick to text files, you'll never have to go to caniuse.com ever. Need styles? Just make a PDF and throw that online. During the "XML HTML" phase the web went through, I never had to worry about validating my PDFs through an XML validator. Then when everyone decided using "<b>" and "<font>" tags was bad and insisting we switch to using "font-weight" CSS in a completely unrelated part of the file, guess what I had to do? Nothing! My PDF keeps rendering exactly the same way through every silly "trend" and "update" on the web, and never misses a beat on Lighthouse in Chrome.

Now if I could just convince all the browsers to implement .docx renderers out of the box, I'd really be set.

This inevitably leads to the actual problem we have in this country: minoritarian rule (that should be obviously worse than majoritarian rule, but again, gets disguised as the "actual majority" or "equally populous opposition" getting a say). If you look at the composition of the supreme court and the senate, along with the contribution to the electoral college from states in presidential votes, it's pretty clear that what gets dictated is lopsided to smaller percentages of opinion, not larger. At the current rate, we are on track to have 66% of the senate representing just 30% of the population by 2040: https://www.washingtonpost.com/news/politics/wp/2017/11/28/b...

I see we're still getting mileage out of the whole "population/land" duality, huh? The combined population of all the counties that have voted to leave so far is 205,000 (the red counties, not the grey and green, which have not voted so far), which, assuming the entire population voted to leave, comes out to just 5% of the population, not 50%. For the record, that's not even 50% the population of Multnomah County (the county that has Portland in it).

To be clear -- I have no particular opinion either way about whether counties should be able to switch states like free electrons in metal. In fact, I might lean towards it. I just don't see the need to repeatedly use the lamest, laziest, and cheapest rhetorical techniques in these arguments. For a group that loves to talk about virtue signaling, they sure like to "arguing-in-bad-faith" signal.

Afterwards you’d get involved in a long weird analogy discussion about two people arguing about git. But that fault would be shared by both of them.

What a slight of hand to say "You can get it the same way you can with node, except for you can't". You should go into politics. Anyways, you asked me for a simple example, I gave it, and now you want to say what I want doesn't count because "no one wants it". Just choose a different challenge next time.

> thus you’re complaining that nobody else is maintaining this port for you.

I'm just pointing out a discrepancy with other environments. One you initially denied existed, and once I trivially pointed out did exist, you switched to attacking the complaint itself. Look, if I'm looking at two toasters and one has less features, sure, you can bark at me and tell me to make my own toaster if I want that so bad. OK, sure. Or I'll just get the one that has the features I want. You are still allowed to believe that those features are useless, but you can't deny they exist. It is OK for you to disagree with the properties I value in an ecosystem, you don't have to resort to telling me I don't know what I'm doing just because I value a different set of properties in the ecosystem.

My point has always been simple: Python causes more pain than other languages when you're not directly using it. I can get node 0.10 on alpine 3.17 just fine. This demonstrates that your comparisons to server JS are completely wrong. But I know, you're going to tell me this is my problem and I expect the world to do work for me or something. Nope. As I've repeatedly stated, I've taken the time to get it to work already. I know you want to believe I'm here waiting for you to fix it, but I'm not. All I've said is: "Huh, I don't have this problem with anything else. I'll keep that in mind before I decide to use stuff from this ecosystem in the future".

If you don't want to read the comment, then also don't bother responding. The comment is long because I am explaining a death by a thousand paper cuts situation. Don't worry, Python isn't going to die just because I don't like it. You don't have to defend Python even if you don't feel like reading my comment. You can also just ignore it or come back to it when you have time to engage with it thoughtfully, instead of just asserting you are correct and having your only argument be that I can't fit my argument to the arbitrary word length you've come up with.

> Those where the first that came to mind. There are many others, and many more if you widen it to server-side JS.

You should stick to talking about Python. This is just not the case and not the culture of browser JS. It's honestly fairly disrespectful of the monumental work browser engineers have done to make that a reality. If you want to switch your argument to server-side JS (where blink and alert don't exist and you are thus leaving it completely as an exercise to the reader to come up with the similar situation), fine, but node 0.10 runs exactly the same today as it did 10 years ago. Again, the bar I am setting is low: have the unchanged thing still gettable and still runnable. I get it. When you work in a certain environment, you imagine all the problems it has must be common and all the benefits are unique. But that isn't the case with this particular problem.

Incorrect. You have to understand that I am not a Python user, and don't a priori care what they do with the language. I only become annoyed when something breaks on its own, or if changing one unrelated thing breaks other unrelated things. This happens for a variety of reasons:

1. Either date-based breaking, or patch releases designed just to throw up deprecations, and breaking the tools you actually use.

2. Packages and or binaries disappearing from package managers, such that even if I have a pinned version and I make no changes, an accidental cache invalidation can now break the entire image.

3. The fact that updating one utility may break others (either because you need to figure out this python symlinking issue or whatever).

4. Python causing discontinuities that don't exist in other bundled build tools. Going from buildpacks:x to buildpacks:y, to get a new feature in A, usually doesn't affect B, but in the specific case of Python, means the installed version might change and break a bunch of stuff.

5. Python 3 changes often being bundled with breaking API changes in app updates, making "upgrading to Python3" a uniquely involved challenge for each one.

If you deprioritize "fault" for a second, such that we're not deciding who's to blame here (whether it's the transition plan by the language devs, the library or app authors, the distribution handlers, or even end users like me), you have to reconcile the fact that this is a unique situation to python. I am not describing the woes of development in general. I am describing a very python-specific set of experiences for non-python users. I did not out of nowhere decide to get angry at a language I don't use. This is the result of a repeated set of circumstances that just aren't happening elsewhere.

As has been mentioned throughout this thread, it is further upsetting that a lot of this could have been avoided. The fact that there are things that could have been done differently to make the long tail effect less painful is fairly disappointing. At the end of the day, I don't need a list of solutions. I've implemented them all, don't worry. I've gone through and read the 500-thumbs-upped threads of people repeatedly running into this exact same problem, either found an easy workaround or taken the time to update the config files for a tool that rudely put itself at the front of my priorities list in order to fix the build, or found a way to remove the utility in question completely. This is not me coming on here trying to figure out how to move forward. This is me identifying a clear pattern, and sharing what I believe to be is a common conclusion: putting "python" in the "cons" column when considering a tool.

I come from the node world. There's plenty of people that do the same for node. Some of it I consider fair, others not. But I make no illusions about one fact: if we want to change that perception, it's up to us to earn that by making the experience better going forward, not by explaining to people why their experience actually isn't real. For example, if there is a simple solution, if you just were familiar with the ecosystem, then LOG IT WHEN THE ERROR HAPPENS. If the person has to go to stack overflow and see a thousand other people running into the same thing, then you've failed.

> However that's not what you're complaining about. You are complaining about is that you want others to support python2 forever, just as you may want browsers/sites to support `alert()`, the `<blink>` tag and IE 6.0 forever. However that's not how the world works.

This is also hilarious since you had to scrape the bottom of the barrel to find the only instances of "non backwards compatible" features in JS/HTML, an environment notorious for backwards compatibility. Also, `alert` may still stay in.

Not sure where you're going with this. I didn't whine to someone else to fix it. I did take ownership. Over and over. I fixed these problems, as unrelated to my main goal as they were. I then complained about it after the fact. Seems like a totally fair ordering of events to me.

Separately, I will state that Python is an environment that seems to go out of its way to make it hard to meticulously manage dependencies if you want to. There's all sorts of competing environments and package managers. I'm sure it's straightforward if that's your main environment, but it doesn't help if you're coming form the outside.

> Those should be routinely addressed as part of your auditing, along with the whole of the supply chain

This assumes that the only available option is "manage this dependency better". That's not the only option. There is also "consider using something different that is easier to manage." Most of these utilities exist in a competitive market. And if there are utilities that allow me to choose the cadence and separately make that auditing simpler, then I will choose that. That is the point of my statement. I am not choosing to go on a hunger strike or avoiding some no-other-choice tool. Quite the contrary, a lot of these tools were chosen by other members of the team at some point, either because it's what they were familiar with or some other unimportant reason, and now they have, to their own detriment, made themselves the squeaky wheel, and opened up the range of possibilities to everything from "put in the work to maintain this tool that has currently demonstrated itself to be brittle" to "maybe I should use something else". Generally speaking, it's a bad thing to only draw attention to yourself when you are doing something bad.

> can't really prescribe much... this is just generic advice.

And yet this is a specific problem.

> I understand the woes, it's just not as unique as this is painted

It very much is unique. I'm literally not experiencing this with any other language that I don't directly use. Do I experience this with the libraries I directly use in my language? Of course. I signed up for that. I know the risks I take using beta builds and have a keen sense of the current internal transitions, etc. But I absolutely do not become aware of the latest argument in the C++ language spec, or a contentious Swift proposal, or end up becoming vaguely aware of the string implementation choices of a language I don't use. That is a unique Python thing. The fact of the matter is, Python has (recently? momentarily perhaps?) proven itself to require more maintenance than other tools I use. The community can decide who's at fault for this (language devs, library devs, end users, whatever), and even whether or not it matters, but if the message to the people outside the community is to deny that this is unique or troubling, then don't be surprised if the way they choose to take ownership is to count Python as a point against a project they are considering to use.

Maybe one day you can get past DH0: http://www.paulgraham.com/disagree.html

Also, I am not "trying hard" not to care about Python. I specifically said in my very first comment I go out of my way to avoid it now. I think that falls in the "cares" category. My default state is to not be aware of what language things are written in. I don't know if some given tool is written in C, bash, or JS. If I were to coincidentally learn what language it was written in, it might serve as a curiosity, but not really phase me either way. However, I was forced to become aware of a bunch of Python stuff since it started breaking, and then forced to learn about all the weird workarounds to get it working. Given that I was forced to repeatedly deal with dependency hell with apps in this language, I am now choosing to avoid it if I can in the future if I learn that an app is written in it.

I think you are missing the key point here: I don't write a ton of Python. I don't write any Python. Of course you think this is old news. You write a lot of Python. You're totally plugged in. You've known this is coming, this inside baseball is "the thing" for you. My point is that, believe it or not, the rest of the world does not keep up to date with whatever the Python community is doing. This is not unique to Python. Most people in dev community X are not aware of what is happening in dev community Y. What is unique to Python is that all of a sudden we were forced to become aware as the downstream apps began to break. By creating a backwards compatibility issue in an interpreted language, you necessarily "backload" the end-user pain to when the apps, which by definition are updated later than the code within the apps, begin to break as packages are removed from package managers, or things are EOL'ed, etc. This is a situation that I can honestly not remember happening with any other language. I can't remember any other circumstance, and certainly not one where it proceeded to happen repeatedly, where I've been abruptly made aware that utilityX was written in a no-longer-supported version of C/perl/whatever (when I previously didn't even know what language it was), after I had been running it for ages.

But that's exactly the nature of doing this sort of change. Again, I am not a Python person. This transition created an unintentional filter where the utilities with poor practices surfaced to end users, such that their only direct interactions with Python are always negative. So sure, the extrapolation may very well be unfair, but that is the completely avoidable situation they set themselves up for. No other language expects end-users of the programs written in that language to be sympathetic to some internal engineering transition. All this stuff may have great reasons, but you've already failed if you have to explain those reasons to non-Python users, or tell them this is confirmation bias or whatever. It's just not happening with other languages. And this is for big stuff too. Ansible, which uses 2 pythons, one locally and one remotely, was a pain. Add on to this that this was a fairly public boondoggle, that the makers agree wasn't handled well, so whether "fair" or not, this is a common take away I think.

However, I will take your snarky reply and turn it into lemonade by using it as an opportunity to talk about how often development teams fail to consider the social implications of their changes. As is mentioned in another comment on this post, the Python team seems to readily admit in retrospect that they didn't predict the pain of having no clear transition path, etc. I think another lesson to take from this experience is the realization that if you create some big "line in the sand" update, you may absolutely inadvertently encourage bad development practices. If the Python 2-to-3 transition had held "ease of transition" as a core value, then it is more likely that that value would have been modeled downstream. By instead initially declaring that the 2-to-3 transition was going to be some watershed moment and people were going to have to update everything, it is not surprising that it could encourage people to just pull the trigger on a bunch of breaking stuff they wanted to do, and come to the (incorrect, but understandable) conclusion that they didn't themselves need backwards compatibility since the entire ecosystem was going through a "unique" non-backwards-compatible change anyways.

The worst part is a lot of times, since Python 3 is a breaking change, people decide that it's a great time to finally do all their breaking API changes too, so all of a sudden updating something to the Python 3 version means that all of its associated config files have changed format, and now you're updating config files that have worked great for ages and running into bugs there.

I have this opinion about no other language. I am generally neutral about languages I don't use. But literally my only experience with Python is porting to Python 3. It's like a sitcom scenario of how to force the worst possible first impression for a language ever. The amount of slowdown and pain that Python 3 has generated on our non-Python project is really just out of this world ridiculous.