Ah, there is nothing like perjorative acronyms ... they seem to be designed to shut down thinking rather than invite more of it.
Let's not forget that:
1. new programming languages bring excitement, creative destruction, and yes, lots of hobby projects that don't turn into battle-tested products. I'm ok with that.
2. rewriting is not the same as re-envisioning. See the comment above. SQLite was a starting point for inspiration, not the destination.
Also, we should not conflate an underlying technology with the hype around that technology:
a. Just because there is a lot of hype around Rust does not mean the advantages of Rust should be overlooked
b. Some highly-praised technologies deserve the praise. Yes, sometimes even the cynics are wrong.
> Nobody forces beginners to write macros. Beginners are only macros _users_. With time and experience, the need for macros emerges by itself, then learning them is a natural part of the process. But even then, nobody is forced to write any.
I think one of the problems with this mindset is, you are only assuming the case with you have full control on the code-base e.g. writing thing from scratch so that you can only use those features in rust that you feel comfortable with, in other cases, you have little control on what others use.
This is something we've not tried yet, so I don't know. I would be surprised if it worked right now. But in general, it's something we would definitely be interested in exploring.
The containers created by Sysbox act like virtual-hosts, so it makes sense to have the ability to expose GPUs / hw-accelerators within them. But container nesting, which comes naturally with Sysbox, would introduce another challenge since the GPUs would not just need to be passed to the outer system container, but also to the inner application containers.
first of all, I don't think "most inappropriate languages for frontend development" is a thing, it is just a new way to do web dev that is different to what you used to be doing with. If you don't think it is an approach that you prefer/can accept, you can just move on continue with whatever you like. You should learn from the people who built Brython, they don't like the way how the current web is being built - hence they continue doing what they believe its right, BUT wihtout putting shit on other's people's work.
There are people who think images and JS are far too much for the Web (you can often read comments like that on HN) and want pure text only Web. Should we learn from them too?
I don't mean to put shit on any body's work. I am just noting several obvious flaws to the idea. Now it might sound like putting shit, I don't know, but I am not native speaker so sometimes I guess I am using the wrong tone/working.
The real question for me is why it's such a big deal? In the end its simply an opinion.
Stavros thanks for the explanation, how does TileDB avoid downloading the entire matrix and do the slicing (locally)? Are we achieving this by breaking down a big matrix to a set of smaller ones? so that you only down the subset of that the current query need? If this is the case, what is the current measure we have to avoid mismatch on metadata (e.g. some error while uploading them to S3) that links them together? thanks
Efficient slicing happens because of "tiling", hence the name TileDB. A tile is similar to an HDF5 or Zarr "chunk", or more loosely to a Parquet page. Although totally configurable, tiling is handled solely by TileDB, the user doesn't need to know about it. A tile is the atomic unit of IO and compression. TileDB maintains all the necessary metadata and indexing built into its format and, given a query, it knows how to fetch only the tiles that might include results. The tiles are decompressed in your memory and filtered further for the actual results. The dense array case is rather straightforward. The sparse case is a big differentiator in TileDB and it is quite challenging, especially in the presence of updates. TileDB handles the sparse case via bulk-loaded R-trees for multi-dimensional indexing, and via an LSM-tree-like approach with immutable objects that allows time traveling.
Concerning your point on potential errors occurring on S3, this is addressed by TileDB's immutable object approach. If an error occurs upon some write, there will be no array corruption. Happy to discuss about this topic on a separate thread.
