jonreem

outside of trivial transfer transactions there are much more complicated things you can do with smart contracts such as decentralized lending and decentralized exchange of assets

these are more like arbitrary atomic changes to on chain state that can affect many wallets and different contracts (and depend on the existing state) rather than just a transfer from my wallet to another address, which can be reordered freely

see protocols such as uniswap, compound, aave, synthetix, sushiswap, liquity, etc.

these are transactions with extremely high value and often extremely urgent and not possible to merge together - e.g. the both liquidate the same unhealthy loan position (could be worth ~$10m+)

the whole point is it's not remotely easy to just "reconcile separately" when you have two mutually exclusive financial operations - these are not code changes made by mutually cooperating developers happy to change their code to resolve merge conflicts, they are actively fighting against each other

edit: this also point out how having a centralized entity decide the ordering of transactions is a horrible idea - sequencing is worth enormous amounts of money and you could not be trusted to resolve transactions in a way that is sometimes against your interests but in the interest of other participants in the network

Settle positions between two mutually non cooperating parties. Your github solution doesn't consider that many non cooperating parties may want to do conflicting things on chain and you need a trustless way to resolve those conflicts. First writer wins to a centralized database at github is not an acceptable settlement method for billion dollar transactions.

EDIT: A blockchain is not just about keeping a history, it's also about maintaining liveness of the chain and preventing censorship even when many non cooperating parties are involved with conflicting incentives.

Nobody clicks the space bar 8 times, they use the tab key and have their editor insert the correct number of space characters instead.

The time-value still comes into play in the form of eth transaction fee. If you're flash loaning to take advantage of an open arbitrage opportunity there will be other parties trying to take advantage of it, so you will pay more to get your transaction in before theirs.

For a lot of transactions like this its actually miners who can detect and rewrite these transactions to take advantage of the arbitrage opportunities first, for this reason this cost is called "miner extractable value" or MEV.

However, note this fee doesn't accrue to the lender!

Personally, I've developed a strong preference for putting this type of information as close to the affected code as possible. Immediately next to the affected code is the only place these types of comments have a prayer of being kept up to date. Keeping them in another document, a commit message, or anything similar just results in the content of the message instantly going out of date.

People who bother to complain are those who actually care about your thing. People who do not care simply leave without ever telling you why. Your complainers are often your most dedicated and invested users.

Thunk is not a proper solution to the problem - it's a totally open escape hatch! You lose ALL the nice guarantees and behavior of redux when "action" no longer means "immutable, serializable event" and starts meaning "completely arbitrary function call with unbounded async effects."

There's no functional difference between using redux-thunk and just calling a "global" `dispatch` in random callbacks; both are equally unmaintainable in the face of interacting effects.

EDIT: Having a bunch of complex async logic all modifying your store in overlapping ways without careful coordination is like having concurrent operations on your database without any transactions or locking.

We don’t appreciate impersonation on HN.

It wasn't my example, but it's just disproving the notion that FP somehow means you need to write big if statements to dispatch your functions.

Traits are not functional-language specific except in that they are often used in FP to solve problems similar to those one might use inheritance to solve in OOP.

One of the many difference is that there is no inheritance, and implementations of traits can be added for types long after they are defined. Traits in rust are not like java interfaces.

Also see `webpack` as a successful example of code-as-configuration in the wild.

This approach necessitates an ever growing number of increasingly specific APIs, or an ever growing set of flags and options which will inevitably approximate a poorly implemented version of GraphQL.

How efficient...

Hey, that’s my library! I’m glad to see a similar macro getting added upstream, so you no longer need to install libraries like this one for easy print debugging.