Any competing product has to absolutely nail tab autocomplete like Cursor has. It's super fast, very smart (even guessing across modules) and very often correct.
I think what you want here is a radar chart, not a 2-2 matrix. I suspect most people embody these different types to varying degrees over time, topics and circumstances.
If I could trouble you for the common discourse here, would you mind summarizing why one may prefer to use Guix in the place of Nix? They seem to be based on the very same ideas and Guix even admits to being inspired by Nix.
There is a different side to the cost benchmark that's not captured by the description here. If your use case needs a lot of stored data but not necessarily a matching degree of
peak CPU (even if your query load is otherwise pretty consistent), Redshift will become really expensive really fast and it will feel like a waste. BigQuery will meanwhile keep costs linear (almost) in your actual query usage with very low storage costs.
For example, you may need to provision a 20-node cluster only because you need the 10+ terabytes in storage across several datasets you need to keep "hot" for sporadic use throughout the day/week, but don't nearly need all that computational capacity around the clock. Unlike BigQuery, Redshift doesn't separate storage from querying. Redshift also doesn't offer a practically acceptable way to scale up/down; resizes at that scale take up to a day, deleting/restoring datasets would cause lots of administrative overhead and even capacity tuning between multiple users is a frequent concern.
Making matters worse, it is common for a small number of tables to be the large "source of truth" tables that you need to keep around to re-populate various intermediate tables even if they themselves don't get queries that often. In Redshift, you will provision a large cluster just to be able to keep them around even though 99% of your queries will hit one of the smaller tables.
That said, I haven't tried the relatively new "query data on S3" Redshift functionality. It doesn't seem quite the equivalent of what BigQuery does, but may perhaps alleviate this issue.
Sidenote: I have been a huge Redshift fan pretty much since its release under AWS. I do however think that it is starting to lose its edge and show its age among the recent advances in the space; I have been increasingly impressed with the ease of use (including intra team and even inter-team collaboration) in the BigQuery camp.
No idea why people reacting here so far got fixated on the "cheating" versions - it's clear to me they were included mainly to set a maximal speed baseline/benchmark and are not the main point of the article.
And data management / preparation is where major mistakes are made - get a join wrong and you may easily be missing data or double counting something just obscure enough to go unnoticed like "ancillary sales".
There is something potentially harmful, or perhaps that needs addressing, about end-user tools growing in expressive power. A good friend who does statistical genetics work once told me "but I don't want every user running their own regressions and drawing nonsensical conclusions from badly prepared data!"
Well, it's really tempting and financially desirable to try and get on Amazon anyway. There are lots of consumers on Amazon with both an appetite for that kind of an artisan item and the purchasing power to go for it despite the higher lead time. So the demand side is usually a given.
Don't forget that, from the manufacturer's perspective, Amazon is not only the logistical facilitator, but also a sales channel where huge numbers of potential customers are introduced to companies they wouldn't naturally be exposed to.
I don't want to have to pin every single tab I want unthrottled - that's a mixing/piggybacking of otherwise orthogonal concerns. Just make it a separate option I can set per tab.
In addition to automatically inferred signals, it would be great to give the user optional complete control over throttling as well at a per-tab level. I.e. a switch somewhere that user can freely enable/disable for a given tab to mark it throttled vs. unthrottled, whatever the right terminology would be.
Any great chess player (let's define that as near-IM fide ratings and up) will tell you that it's a highly iterative process between practice, analysis and reading that is very much anchored around practice.
They play thousands and thousands of hours and, yes, also spend quite a bit of time reading, thinking, analyzing (both their own and others') games and learning from mentors/teachers. However, practice is king and all the reading/analysis would be worthless in its absence. They would have no anchors to grab onto in your brain - no way to really become operational.
A chess "player" that mostly reads, studies and analyzes with a little bit of practice sprinkled in between would indeed be hilariously weak.
Soostone | NYC or Remote Possible | Functional Programmer (Haskell) | Backend, Frontend, DevOps, UI/UX Engineering
Soostone is a technology provider in the enterprise analytics space with a focus on performance improvement for e-commerce clients. We are the developers of a highly scalable platform that revolves around data, modeling, machine learning, real-time decision-making and sustained optimization. We routinely build features or capabilities that make use of in-process and multi-node concurrency, parallelism, stream processing, domain-specific languages (DSLs/EDSLs), Functional Reactive Programming (FRP) on GHCJS, MapReduce on Hadoop (via Haskell) and many other methodologies common in the functional programming world.
We also care a great deal about contributing back to the community by open sourcing useful components wherever possible. Our team members help organize a number of community events in eastern United States including the monthly NY Haskell Users Group, Hac NYC and the Compose conference.
Please note that this is pretty much how you model Haskell programs as well: Keep as much of your logic as possible in pure code and interface/drive that with imperatively written stateful code. Purely functional languages (e.g. Haskell) do not remove your ability to code imperatively, they rather augment it so that you can better reason with it while doing it. Things like first class IO actions (that you can pass around) and explicitly marked state (i.e it's clear what you have in context and what you don't) make for some pretty satisfying solutions you wow yourself with.
It is common to hear in the Haskell community remarks like "Haskell is the best imperative language I've used."
Huh. This new form of "because" in an actual, intended-to-be-grammatically-correct sentence sounds weird to me and I don't think I personally use it at all. Isn't it just "because of" without the "of" when people are in a rush, typing on a tiny keyboard or just plain lazy? Or when the intent is to construct a witty, purposefully broken sentence?
Application design for me almost always begins with data and data structures. Whether my database has an explicit schema or not, I always have one in mind, documented or otherwise reified in the table-data structures I have in my code. I just don't get why people would want a schema-free database that is in almost every way inferior to the rock-solid power beast that is Postgres. Just use a library with proper migration support so you can propagate changes to your schema rapidly during development. You'll thank us later when you learn a little bit of SQL and start analyzing your data, running circles around the no-sql guys.
Cassandra et. al. are completely different, in that you don't use them because they are more fun to use. You use them despite their awkward, low-level interfaces because you're going to dump billions of data cells into your database from day one with no end in sight and want all the easy scaling/availability features provided.
So much effort was poured into just redesigning, repackaging basic apps on the surface. I think some of them look and exhibit functional behavior straightforwardly worse than before:
- Smaller fonts and less obvious icons on the weather app
- Less info on the world clock without the digital time text, which helps grasp the time at a glance especially when you're looking at several zones.
- Smaller direction character font on the compass (why would anyone do that? It's like 40% of what it used to be and is only a single char!)
- Less contrast across the entire interface with all white text; harder to discern differences.
... and at best a neutral change across the others. I haven't yet installed it myself, but the screenshots look disappointing. I am not dismissing the idea of removing skeumorphisms, but this particular implementation/execution seems like a step in the direction of less refined for Apple.
I have seen very few screenshots so far that made me say "oh that's so much better, wow". Several did make me say "Gosh, why would you reduce the font size there?!?! Why would you make the icon much less obvious?"
Just to note that I am not trying to be negative - I am certain with this much solid engineering talent, there will be features we'll love.
I hope I'm proven wrong once the OS is officially out and we're hooked in the following few weeks.
Sorry, I really don't know much about Rust other than the occasional article I run into here on HN. Maybe someone else can point you towards a document. For Haskell, here are a few resources:
A sidenote: Your blog's code formatting is awful. I would recommend that you embed one of the common solutions for code snippet syntax highlighting into your blog. I needed special motivation to continue reading your post past the first code sample.
Edit: And then of course actually use the prominent guidelines for good-looking code in each language!