Orou

Are there any major benefits to using Tailscale over vanilla Wireguard?

> This cycle of having a few years where the costs of an approach aren't acknowledged, to a few years where the benefits aren't acknowledged, is very lame.

Well said. I do sympathize with some of the criticisms but only insofar as people who didn't have experience with microservices get sold on a lot of hype, the tradeoffs aren't made clear, and they get burned. The cycle seems to be "This is the silver bullet for programming complexity!" for a few years, followed by a few years of "This isn't a silver bullet!" before the Next Big Thing (TM) comes along and the cycle starts over.

> The more hardcore UBI defenders talk about paying Malibu surfers to surf all day, or to write haikus

I've been following the UBI space for a long time and I've never seen anyone use this as an example - that's just a strawman. What people discuss is the work that is valuable to society but is unpaid such as raising children, caretaking for the elderly, community support, and so on.

A few hundred dollars a month isn't enough to live on, but it moves the needle for those most at-risk for going hungry or becoming homeless. And for everyone else, it gives extra breathing room and negotiating power in the workplace.

This makes me really curious about how people with legal mononyms (Ye, Cher, etc.) have their taxes filed or medical forms filled out.

> always just about 'good enough' to solve the issue at hand

I've seen this approach really bite teams that only focus on the cost of implementing application behaviors rather than the long-term costs in terms of maintenance and systems complexity. If too many poor design decisions are made when a project is greenfield under the premise of "good enough" it can create technical debt so bad that the devs can't extricate the debt from core product features further down the line.

You're not missing anything, the argument is for how long this duration should be.

The lifetime of the original creator plus $YEARS should be more than long enough for the original work(s) to be made 'canonical'. How is a corporation buying up an IP because it is profitable going to guarantee it remains true to the original author's intentions, or to the desires of fans? If we care about the consumer they should be free to engage with the original works or any derivation thereof as they choose. IP isn't about expanding consumer choice, it's about limiting it - and it certainly isn't a mechanism for guaranteeing the ongoing quality of a series.

I agree libraries are great when dealing with very specific domain problems (who wants to hand-roll a datetime module?). But there are also a ton of libraries that aren't for such specific domains or which attempt to bridge multiple domains (i.e. frameworks).

The argument made by functional languages like Clojure is that by making heavy use of pure function composition, you don't actually need a million libraries to build large/complex systems. You can do it with a much smaller number of libraries where necessary and take advantage of the language's natural extensibility for the rest.

Is the interleaving of redis and db transactions atomic?

> I would strongly advise against using python for anything other than PoC/experimental endeavours.

I agree with your points, but this seems to lean a bit too far the other way. Yes, Python has plenty of limitations and cases where there are better choices in programming language. But saying that it shouldn't be used in real production systems when there are so many examples of it being used effectively for precisely that seems a bit hyperbolic, no? It's like saying Javascript shouldn't be used in production.

> it forever mystifies me that it isn't standard

I can give a few thoughts on why here:

- it doesn't work for collaborative efforts unless everyone is using the same linter or IDE with the same configuration. Not friendly to edits outside of that ecosystem (e.g. open source). - there are other ways of writing SQL (e.g. dbt style guide) which are still very readable while also being much faster to write by hand without the need for an auto-formatter. - some of these patterns such as the from and join indentations have nothing to do with readability and are purely stylistic. Nothing wrong with that, but there's nothing objectively better about this pattern - it just comes down to how you're used to reading SQL.

Wholeheartedly agree with this. The problem isn't aliasing, it's lazy aliasing which is more I think what GP was referring to (e.g. emp.id instead of employee.id).

> Separation of "developer" and "user" is artificial and more should be done to recognize that.

I've seen some company ROI models built in excel that I think would change your mind about this.