jon_smark

Sorry to nitpick, but for a good Bayesian, absence if evidence is evidence of absence. If you want the aphorism to be technically correct, you should say "absence of proof is not proof of absence".

A note on the terminology: "evidence" is a piece of data that suggests a conclusion, while not being conclusive by itself. Whereas "proof" is a piece of data that is conclusive by itself.

Thanks for the reply. I hope that the array and list comprehensions land soon in upstream; it's a useful and hopefully not-too-controversial feature.

I'm more ambivalent regarding the local allocations and the unboxed types. I totally understand why they'd be useful when you are trying to squeeze every last drop of performance, but they do require a not-so-trivial complexification of the language.

Thanks for the reply. I'm hoping that modular macros land soon. I'm very ambivalent about the PPX mechanism, and I hope that modular macros reduces the need of PPX.

Are the plans for typed algebraic effects solidifying, or are they still nebulous? Concretely, are you willing to take a guess as to when we are expected to see OCaml 6? ;-)

Congratulations and a big thank you to the OCaml team! I hope that multicore support finally ticks all the requirement boxes that had prevented many from taking a serious look at OCaml. The language certainly deserves it: it hits that sweet spot between expressiveness, performance, and pragmatism like no other.

I have to interject here for the sake of those unfamiliar with OCaml and who may take the parent comment at face value.

Saying "it has quirks like using ;; to end statements" is misleading to the point of just being bogus. The double semi-colon is only ever used in the REPL. In fact, I've been programming OCaml for fun and professionally for over 15 years, and I've never used a double semi-colon in my code, nor have I ever encountered one in the "wild".

> Conversely OCaml is an interpreted functional language.

Correction: OCaml is not an interpreted language. OCaml programmes are compiled down to native code (or bytecode, or Javascript).

Quite on the contrary: The OO part of OCaml is hardly used at all in the wild!

Indeed. Considering the volume of transactions going to and from Coinbase, their adoption of Segwit would go a long way towards alleviating the current mempool situation, which would bring lower fees for everyone.

As others have pointed out, your understanding is backwards. Mining is heavily centralised already (in China of all places!), and larger block sizes would only exacerbate the mining centralisation, which is probably why the biggest fans of larger blocks are the Chinese miners.

> Segwit isn't a a block size increase. It allows for a tiny amount more transactions but it's very clear it's not enough. An actual block size increase (say to 8MB) would solve the current problems.

But what about the new problems it would introduce? I run a full node and even now it eats a significant portion of my bandwidth. With even larger blocks I would probably drop off the network altogether. And I'm sure I'm not the only one out there in this situation. Therefore, I don't think Core developers are exaggerating in their concerns about the centralization pressure caused by overly large blocks.

Moreover, wouldn't increasing the block size simply kick the can down the road? One advantage of the current fee pressure is that it strongly encourages the development of 2nd layer solutions. There are right now at least three independent teams working on Lightning Network implementations and they seem to be making quick progress...

What about pandemics? (Either natural or engineered.)

> It's a pyramid scheme in a sense that you depend on others to keep buying the bitcoin.

Please don't use the expression "pyramid scheme" lightly, because there are actual pyramid schemes out there, and we want the expression to keep its power so we can warn people against them.

Bitcoin may be in a bubble, but it's definitely not a pyramid scheme.

OCaml has great support for concurrency (check out Lwt or Async libraries). Do you mean parallelism, perhaps?

And yet the Pentium G4560 -- one of the cheaper models of their Kaby Lake lineup -- supports both ECC and non-ECC RAM. I suspect the only reason behind lack of ECC support on their mainstream processors is just market segmentation.