greenfield1
> That's exactly what they did.
You have read the article, right? It starts with showing how it looks like in C++ and then goes on with the revelation "In Rust on the other hand ...". Literally. This strongly suggests that what they are getting at is a language feature that sets Rust apart from C++.
Wages are where the two parties met. It's high enough so the seller of the good (employee) is ok with selling and it's low enough so the buyer of the good (employer) is ok with buying. As long as they do business with each other, they are apparently both deciding, rationally, that this is an acceptable deal. Better than the alternative.
> Workers are leaving because they can't afford it, not because they want to stratify their families and leave their homes.
Great that they are leaving! They should be leaving! Cause then, and only then, will businesses be driven closer to raising wages since the sweet spot in the above equilibrium moves upwards.
> For those thinking this is the market successfully working: has the market successfully worked in the Bay Area? How does SF look right now?
Well in the Bay Area, the market is highly distorted. Lots of NIMBY zoning rules preventing high density housing being built. People sitting on detached homes because they can't afford to move. This heavily distorts housing costs which then impacts salaries since all those tech workers need to live somewhere. Big tech and VC-funded not-as-big tech is floating in money, so can afford to push salaries/compensation higher and higher. It's the market, but it's not pretty and it's heavily distorted.
Because that's where you have your social connections. Friends, family. That's where your home is, your parents lived there, your grandparents lived there, you grew up there. And you hold out for better times. And that's why you can be exploited like that.
That's the "not rational" part. The humans participating in the market are not "rational", for some odd definition of the word. But if you think through motivations, they are rational, if you put value in the reasons why people do this kind of job in this kind of situation.
Ever been to a gas station? That raised the price multiple times a day just like the other gas stations a few hundred yards away? Same principle. Doesn't need price fixing as explanation. They are just all buying the same raw product.
A type checker would amount to an automatic correctness proof, which in its full generality is impossible (by halting problem), but for the practically interesting classes could be done using a theorem prover / proof assistant and the occasional hint from the programmer. That would be great to have, but none of the examples you mention is anywhere close.
In the ideal program, only legal states are reachable. If you can use your type system to prevent to ever run into an illegal state, then you have won quite a lot. This is basically the holy grail of programming. Not sure we'll ever get there though.
The `pins.d13.into_input();` part just returns an object/reference/... of a type that only has input-specific methods, while using `.into_output()` would do the same with only output-specific methods, correct? That's nice, but why couldn't you do the same thing in C++?
With a dependent type you could do `pins.d13.into(INPUT)` and get the input-specific type, but that seems to not be something Rust could do?
Python allows recursion too. Are you using recursion? Why not just write it in Haskell?
Python allows function calls too. Are you using function calls? Why not just write it in a functional language like Haskell?
A monad is just a general programming concept, like recursion and function calls. One particular language pioneering the concept's heavy use doesn't mean other languages can't adapt it. To the contrary, languages get influences from one another all the time. Especially Python.
Do you like list comprehensions? This super-pythonic thing? Goes back to functional languages in the 70s and the name was coined by Philip Wadler, one of the main Haskell gurus. If you like list comprehensions, this feels like trying to write Haskell code in Python. Why not just write it in Haskell?
Of course this leads to accumulation of wealth, which can be an issue for society if it goes to far. And I agree that that's happening and that we can't turn a blind eye to it. But the solution here is not to make villains out of investors, but to tax profits. Seems to be hard to get that into peoples heads though, especially in the U.S. where taxes are always viewed as something bad.
But the Maybe monad does have its beauty, which the in-built Optional doesn't really provide. If this package makes people more accepting, then let them.
It's like saying "well I'm only asking for market prices" when offering somebody to sell some stock to for 100 USD even though they and everybody around them only want to pay 50 USD. That doesn't make 100 USD the "market price". Only if you've seen some recent trades for 100 USD, then it's the "market price".