They are probably exchanges doing batch withdrawals (large number of outputs) or consolidating their holdings into a single large output for economic reasons (large number of inputs)
Most transactions will have two outputs. One is the actual destination and the other is change that goes back to the spender wallet. There is nothing unusual going on here.
Not sure which audience you are targetting but I would love to read more on modern compiler design. There is very little information on the web on how to design a compiler to provide good error messages and code intelligence features even in the face of incomplete or incorrect source code.
The US is much richer than 80 years ago, so it’s way more likely than billionaires come from comfortable middle-class families, of which there are many more now. If Warren Buffett or any of the others mentioned had been born the year Mark Zuckerberg was born, they would have probably enjoyed a similar upbringing.
There's a PubSub implementation for IPFS that can provide support for dynamic content in this case. I'm pretty sure there is another way to provide fast updates through some indirection mechanism though.
I have quite a few years of experience with Django and in general, I have found it to be quite easy to set up. I don't think you can avoid much of what you describe with any other template engine, in Python or any other platform.
I mentioned that no one had much experience with the implications of Ethereum's model and you point me to a bunch of articles but I fail to see how they apply to the case of Solidity.
What are the big ideas from E that Solidity is missing?
Also, the article by Nick Szabo has some interesting ideas, but as far as I understand, it does not describe a language for programming arbitrary smart contracts, just some notation for common financial contracts.
Speaking seriously, there is an assembly for Ethereum called LLL. I would love to see code that performs exactly that example you mention and is easier to audit than the equivalent Solidity version.
Not that difficult. There is not much point in creating immutable contracts since they act like singletons.
This is different from the kinds of objects that you would instantiate in a language like Java, where best practices suggest defining as immutable unless you have a good reason not to.
I may have enough funding to pay more that Brendan Eich is making right now. That does not mean that he will join my project. Good talent is scarce regardless of funding.
> This is true for Haskell, but "most" other functional languages don't suffer this issue: SML, OCaml, F#, Rust, etc.
I don't have much experience with the ML family of languages, so I may have jumped to conclusions based on my previous experience with Haskell/Elm, but I did not intend it to sound as a dismissal of functional languages at all.
In fact, there is a growing community of researchers working on functional language design for the EVM, but I would wager that it's way more complex to build such a compiler than something a bit more "close to the metal", especially since no one had much experience with the implications of the memory/storage/execution model of Ethereum at the time work started on Solidity, let alone the kinds of vulnerabilities these contracts would be exposed to.
Most of these observations are well-known to the Solidity devs. I know because I participate in many of the conversations around it. While it's not easy to evolve a language (the API surface is pretty wide compared to many other programs), Solidity is indeed changing and improving regularly, only limited by the available time of their contributors.
Being a good, secure language for writing smart contracts is absolutely one of the most important goals for Solidity. I can say so because I have been involved as a regular contributor to the compiler for more than a year. If onboarding a lot of people to the platform quickly were the goal instead, they would have ported some crippled version of Java or JS and called it a day.
The problem is that it's just not easy to get all those details right from day 1, and interest in Ethereum has grown way faster than its capacity to produce a reliable, mature set of tools around it.
None of the languages that you mention target the EVM, and the changes required to do so would turn them into restricted versions that look kind of like the original ones but have several differences that you need to keep in mind while programming in them. It makes quite a lot of sense to create a new language that takes advantage of the particular features provided by the EVM.
It's also quite hard for programmers to reason about performance or complexity in most functional languages. In the EVM, all functions should either be O(1) or bounded O(n) and should strive to use the most economical bytecode available to perform each task.
Disclaimer: I am a regular contributor to Solidity.
No, that's called end-to-end or client-side encryption. Zero-knowledge is a property of a certain class of methods that allow one party to prove to another that a certain statement is true, without revealing anything else about it.