News for hackers. Stuff that matters.
Re:Adding Optimistic Locking to an API by quadrature on Thursday August 26, 2021 @10:45AM (#28315608)
It definitely a scary proposition. But it's worth mentioning that two of the world's biggest money moving platforms (Stripe and Shopify) are written in ruby.
Re:Adding Optimistic Locking to an API by valenterry on Thursday August 26, 2021 @10:58AM (#28315763)
Stripe decided to write a type checker for it though, probably for good reasons: https://sorbet.org/
Re:Adding Optimistic Locking to an API by judofyr on Thursday August 26, 2021 @11:52AM (#28316520)
It should be mentioned that their reasons were mainly developer convenience/productivity, and not “correctness”.

I think people severely overrate the value of the language when it comes to avoiding bugs. We already know how to minimize bugs: Extensive testing regimes (automated, manual, or both) and a general focus on correctness over “shipping on an artificial deadline”.

Re:Adding Optimistic Locking to an API by karmakaze on Thursday August 26, 2021 @07:55PM (#28322580)
You can have something that aids convenience/productivity and not correctness. You can also have something that aids correctness that increases developer convenience/productivity. I treat static typing as the latter.

Edit: Btw, the github.com/sorbet/sorbet project is really well run and surprisingly easy to get into. I've been drafting PRs. C++ is not nearly as rough as I remember from decades ago.

Re:Adding Optimistic Locking to an API by nradov on Thursday August 26, 2021 @12:53PM (#28317427)
Ironically, advocates of dynamic typing often claim that it improves developer convenience and productivity.
Re:Adding Optimistic Locking to an API by quadrature on Thursday August 26, 2021 @11:36AM (#28316274)
Yup, also being used at Shopify. Types are awesome, but these companies got very far by betting big on the productivity of ruby before this became a concern.
Re:Adding Optimistic Locking to an API by valenterry on Thursday August 26, 2021 @11:44AM (#28316392)
Not claiming that ruby isn't productive, but I could as well rephrase that into "these companies got very far despite the lack of productivity of ruby before this became a concern". It's not really giving any new insight.