The Forbes article is from April, while The Local article you're quoting is from October. Back in April, the proposal was different, as The Local explains.
And the biggest problem for startup founders remains: you're taxed, on leaving the country, on unrealized gains. Being taxed on 5 millions of profit sounds fair, being taxed on 5 millions (or 30 millions) of valuation used for raising capital, in a startup that then fails and is worth nothing after a few years, maybe not so much. Neighboring countries do not have this kind of taxation.
Looks like a competitor/alternative to Smithy, https://smithy.io/2.0/index.html. Since at least one person from the TypeSpec team is here, do you have any thoughts on how they compare?
This was my thought too - since smithy is already out there and used in a similar ___domain, it would be useful to have a comparison. “Doesn’t have Kotlin and Gradle all over the show” seems like a significant advantage in favour of TypeSpec.
That could be improved without fixing the whole JVM data ecosystem, but that's mostly up to JVM developers. It's unfortunate if the Spark developers using Arrow aren't contributing in this area (especially since many of them are being paid), but it's all open source and undoubtedly pull requests are welcome.
Congratulations on the 1.0 release, it's only going to keep getting better! Really exciting to be able to share data in-memory across languages.
Sure - but the comment you're replying to made no mention of NoSQL. It just said Clickhouse lacks OLTP by design, that doesn't mean it won't be widely used, just that it will perhaps be limited to analytics workloads.
If you need deletes and transactions, look elsewhere, but Clickhouse seems to be great for what it's been designed for.
BigQuery uses a lot of tricks to get efficiency, but this post emphasizes Apache Arrow and open data formats like it as the way forward (in particular the last point, "Be open, or else…") which are not currently supported by BigQuery.
If Apache Arrow takes off I hope BigQuery will support it as a data interchange format in the future. Zero-copy is pretty awesome, as are open standards in general. This feature does not exist in BigQuery today (as far as I know - definitely not as discussed in the source).
One thing people commonly miss about this is this is all meaningless if you don’t have the corresponding runtime integration, and these techniques very much imply co-design, and therefore tight coupling, between the format and the runtime. To give a concrete example, to make any of this efficient and fast you must have predicate pushdown directly into decoder such that filters could skip the data they don’t need to decode. Some aggregations could be handled the same way.
So it’s a little incorrect to think of this as a “file format” in the first place. If you end up designing it like that, you’d not be able to have a lot of the gains that the Abadi paper (and others like it) alludes to. My suggestion would be to go whole hog and push down as much filtering and aggregation in there as is feasible, exposing a higher level interface with _at least_ filtering predicate support, and do it in C++.
And the biggest problem for startup founders remains: you're taxed, on leaving the country, on unrealized gains. Being taxed on 5 millions of profit sounds fair, being taxed on 5 millions (or 30 millions) of valuation used for raising capital, in a startup that then fails and is worth nothing after a few years, maybe not so much. Neighboring countries do not have this kind of taxation.