Maybe I'm spoiled, which I'm willing to consider being true. However, one could assume that projects at this stage would use versioning, pinning, and documenting the changes to the api, which obviate the need for these types of disclaimers. All caps disclaimers like this could discourage those who are otherwise capable from giving it a shot.
Im not saying this is deno's fault, maybe it is and maybe it isn't, I'm only saying I'm noticing that rather than documenting through breaking changes people would prefer to make prominent disclaimers that are essentially buyer beware
I'm currently developing an "experimental" piece of software, i.e. I am not even sure some features I want to add are possible, meaning I had to rewrite it a couple of times (and won't be the last). Having strict versioning, pinning, and documenting everything before it reaches a semi-stable state would discourage me from developing it altogether.
I agree with the approach they are taking, keep the disclaimer, put it out there, get some visibility to find early adopters and contributors and stabilize it. A year from now people will have forgotten about this thread and will see it a new and stable framework.
I think if you look at Angular as an example, the Aleph team is doing it right. Angular didn't just make breaking changes when they went 2.0, they basically abandoned everything about 1.x and released something completely new. There were definitely people who had just learned Angular 1 that found out their time was poorly spent.
Deno 1.0 is roughly two years old. It's also apples to oranges. Deno is a JS runtime plus a std library. Aleph is still an experimental web framework. If you want to make a more apt comparison look at the web framework/library stuff in Rust that has frontend affordances/capabilities, which has a similarly immature v0.X feel to it.
How many years before a language is mature enough that it's not to be expected? I'm thinking 5 years is starting to push it, but others may have other opinions.
on edit: when saying push it I mean sort of still reasonable, but maybe a bit troubling? 7 years would definitely feel like too much to me. I wonder if there are any studies.
Ok, but obviously when I say 5 years I mean from the start of development of the language not from when it is given 1.0 status. Is it your contention that the count to 5 years should start from when language creators say it is at 1.0 - if so I think 5 years is way over the line for when people should be saying they are rewriting projects written in it from the bottom up periodically.
Start of development could be a "hello world" commit, so I would say any critical judgements should always be from the 1.0 release. Far too much churn before then anyways. Rust changed a truckload.
OLAP vs OLTP will depend on your ML use case. Online predictions will likely be better served by an OLTP vs offline batch predictions being better served by OLAP.
OLAP use cases often involve a lot of extra complexity out of the gate, and something we're targeting is to help startups maintain the simplest possible tech stack early on while they are still growing and exploring PMF. At a high enough level, it should just work with any database that supports Postgres extensions, since it's all just tables going into algos, but the devil in big data is always in evaluating the performance tradeoffs for the different workloads. Maybe we'll eventually need an "enterprise" edition.
How about the difference between this and the Madlib project? Better ergonomics?
I've used Madlib in the past and although it was 'successful', the constraint was unfamiliarity with the library from our data scientists, who preferred the classic Python libraries.
The timing feel similar to rust to me. It needed almost a decade to have real production ready project. Mozilla was an exception as they built it.