The word "blockchain" works just like the word "computer". You can have a blockchain or multiple blockchains, just as you can have a computer or multiple computers. And you'd refer to "blockchain technology" just as you'd refer to "computer technology."
It is interesting how Go seems to be doomed to head down the same path as other languages it accused of being "bloated." No one intends to design a complicated language but the reality is that the problem space is complicated.
The only thing that isn't so forgivable with Go is that these aren't new problems this time around. Go is still struggling to get over challenges that were first seen a long time ago. It's a great experiment on designing for complexity vs trying to avoiding complexity.
> It is interesting how Go seems to be doomed to head down the same path as other languages it accused of being "bloated." No one intends to design a complicated language but the reality is that the problem space is complicated.
It's not surprising, it stems from the arrogance of Go designers who think they can eliminate complexity by deeming it irrelevant and making the user carry the weight of the complexity they refuse to deal with. Simplicity isn't hard, like Rob Pike says, it's a trade off.
If you're not going to have enums in your language for instance, you are forcing your users to implement their own, badly and in incompatible ways.
If you're not going to have generics, well you'll get this stupid situation where users are expected to "augment" the compiler with code generators, leading to an increase in complexity in building a program, or worse, ignoring compile time type checking since it's the path of the least resistance when dealing with generic container types.
There are a few misguided views in this article and in some of these comments.
1. Every shardable database (Cassandra, Dynamo, BigTable) has to worry about hot spots. Picking a UUID as a partition key is only step one. What happens if one user is a huge majority of your traffic? All of their reads/writes are going to a single partition and of course you are going to suffer from performance issues from that hot spot. It becomes important to further break down your partition into synthetic shards or break up your data by time (only keep a day of data per shard). BigTable does not innately solve this, they may deal better with a large partition but it will inevitably become a problem.
2. Some people are criticizing the choice of NoSQL citing the data size. Note you can have a small data size but have huge write traffic. An unsharded RDBMS will not scale well to this since you cannot distribute the writes across multiple nodes. Don't assume just because someone has a small data set they don't need to use NoSQL to deal with their volume
> Every shardable database (Cassandra, Dynamo, BigTable) has to worry about hot spots.
Yeah, but the issue with DynamoDB seems to be bursts of access triggering "throughput exceptions" caused a very static bandwidth allocation which is going down with the number of shards and not so graceful handling of overload situations.
It is imho. an anti-pattern to split up the bandwidth like they do. It negates the multiplexing gain for no good reason except a rigid control model.
It depends a lot of the write. If they can be batched, you can put them in a queue or in redis until it reach a threshold and write the update down in the RDBMS. It won't work for all the use cases, but more often that people think.
Yes microbatching is a great way to get a fixed write rate regardless of traffic, can even do it right at the application layer. The trade-off is that you can theoretically lose one interval of data when your service goes down. This might not matter for analytics workloads with a margin of error but some usecases require confirmed writes
But when you are just taught to use libraries and technologies without having some exposure to he principles behind their inner workings, it's easier to fall in cargo cult.
I can't speak for every student at every university, but my university is in the top 50 of csrankings.org and yet even in my junior-level courses there are loads of cargo-cult programming students. They think they understand things like compilers, operating systems, and so much more, and they delude themselves into having those beliefs based on things like "I'm in CS; of course I understand $THING" or "I'm at $UNIVERSITY and we've learned so much, so I definitely understand $THING". In reality, if you mention "ELF", most of them would probably think you're talking about a special type of new line, and the only thing they think "IR" could possibly stand for is "infrared"
It gets even worse when you get on the topic of "Computer Architecture" - so many people think they can talk to their computer on a deep level, without realizing that what they're learning in class (MIPS) is actually not what their computer understands!
Implementing aggregation at query time is a temporary solution. For systems like this aggregation should be done on insert time - many hugely popular databases do not provide much more than a basic get operation for this reason
Yeah I don't get why they're marketing to Mongo users, weird choice. This is a DB for companies trying to moved to a query-less architecture - something no one should be doing with mongo
Databases in this category are some of the most popular ones in the world with good reason. The only way you can scale is to adopt a query-free architecture.
It feels tedious at first but once you develop some good habits and frameworks around denormalization it becomes easy to do that from day one.
>> The only way you can scale is to adopt a query-free architecture
This is not really the case. There are database systems that can handle large scale and complex queries. Allthough usually at the price of providing reduced consistency guarantees.
I do hope you'll read the article regardless!