ozataman

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.

Very happy to hear that and thank you for pointing out the dead link! It's been fixed.

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.

If interested, please submit applications to jobs@soostone.com

Website: http://www.soostone.com

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.

That's exactly how I feel; good description sir!

Well, that's very good to hear. Looking forward to the official release.

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:

- https://github.com/tibbe/haskell-style-guide/blob/master/has...

- http://stackoverflow.com/questions/6398996/good-haskell-sour...

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!

For example: I personally prefer the standard form here, as (to me) it reads a bit more like English:

over (location.x) (+ 10) $ player1

"over location's x, add 10"

Care to point at some resources?

In further support of these points... Thinking outside the box, breaking the rules as a last resort to do the right thing and other similar actions can indeed produce the extraordinary results, in certain situations, the organization is hoping for after all. Yet this strategy will work only for the very top performers: Those who can sense and actually produce the truly largest "contribution" to their company (as opposed to what seems right, interesting or cool to them), even when it more or less eludes their higher ups; those who can do this while also being politically savvy enough to contain the consequences and sell their actions as actually in line with everyone's goals; those who are almost magical in being able to produce the kind of results others are very unlikely to do etc. It can work, I've seen it work, but I think it is important to realize that not everyone can or should do it. When it works, it is certainly a great boon to the career of the said top performer.

Know that by doing this, you may be counterproductive both to your organization and your career. If you take it to the extreme, you may become a friction rather than a "problem solver".

The most common pitfall I've seen is a highly technical person considering things like "refactoring", "getting it right" more important than getting to the finish line fast. Remember that you may be missing what's really the most important thing for your company at the time.

I've also seen commonplace "complaining" about inconveniences that are actually quite legitimate. It's just that you don't know all the facts or haven't been put in a position to produce the bottom-line results. Things look different when you're the one navigating the ship.

OTOH, I've seen this strategy work best when the very formal scope/objectives/deliverables of an effort are clearly wrong and would indeed lead to a subpar outcome for all involved. Implemented successfully, this strategy could produce outstanding results by forcefully course-correcting and then actually delivering great results. Remember though that you'll be blamed for everything if your course-correction isn't great, even if the original direction would also have been equally bad.

That's great - I love worthy and proper competition combatting nonchalant/tyrant attitude of incumbent giants. It is so annoying to deal with customer service reps that act like they are your boss and you're inconveniencing them through your questions. The stronger the company, the more of those reps you'll get.

Thanks for posting this!

Don't make assumptions on what's business critical and what's not. Not every business has the same level of free capital, circumstances or domain knowledge to handle everything theoretically correctly. There is implicit trust in working with companies like Google; you expect everything to work properly. They don't have to, of course, but when they don't, articles like this chip away at the confidence we all have in Google.

Nice to see a non-negative analysis of iOS7. Not having tested it myself, I hadn't realized that iOS7 was actually pushing the boundaries of what's possible with modern hardware. My previous impression was that, if anything, it was a simplification of sorts and that seemed a dubious direction. Thanks for pointing this out!

Seems to me like a somewhat empty bag of words. My general interpretation is "walk before you run"; I don't see the need for working hard to find a rule that applies everywhere. The obvious point is that you probably need to have something substantial (market wants your product, fans clamoring on HN, you have a few initial clients, you make some money.. something) before thinking bigger.

If we have to impose a timeline, though, I would say that all 3 elements (market fit, strategy, biz model) have to be considered together, all the time in the leaders' heads (and officially recognized once in a while). Please remember that there is only a single digit (or so) number of Twitter-like stories in the world. Just think of the numerous times that kind of linear thinking (forget about biz. model - let's just pour money into this thing for a long time, or, let's build this cool product without a strategy although I don't even know what cool means without a strategy) approach has failed. In those rare cases, you probably still think about the biz model, as in "it doesn't yet exist but will exist likely in one of X forms once we reach status Y".

I might have a different definition of strategy, but you need some kind of strategy, which at a high level might even just mean "approach", to be able to do anything, including validating an initial market fit. Even starting small, testing/iterating and seeking market fit and later switching gears itself is a form of high level strategy. A ship without a direction gets nowhere, even if you're a small ship in a really-well charted sea.

Unless, of course, he means by product-market fit "an idea for a product/service that the market wants", which would be just about the first thing to do in any business, as championed by the likes of the book "Four Steps to the Epiphany". I suspect those bootstrapping (to at least some degree) would likely know this from deeper in their hearts than others who've had an easier time with plenty of funding upfront. Everything else by definition has the workings of a strategy, whether you admit it or not. If you're not explicit about it though, you're just letting the waves take you places you hope will be good.

Edit: The issue I take is that the article puts strategy into a step in the timeline or process, whereas I believe it needs to be everywhere, all the time. You can't have product-market fit without strategy AND/ORD you can't build a solid, sustainable business without thinking about strategy/market-needs/biz model and probably more at the same time, holistically throughout your existence. It's not just that "don't forget about strategy before biz model!!". Jumping to biz model without having a strategy is impossible - it just means your strategy implicitly is to "grab the money in the best way you see possible right now", without charting a longer term objective.

Agreed. I would argue the SSL tax on servers is fairly negligible in this day and age.

As for other reasons:

1. It leaves a bad taste in your customers' mouth. Security should be an option.

2. Imagine the disaster if someone makes front-page on HN complaining how their PW got snooped and their top-secret project plan is now public.

Pay-for-SSL was a bad idea back in 2005 - now it's a non-starter in my opinion.

Yeah, it should be the absolute requirement for this kind of app on all tiers - free or otherwise.

Haven't thought of that tbh. I only have a single reservation that I mentioned in my above post. Not to put any words in his mouth, but I'm not sure there can be a solution to it given his current architecture of the system. It is inherently a multi-tenant SaaS backup service...