Mike Hearn

> "Which works great, as long as those DSLs are complete, standardized, and mostly not leaky. In the spirit of your comment, I'll let you discover for yourself why that doesn't seem to happen."

Two reasons:

1. Computing is a relatively young field, and not all of the best practices have made it to the mainstream.

2. The quickest way to develop is to bolt additional code onto the side of a project rather than considering how the overall requirements for the software application may be better served by designing reusable helper functions and refactoring.

Also, I think you've dismissed Red a little too quickly. The GUI DSL is not the only factor that keeps the codebase compact. I'm using the word "compact" rather than "small" as I recognise that Red is still in its infancy, but with the word "compact" I'm trying to emphasise that Red does a lot with not a lot of code.

> "EDIT: As an aside, the Java 1.1 JVM was only about 15MB."

How big was the JCL (Java Class Library) at the same time? Also, 15MB for a VM on its own is not that impressive. Even Oracle have managed to make small (feature complete) VMs, for example:

https://blog.plan99.net/graal-truffle-134d8f28fb69

"The resulting runtimes have peak performance competitive with the best hand-tuned language-specific compilers on the market. For example, the TruffleJS engine which implements JavaScript is competitive with V8 in benchmarks."

"To give a feel for how easy it is to write these engines, TruffleJS is only about…

> --- Most of the BEAM isn't well-suited for trends in today's immutable architecture world (Docker deploys on something like Kubernetes or ECS). Bootup time on the VM can be long compared to running a Go or OCaml binary, or some Python applications (I find larger Python apps tend to spend a ton of time loading modules). Compile times aren't as fast as Go, so if a fresh deploy requires downloading modules and compile-from-scratch, that'll be longer than other stacks. Now, if you use stateful deploys and hot-code reloading, it's not so bad, but incorporating that involves a bit more risk and specific expertise that most companies don't want to roll into. Basically, the opposite of this article

I don't necessarily disagree with your reading of the trends, but if following the trends means losing the best tool for the job, maybe it's not the tool that's in the wrong. Re: deploy time, I don't think there's a need for deployed servers to fetch and compile modules --- you wouldn't do that for a Java or C server, you'd build an archive once and deploy the archive. I guess if you're talking about the speed of the build pipeline, I'd think the pieces in the build could be split into meaningful chunks so builds could be in parallel and/or only on the parts where the dependencies changed. I imagine BEAM startup itself isn't particularly fast at the moment, because I haven't seen a lot of changelogs about speeding it up, but I'm not sure there's a huge amount of perceived need there?…

> Well none of this has any effect on the bitcoin network now does it?

After having been stripped of most of the functionality that gave BTC it's original value proposition, you might be surprised at the degree to which it really does need ads like this to attract fresh investors.

BTC killed it's most powerful tool for cementing it's position as the leading cryptocurrency, it's network effect.

They killed it by merging "full replace by fee", making it trivial to cheat bitcoin-accepting merchants during times of higher network congestion. This made it even super risky for merchants and many opted out. They even had a much safer alternative (FSS-RBF) ready to merge.

* https://github.com/bitcoin/bitcoin/pull/6352

* https://blog.plan99.net/replace-by-fee-43edd9a1dd6d

They killed it by using the size of OP_RETURN to gaslight Counterparty, a company that was trying to build a rich smart contract ecosystem (yeah like Ethereum has now) on top of bitcoin. This was the second time the core devs' hatred of smart contracts killed new use cases for the coin. The first time led Vitalik to create Ethereum.

*https://old.reddit.com/r/decred/comments/6wxueo/your_best_pitch_for_decred/dmcerna/

They killed it by blanket censoring on all the big bitcoin related communication channels all discussion about increasing the blocksize and/or building/supporting alternative BTC full nodes. This censorship completely fractured the community and directly led to the network fork called…

> It is, of course, possible to create libraries that don't follow the idiom.

Yeah. Thing is though, there are these libraries who access pointers (especially in Go where lots of stuff are implicit pointers, like maps and interfaces). Or, may God strike them down where they stand, people who use division. Or allocate. Or cast. Or use interface{}. All such code has implicit (non-visible) panics in them.

What I mean to say is: in practice, Go code is not fundamentally different from Java/C++ code : everything can throw. Everything. Yes even that thing that you're thinking of right now that couldn't possibly ever think about throwing. There's just people who admit this and people who don't.

That the Go authors come up with idioms that are so incredibly shortsighted is emblematic of everything else about the language.

This is how Go works. They claim they are perfection, and know better than anyone.

For instance, compare:

https://blog.golang.org/go15gc

with

https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e

(just to put up something other than the generics discussion. But everything about go suffers from both massive deficiencies and an extremely arrogant development defending deficiencies ...)

For the past two years, the Bitcoin community has been embroiled in a debate about how to scale the network to handle more transactions. The debate has at times become less technical, rhetoric about "centralization" and the values of the community has become introduced, etc. Recently the debates have come to a head, and some have referred to it as a "Civil War"[0].

For technical background, I recommend these two posts by Mike Hearn, who has since left the Bitcoin community [1] [2]

Now, what the original article is talking about is the "Core" development team--the people who have commit access on the Bitcoin Github repo. The whole debate has essentially become Core vs. some other factions, mainly miners. You'll see the arguments in [1] and [2].

(Keep in mind, Mike Hearn is strongly on the anti-Core side of the argument. But those articles should give you an idea of what to search for, if you want to hear arguments on the other side.)

[0] https://www.bloomberg.com/news/articles/2017-07-10/bitcoin-risks-splintering-as-civil-war-enters-critical-month

[1] https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7

[2] https://blog.plan99.net/the-resolution-of-the-bitcoin-experiment-dabb30201f7

I'm curious why you chose to use the term "bcash" to refer to BCH. No exchanges or mainstream projects use that term to refer to BCH. As far as I'm aware it's primarily used as a pejorative, so it seems strange that you'd use it here.

As far as BCH's additional value: I'd suggest researching the block size debate. This debate is BCH's entire reason for existing. This article [1] from 2016 by Mike Hearn contains a good primer on the block size debate itself. He ended up quitting development of Bitcoin, but others decided to raise the blocksize limit - with or without the majority, thus creating BCH. Succinctly, BCH is the continuation of big-blocker's vision of the Bitcoin experiment.

[1] https://blog.plan99.net/the-resolution-of-the-bitcoin-experiment-dabb30201f7