Aren't all the labels on the buttons facing the wrong way? They're facing outwards in the direction of the screen viewer, rather than inwards towards the person operating the thing.
It's my experience that once you get sent to secondary they have already decided to fuck you, they are just deciding which flimsy excuse they will use to do it. My totally non-legal conjecture (and livid experience) is if you are a citizen they will play mind games with you in secondary or a holding cell for hours to a day or so and then eventually reluctantly release you after muttering threats about revoking your passport and/or not letting you in.
The solution, as Donald Shoup advocated, is to raise (or in some cases, lower, and in general, have it be dynamic) parking rates to market-clearing prices for parking spots such that there are is always one (but not too much more) free spot available on the block.
That's a necessity, but I'd also add legalizing construction of dedicated parking structures in more places. Land is at a premium in any desirable place and street parking is a lot less efficient usage of that than a multi-level parking structure. As a driver I also prefer them. Circling around blocks is a waste of time and annoying and my car is safer in a dedicated building that typically has some cameras
This is not really because parking lots are not legalized (they are, and in fact are often required) but because structured parking is so expensive to build; $25-35k per space in an above ground garage and $35-50k per space underground. https://dcplm.com/blog/cost-of-building-a-parking-garage/
The only place I'm aware of that bans new parking garages in the US is Manhattan, which has a general parking cap; but providing enough spaces for the actual car travel demand to Manhattan would necessitate leveling the whole island and then some, so the policy is there to get people to stop driving to a narrow, congested island.
At least here in California the big driver is Prop 13. The flat parking lots all over Los Angeles have been owned by the same people for decades, usually since the 70s or earlier, so they’re paying a few thousand bucks in property tax while absolute raking in cash - they can usually meet their obligations with a week of revenue and the constant cash flow is a guaranteed lever for credit and loans. Selling or redeveloping the lots would trigger a reassessment, so the owners just keep them as the cash cow they are.
I have a friend who inherited three such lots in downtown ($$$) and he lives very comfortably off just that revenue because their old assessments totaled under a million so they never got reassessed (though the rules have become far less generous with Prop 19).
I've also heard that it's popular as a literal cash-heavy business. This allows it to be used for manipulating tax filings, in both directions: laundering other income, or under-reporting profits.
I am pretty sure that most areas here in Portland affected by the shortage of parking aren't zoned to allow building a parking structure. I haven't looked this up though. Edit: It's not downtown here that has this problem, but smaller, hip neighborhoods where you have a shopping street surrounded by an ocean of SFHs
If high cost is the issue, it seems like people are complaining about lack of parking but don't want it enough to pay the real, unsubsidized price. So why should everyone else pay for them?
When I last worked in Boston (decades ago... pre Big Dig), I shared a spot with a coworker (we alternated days) that was $600 a month for parking (total).
Im in Sydney AU and parking spots are more like 50-100k. In the city center, or desirable suburbs you might see $150-200k. The city has also restricted parking permits to 1/residential address, and eliminated them for businesses.
This has all been more-or-leas fine, with residential prices factoring in parking, and multi-tenant developments pulling in density via car stackers and the like. Oh, and a pretty functional transit system, of course.
You might think so at first glance, but if you multiply a regular parking space (9' x 18', 162 sq ft) by the median price per sq ft of a normal house ($244) you get $36288. Obviously these figures are specific to the US, but cars take up more space than you think, either because we're usually inside them or because we're just used to it.
For a whole parking garage you need many large I-beams, tons of concrete, frequently elevators are added, etc. Not surprising builders opt out of including them when they can.
I don't think this is actually necessarily true. Most of the AV fantasies involve cars driving about aimlessly when not in use or increasing congestion in the reverse peak towards parking lots in the suburbs during dead times, and to the extent that those scenarios increase vehicle miles traveled that might actually be worse than parking lots everywhere.
Yes, the system developed as it did for a reason, some of the more obscure being:
+ entrenched rent-seekers controlling properties in cities (it's almost axiomatic)
+ centralized transportation systems being subject to political and labor capture-- the main purpose is not great customer service
+ red tape in urban areas for everything
+ market forces created last-resort poor quality housing in cities
+ the car vs transit battle is winner-take-all at a neighborhood level, and transit does not compete properly on a metro or regional level, nor is the park-and-ride system fully competitive
+ car-compatible density negates transit density
+ different ownership model for rolling stock leads to over-investment for cars and under-investment for transit (you buy the car you personally can afford and it sits idle while you ride the subway car your grandparents' generation was willing to pay for collectively )
Is there at least seats available? As shouldn't public transport too be market clearing. So price should be high enough that there is always empty room in busses and the busses fully pay for themselves.
Usually yeah. London has buses every 10 mins on most routes. It can get very crowded at rush hour or school run time though. Several groups (OAPs, kids, disabled people...) get discounted or free bus passes which I wouldn't want to change.
Don't get me wrong - London public transport is fantastic. Extensive, frequent, convenient, and multi-modal. But the pricing is quite static so that people who use it for short inner-city journeys lose out a bit.
I think you are right and this is one of my issues with busses in most American cities. Basically, it's just going to be viewed as a worse version of your car. You have to create a categorical change and that's best achieved with rail, biking, and walking which can't be replicated by cars or busses. This doesn't mean we shouldn't have bus routes or anything, that's not great either, but we need to break the habit of hopping on/in motor vehicles if we want to see change.
But also, we need to actually fund public transportation. In most states the amount of funding allocated toward non-car infrastructure amounts to a rounding error.
So what can be done?
Write to your representatives at your city, county, and state level. When your state's department of transportation issues surveys or maps for feedback make sure to give feedback! If there are other opportunities where your local leaders are engaging with the public just mention you'd like to see better transit and walking infrastructure to reduce cost for taxpayers and increase quality of life. Ask for a meeting. Ask for explanations. Ask questions and keep asking questions.
The solution to poor people not having enough money is to give them more money (if you really want to help them).
It's not to make random consumer goods like parking free for all. If you do this, most of the goods will be used by people who are not poor, so it's very inefficient at helping you achieve your goal of helping poor people.
In addition, many poor people won't want the thing you are making free. In the case of parking that could be because they don't own a car, so this plan doesn't help a portion of the population you are trying to help. Even more inefficient!
When people think we should have free parking to help the poor, it's mostly just status quo bias at work. Most people would never say that we should make bread free. Or that we should make milk free. Parking isn't any different.
I know this probably doesn't add a lot to the conversation but for me it articulated and cleared some inconsistencies I was failing to square up in my mind. So, nice, thanks. Do you have any books or articles that helped you in your analysis, I wonder?
>If you do this, most of the goods will be used by people who are not poor,
Why does it seem as though some people believe there is an infinite supply of rich people?
Income disparity is so great that the cost of parking is irrelevant to the mythical army of rich people waiting off to the side for parking prices to come down.
I'm not even in the 99%, I'm in the 97% and I don't give a fuck about parking. I'm driving downtown to buy a $600 Barbour jacket from Orvis. I don't care about $20 for parking and I'm not coming downtown more often if parking is $0.
>Most people would never say that we should make bread free. Or that we should make milk free.
If you are poor milk and bread should 100% be free.
Support for SNAP (food stamps) routinely and consistently polls at >70%.
People who assert what you just did are in the extreme minority.
SNAP doesn't make food free in the sense of free parking, it gives money to poor people to buy food. The equivalent for parking would be market-rate parking with means-tested parking vouchers, which would be a much, much better solution than what we have now.
You're missing the trade-off between time and money (and how it differs based on wealth).
"Free for all" parking spaces allow you to trade your time (hunting a spot) for parking, the same way coupon-clipping trades time for a discount on food.
You can say "eliminate coupons, all food should be at market price", but coupons really are an effective way of helping people. They segment the market by being too time-consuming for wealthy people to bother with, and are a job for people who don't have a higher-paying one.
You can trade your time for goods, but others might trade money for time. Something to think about maybe.
Free Shakespeare in the Park is a New York City civic tradition dating back to the 1950s. It is, as the name suggests, free to the public, but because Central Park’s Delacorte Theater has a finite number of seats, tickets are given out on a first come, first served basis. Some folks, who either can’t or don’t want to stand in line to get tickets, have taken to employing line-standers to do the waiting for them. According to Sandel, the price for a line-stander in 2010 was “as much as $125 per ticket for the free performances”
That's not why coupons exist, though, it's just a side effect. If coupons didn't exist and your goal was to help poor people eat, coupons would be a weird way to do it.
Why is it weird? It's a lot like the 10c can and bottle levy. Ostensibly for recycling, but also gives homeless people a job. Sneaks under the radar of regular-sized market forces, and gives them some agency in their lives.
It’s pretty badly targeted. Lots of poor people don’t have much time, and lots of better off people have lots of time and enjoy things like screwing around with coupons to get a discount. It also doesn’t do much for extreme poverty. If you have no money, it doesn’t matter if you can get a coupon for half off a loaf of bread or whatever, you still can’t afford it. So you end up giving more help to people who need it less.
If you want to help poor people buy food, give them money to buy food.
Would argue for getting rid of SNAP and replacing it with a convoluted system where poor people could get free food but they had to spend hours hunting for just the right coupons to exchange? I would hope not. It might help the poor, but would be a really crappy way of doing so.
Free parking certainly might help the poor a teensy bit. But it's an incredibly bad way of doing so that comes with all kind of other bad side effects.
If helping the poor is our goal, that is not a good way of doing so. You're better off charging a market rate for parking and then taking that money and giving it to poor people.
> Would argue for getting rid of SNAP and replacing it with a convoluted system where poor people could get free food but they had to spend hours hunting for just the right coupons to exchange?
That makes a lot of sense, but (mostly conservative) politicians still criticize many innovations because of their supposed effect on the (more or less) poor. Recent example: the 2023 reform of the Gebäudeenergiegesetz (Building Energy Law) in Germany, which sought to promote energy efficient ways of heating and decrease heating using fossil fuels, was met with furious opposition (including a lot of disinformation) from the conservative press and parties because of the poor poor building owners who can't afford a heat pump (which is more expensive to install, but already has much lower operating costs, which are likely to become comparatively even better in the future).
Part of what it allows is more housing (something that places like San Fran fail miserably at) because it's not constrained by having to provide 1.5 spots per bedroom or whatever arbitrary number.
And more housing is what is needed to contain housing costs.
It benefits the poor by allocating resources as efficiently as possible. If there is someone who is poor enough that they need help from society/the government, it would be much more effective to transfer money directly to the, rather than very very poorly (probably regressively in fact) target that help by having the public subsidize parking on their block.
They would rather have the $100 in efficient redistribution rather than the government spend $100 so that they can benefit by $1.
That's true but I'm not really worried about them. I'm worried about the people who are doing everything right and about to not be poor. Increasing the cost of every rung of the ladder, like for example slogging out a shitty commute and parking situation for some time decreases the number of people who make it up the ladder. It's almost like a pseudo welfare cliff. Public policy should strive to avoid doing stuff like that.
I'm of the opinion that when public goods are cheap enough to face shortages all the time the market economy steps up because better off people will spend more to save time/hassle.
The problem is when things are expensive enough to kick out a lot of people, but not enough people actually alleviate shortage, which is basically how it currently goes with parking.
> Increasing the cost of every rung of the ladder, like for example slogging out a shitty commute and parking situation for some time decreases the number of people who make it up the ladder. It's almost like a pseudo welfare cliff.
No, it's the opposite. A city built around everyone having a car makes car ownership a cliff. Normalising not having a car (and a reliable bus service - like the kind you get by turning street parking spaces into bus lanes - helps with that) makes the ladder gentler. If people are late for work because they couldn't find a parking spot just as often as people are late because the bus was late or didn't show, maybe there will be fewer horror stories of people getting fired because their car broke and they couldn't afford to get it fixed.
The market economy has solved none of these problems, and I suggest looking up just how socioeconomically mobile people in the US really are (it's not great).
Price parking at the market rate. Demand for other forms of transportation increase substantially. Provide it. Poor people can now take cheap buses and trains instead of expensive cars.
If you're worried about the transition, subsidize other forms of transport and build that out first, but forcing poor people to own cars just to make it to work is not a good way to help them.
Price parking at the market rate. Political competitor criticizes you for being an "eco-dictator" and promises a return to free parking. You lose the next election.
Sorry for the cynicism, I'm actually for increasing the price of parking, but recent political events have robbed me of any illusions that environmentally friendly policies have a future. When they have a choice between the environment and paying less money (short-term), most people will choose paying less money.
Outside of maybe a couple urban areas like NYC, that's patently untrue in the United States. It would not surprise me if the poor frankly had more and older/rougher cars than their more wealthy counterparts.
One of the ways it benefits them is by reducing traffic congestion so buses can get through. A significant amount of traffic in parking-contested areas is from cars looking for parking.
Java (+Kotlin) for Android, Python for its automation and tooling (and obviously, data.) These aren't very low-level - For Android there is always C++ if you want to go down to metal.
Ah that's interesting. And there is ofc Swift and ObjC for Apple devices. Maybe I should get into app dev.
Thanks. Do you think there is a strong market of Android/iOS native app development? As a DE I don't think my previous experience worths much -- maybe a bit more when we move to Flink which uses Java, and the might would rather hire new graduates instead of me.
Data is still a big thing, but nowadays vendors successfully removed most of the management because people just want to get things done, so a lot of companies are moving to Snowflake and similar places. You basically do some click ops and hopefully shit sticks on the walls.
Interesting if you just like data, but bad if you like the tech beneath. I'd recommend moving away from DWH part of data engineering if you can, and focus on OLTP, streaming which are more technical. The culture is also different.
I feel like the biggest misstep that the Scala ecosystem and Typesafe/Lightbend did was that they didn't invest more in Play Framework. 10 or 12 years ago, Play had a lot of energy and momentum, and it's a kind of thing that has broad enterprise/start up appeal. But focus was always more on Akka and what seemed like really niche architecture astronaut stuff like Actors and Actor System Clusters and Event Sourcing etc, rather than getting the basics to be super ergonomic or productive.
If they had keep just making Play Framework better and better and focusing on the practical problems that every web service faces, they could be in a similar great position as Laravel is in today or any of the many Rails/Laravel consultancies.
> I feel like the biggest misstep that the Scala ecosystem and Typesafe/Lightbend did was that they didn't invest more in Play Framework. 10 or 12 years ago, Play had a lot of energy and momentum, and it's a kind of thing that has broad enterprise/start up appeal. But focus was always more on Akka and what seemed like really niche architecture astronaut stuff like Actors and Actor System Clusters and Event Sourcing etc, rather than getting the basics to be super ergonomic or productive.
I'd say the opposite. They pushed Play a lot. But it was never a killer app, and it never even really leveraged the strengths of Scala.
People and especially companies don't switch languages for "super ergonomic and productive". They switch because they want to do something they can't do in their current language. I'm not a fan of Akka or Actors, but it made for some incredible demos that you really couldn't do in anything else except Erlang.
Hmm. Fair point for Rails and Laravel (whereas I think React had a killer app in terms of being able to make SPAs without going crazy) but those are tools that you can pick up for a one-off throwaway project - indeed I suspect most adopters didn't "move" to them so much as start doing projects in them and eventually stop doing projects in other things. Scala was never really competing in that space - I don't think anyone would ever say "let's make our website for the next tradeshow in Play" - it's a "heavy" language that needs an IDE and deep familiarity to get the best out of it (and partly that's also what JVM folks would be expecting). So it needed to play for the big core codebases, and for a while it did (particularly when there was no alternative to Spark).
Could they have made Play an alternative to Rails for one-off throwaway websites? Maybe, but the thing that would have needed to be different wouldn't be pushing Play itself, but rather lighter tooling and making it easier to get from zero to pages being served. Honestly I struggle to see how they could've done it without making the compiler and build tool much faster, and either making the IDEs much more efficient (difficult) or making the language easier without an IDE (difficult, and would risk splitting efforts). And even then, you wouldn't really show the compelling advantage of Scala, which is fearless refactoring in large codebases. I don't know that it could ever have been better than Rails at what Rails does, and also we already have Rails. Whereas even if it eventually "dies", Scala has already pushed Java and Kotlin to be much better than they were.
I mean, I don't find that working with IntelliJ makes it any "heavier" than other languages in terms of prototyping. I use PHP Storm for Laravel development and I never say to my self, "if only I wasn't using an IDE, maybe I could get this site put together faster". Quite the opposite, Intellij makes me super productive.
I think all of these frameworks - Laravel, Rails, Django, Next.js, Spring - require deep familiarity to get the best out of them.
> Honestly I struggle to see how they could've done it without making the compiler and build tool much faster
Well, Lightbend literally was the owner of Play, SBT, and Scalac. They were in a perfect position to make the build tool and compiler much faster. Or even if SBT can't be made much faster, ditch it and make integration with gradle and/or maven really great.
> I use PHP Storm for Laravel development and I never say to my self, "if only I wasn't using an IDE, maybe I could get this site put together faster". Quite the opposite, Intellij makes me super productive.
But the first time you tried out PHP, did you have to install the IDE first? Did you have to change your existing PHP tooling setup the first time you tried out Lavarel?
I would agree that IDEs are an improvement over not using them in most languages, but my feeling the "tooling curve" is much steeper for Scala than for something like PHP.
Play's hype did more harm than good. I work at a company that has many legacy projects in Scala because we were/are heavily invested in Spark, and Play is a disaster overall.
- The churn caused by breaking changes in minor versions used to be annoyingly high.
- Slick looks neat at first but caused a lot of friction when used by less experienced developers.
- The fact Akka is in your dependency tree encourages people to reach for it and raw actors are usually a bad choice. Akka streams work well for websockets and SSE but it's another footgun.
Additionally:
- It was in state of semi-abandonment for several years before Lightbend gave the project to the community. Even though there are/were big companies deploying Play apps at scale, for instance Apple.
- The introduction of Guice (in 2.4 afaik) was a terrible mistake, completely unnecessary and at odds with the Scala philosophy. Sure you can not use it, or use something else (like macwire) but defaults matter.
- Play-JSON depends on Jackson which is annoying in the JVM world, causing binary compatibility issues when you have diamond dependencies.
- Standard library Futures are not so nice when you've experienced anything else (Scalaz Task, Cats IO, ZIO, even Twitter Future...)
- Code generation from routes files is an odd choice when Scala has always been expressive and DSL friendly.
- Swagger/OpenAPI integration is brittle.
I've personally used Tapir since 2019 and couldn't be happier. All Play apps still running at my company are being abandoned or replaced by Spring/Java projects.
Tapir looks nice, didn't know about. Can I ask, do you use it together with Netty? How fast is it for you? (if you happen to have benchmarked it)
Have you tried Vertx with Scala? (Or Spring + Scala, or sth else?)
> The introduction of Guice
Personally I've wired everything statically at compile time, zero dependency injections. (Felt as if what I did went a tiny bit against the framework, but works fine.)
I use Tapir with http4s as the http server isn't my bottleneck anyway and I like Cats Effect and fs2.
But SoftwareMill has done extensive benchmarking to make sure the overhead from Tapir vs calling the http backend directly was insignifiant. I believe Netty is the recommended backend if you want direct style (i.e no effect systems) on Java 21+ virtual threads even though Oracle's Helidon Níma is supported too.
Thanks! Ok, seems direct style is what I would want, after having asked an LLM: it says it's then simpler to debug async call stacks, with Java 21+ virtual threads.
Nice to know that there are good alternatives, if time it is some day to migrate away from Play.
Totally agreed, Slick is definitely not a good way to access the database. It massively over complicates things and was a massive oil spill that destroyed the maintainability of many codebases. But that's not really Play, specifically, just a library that lots of people used with Play. I personally was always more a fan of https://scalikejdbc.org/, if not just plain JDBC
> It was in state of semi-abandonment for several years
Yes, this is my main complaint. I remember on the front page for like 5 years after TypeSafe Activator had been totally removed from the internet, the Play website was still showing Activator commands. To this day, the Play site still hasn't removed their line about how they support CoffeeScript and Less.
> Guice (in 2.4 afaik) was a terrible mistake, completely unnecessary and at odds with the Scala philosophy
> Play-JSON depends on Jackson
> Standard library Futures are not so nice
Well, it turned out that the Scala Philosophy wasn't the be-all and end-all anyways, and was always changing (at some point DSL's were in, then they were out. The way people encode TypeClasses changed over the years, selectDynamic/applyDynamic were in and then they were out, symbols were everywhere and then deprecated, implicit conversions were in and then "best practice" switched to Converters) and there was always at least 2 camps who had very different philosophies. Guice is probably the most popular DI tool in the JVM world so seems to make sense to use it.
The Jackson dependency and Scala Future's shortcomings might be annoying to many, but I don't think they really hindered adoption. Even in your case, what happened? At your company they're ripping out Play and replacing it with Spring, which uses DI very similar to Guice, probably depending on Jackson, and using java Futures (if they're doing async at all).
It's true some Scala features or patterns fell out of fashion but I don't recall any time where replacing compile-time logic with annotation based runtime reflection was considered a good idea. And I don't think Guice was ever the most popular JSR-330 implementation, at least not when Play started using it. Spring had been dominating the Java world for several years by then. Funnily enough in the Android world I remember Dagger being very popular exactly around that time as people figured compile-time automatic DI is a lot saner than Guice.
Of course Spring is another can of worms entirely and I find many aspects infuriating. But things like diamond dependencies are less of an issue thanks to Maven BOMs which are common in the ecosystem.
My point is that ~10 years ago people started using Spark at my company, got curious about Scala and thought Play was compelling. Nowadays Spark (in Scala) is less ubiquitous and these teams remember that so many people got burned by Play before.
Funnily enough the peak of Scala's hype which I believe plateaued between 2014 and 2019 before dropping sharply was mainly driven by:
Spark: ground breaking in many ways but has become a huge liability to the ecosystem, holding so many libraries back. Databricks is also the main financial contributor to the Scala Center (I believe) while not giving much of a damn about the community or Scala 3 altogether. Spark is a very frustrating piece of software overall and today 95% of users are in PySpark anyway, avoiding JVM dependency hell being one reason.
Play: good idea, questionable execution, poor governance, and today mostly irrelevant to the future of Scala. Props to community maintainers who managed to secure funding and brought the framework back from the dead, saving many projects from a certain death.
Akka: also ground breaking, pretty much the only game in town if you need stateful cluster sharding, deployed at scale by top-tier companies. But also overkill for most people, and on top of that the relicensing really hurt the community and broke trust.
I use Play, and I think it is a good web framework, nowadays.
In the past, however, upgrading to new versions, was annoying, because of pretty big changes in the API. (Don't know if this is what GP had in mind though.)
And even worse (I suppose) for people who were using the different ORMs which have come and gone, instead of plain SQL.
Akka has been annoying too: Adding WebSocket to my project, using Akka, was extremely much more complicated than doing the same in Nodejs (at least looking at the Nodejs docs I've seen).
Today, to me, Play is feature complete and all I want is maintenance updates (and performance optimizations but not so important). And yes, that's how things look right now: Some bigger companies pay an open-source maintainer, so Play gets regular maintenance updates, but not any annoying major API changes (or so I hope), nice.
Play has become boring in a good way? :- ) (Thinking about some "Use boring tech" HN posts.)
Totally agree. I wrote a few Play apps way back when and really enjoyed it. I was so excited about the future of the framework and how it would beat out Java for web apps, and steal folks away from the Rails ecosystem.
And then it just…stopped. Not sure what happened there honestly.
The thing I always get stuck on with these techniques is, how do you handle transactions which perform validations/enforce invariants on data when you’re just writing writes to a log and computing materialized views down the line? How can you do essentially, an “add item to shopping cart” if for example, users can only have max 10 items and so you need to validate that there aren’t already 10 items in the cart?
This all sounds to me very close to the event-sourcing/CQRS/DDD area of thinking. In which case you look at it in two parts:
- Event firing: Here is where you fire an event saying that the thing has happened (i.e. item_added_to_cart, not add_item_to_cart). Crucially, this event states the thing has happened. This isn't a request, it is a past-tense statement of fact, which is oddly important. It is therefore at this point where you must do the validation.
- Event handing: Here you receive information about an event that has already happened. You don't get to argue about it, it has happened. So you either have to handle it, or accept you have an incomplete view of reality. So perhaps you have to accept that the cart can have more than 10 items in some circumstances, in which case you prompt the use to correct the problem before checking out.
In fact, this is typically how it goes with this kind of eventual-consistency. First fire the event that is as valid as possible. Then when handing an 'invalid' event accept that its just got to happen (cart has 11 items now), then prompt the user fix it (if there is one).
Not sure how helpful this is here, but thought it a useful perspective.
You're not "just" writing to a log. You always need a view of the state of the world to take decisions that enforce invariants (in this case, the "world" is the cart, the "decision" is whether an item can be added).
What you'd do is, when you receive the "addToCart" command, construct the current state of the cart by reading the log stream (`reduce` it into an in-memory object), which has enough data to decide what to do with the command (eg throw some sort of validation exception). Plus some concurrency control to make sure you don't add multiple items concurrently.
For reading data, you could just read the log stream to construct the projection (which doesn't need to be the same structure as the object you use for writes) in-memory, it's a completely reasonable thing to do.
So at the core, the only thing you persist is a log stream and every write/read model only exists in-memory. Anything else is an optimization.
DDD calls this "view of the world" an "aggregate". Reading the log stream and constructing your aggregate from it is usually fast (log streams shouldn't be very long), if it's not fast enough there's caching techniques (aka snapshots).
Similarly, if reducing the log stream into read models is too slow, you can cache these read models (updated asynchronously as new events are written), this is just an optimization. This comes at the cost of eventual consistency though.
This kind of thing only works if your whole universe belongs to your database.
Transactions and conditional-updates work smoothly if it's your customer browsing your shop in your database - up to a point.
But I usually end up with partner integrations where those techniques don't work. For instance, partners will just tell you true facts about what happened - a customer quit, or a product was removed from the catalogue. Your system can't reject these just because your Db can't or won't accept that state change.
But if you did you'd need an aggregatable (commutative) rule.
Like you can't aggregate P99 metrics. (To see why, it is similar to why you can't aggregate P50. You can't because a median of a bunch of medians is not the total median)
So you measure number of requests of latency < 100ms and number of requests. Both of these aggregate nicely. Divide one by the other. Now you get Pxx for 100ms. So if your P99 target was 100ms you set your 100ms target to 99%.
Anyway you'd need something like this for your shopping cart. It is probably doable as a top 10 (and anything else gets abandoned). Top 10 is aggregatable. You just need an order. Could be added to cart time or price.
I was thinking about this as well as these streaming things become more popular. Would you write add-to-cart events and those trigger add-cart events; the latter containing an valid field which will become false after the 10th add-cart. So after that you remove-from-cart which triggers add-cart which then becomes valid again < 11 items? And transactions similarly roll back by running the inverse of what happened after the transaction started. I'm just thinking out loud. I understand you probably wouldn't use this for that, but let's have some fun shall we?
All systems I have worked on like this has some concept of a version number for each entity / aggregate.
So you get that the account_balance was 100$ on version 10 of the account, and write an event that deducts 10$ on version 11.
If another writer did the same at exact same time, they would write an event to deduct 100$ at version 11. There will be a conflict and only one version will win.
This is exactly like any optimistic concurrency control also without event as the primary storage.
Didn't check if the system linked to supports this, I guess it might not? But this primitive seems quite crucial to me.
I assume that shopping cart limit is a made-up example, but I'm curious what preconditions are you actually enforcing in the real world via DB transaction rollback?
add_item is not an event, rather a command/ request that is yet to be validated. item_added is the event = a fact that was 'allowed to happen' by the system.
Keeping commands in a persistent store is a matter of choice but not necessary. I've seen people doing command sourcing and calling it event sourcing.
The fact that there are other ways to work around previous limitations to accomplish something doesn't render the use-case invalid. The GP was asking for a usecase outside of currency and one was provided. If a valid use-case for electricity was asked, and someone described a lightbulb, you could just as well say "...or, you could just use an oil lamp"
If Bitcoin is a ponzi scheme because of this, then literally every asset which has resale value is a ponzi scheme.
When people buy bonds, stocks, commodities, or purchase a car, a house, or even an Xbox, they are taking into account the resale value of that asset. If you supposed that when you're done with your house, it would be worth $0, you would be willing to pay a lot less for it. There's nothing fundamentally different here wrt Bitcoin.
A house produces value; you can either rent it out, or live in it (thus avoiding paying rent to someone else). Stocks produce value; the companies make money (and generally either pay dividends, buy back stock, which is just a tax dodge approach to paying dividends, or invest in growth, and will thus eventually be in a position to pay more dividends). Bonds produce value; they are literally loans which (hopefully) get paid back. All of this allows a value to be assigned to them; that value may be greater or less depending on market conditions, demand, future value of money, etc (for instance, if your house is in the middle of nowhere and, by the time you’re done with it, needs a new roof and windows and so on, then its market value may actually approach zero). Things like bitcoin are different in that they do not produce value. You can’t value bitcoin based on X years of expected dividends/quasi-dividends or anything; any value is purely speculative.
To be clear, there’s speculation involved in buying stocks, too, to an extent (particularly buying _individual_ stocks), but ultimately you have a share of some real thing. That is not the case with bitcoin.
Sure, there's some value there, you can use it to make gold-plated contacts or shiny things, but if that was the only use case, it wouldn't be nearly as valuable as it is now.
Gold is valuable because people think it is valuable, and the same hodls true for Bitcoin.
Gold is probably the closest conventional thing to bitcoin, yes, though it does have _some_ intrinsic value as an industrial material, which sets a floor. But yes, gold’s value is basically speculative, and you’re largely relying on a greater fool.
You also shouldn’t buy gold; over any long period it is almost guaranteed to massively underperform the markets. If you had bought gold at its 1980s peak, you would have been down in real terms ever since; adjusted for inflation it has never reached that value since, and may never do. While you can say that about some individual _companies_, of course, you would be hard pressed to find a major index for which that is the case.
> If you had bought gold at its 1980s peak, you would have been down in real terms ever since; adjusted for inflation it has never reached that value since, and may never do. While you can say that about some individual _companies_, of course, you would be hard pressed to find a major index for which that is the case.
The Nikkei 225 comes to mind. It only broke its 1989 peak last year.
You really don't want a financial crisis in banking. All those regulations that crypto folks want to get rid of keep things like what happened to Japan in 1990 from happening with more regularity. Even 2008 in the US was painful and very long recovery, and mortgages were a smallish part of the overall economy.
The claim that we are disagreeing with is that Bitcoin is meaningfully different from any other investment in a way that makes it a Ponzi Scheme. I'm not trying to persuade anyone that it's a good investment, just that it isn't a ponzi scheme any more than gold, oil, real estate etc is.
I don’t think bitcoin is a deliberate Ponzi scheme, but it does have Ponzi scheme-like elements, in particular the absolute dependence on a greater fool to take it off your hands, with value _purely_ being based on what other people imagine it to be worth (ie not backed by any intrinsic value). Gold, yeah, isn’t a million miles away from this, either (as I mentioned previously, historically it is a _bad_ investment) though it does have the benefit of a few millennia of cultural cachet, increasing the chances that there’ll be a greater fool along soon.
Oil and real estate are totally different, though investment in oil in particular _is_ rather speculative; you’re betting on future real demand, but that demand is at least, like, _real_; there are obligate buyers of oil, almost no matter how high the price goes. Real estate, as I previously mentioned, produces value in terms of either rent or not having to pay rent.
The difference is that Bitcoin only has resale value.
The other examples you mentioned generally have some significant additionally value beyond just resale value -- e.g. stocks pay dividends or are expected to at some point, a house is something you can live in or get an income from by renting it out, and so on.
Bitcoin's use is as a store-of-value. That's it's utility. It has the traits of an ideal store of value. Eventually we may use it as money, but that won't happened until it is much closer to it's ultimate value and the value as stabilised enough to use it as a unit of account.
Take up an interest you can do socially and really dive deep into. For me, I easily made friendships with people after taking up viola and joining an amateur adult beginner orchestra. For you it might be rock climbing, or guitar, or maybe you could join a local crochet group if you’re into that.
I love programming too, and used to go to meetups before covid, but I think the music crowd for me has been easier to turn into a social thing.
I mean, this is like telling an obese person to just exercise and lose weight. Fact is, while it is that simple to those who are already doing it, to them, it is not that simple. The activation energy to the hobby can be immense and may require the person to change their entire lifestyle to accommodate it. For example, an obese person who suddenly exercise may come to work the next day worn out and less productive. They will also feel hungry and more irritated since they are not yet used to it and this can affect their social interactions. Eating becomes difficult and less enjoyable as they have to watch their calories intake and food type. Sleeping is harder with the hunger, etc.
I can fast almost everyday and I feel nothing even if I skip breakfast and lunch for the whole week. But I came to know many healthy people who hate to do the same to the point they can't do it even if they want to. Extrapolate, I understand what is easy and feel low effort for one person is not the same to someone else who is accustomed to the exact opposite. It takes more than just stating the obvious to help them.
But there’s really no way to get around it. Yes, you’ll have to put yourself in uncomfortable situations. There’s no one simple trick that’s going to mitigate that and trying to find a path that’ll get you there without discomfort is only delaying the inevitable.
Well we see the results of that in this article, I suppose.At some point we either accept the world is getting lonelier or adjust societal affordances to make them want to go out.
