Comparing k-NN in Rust - <AUTHOR> http://huonw.github.io/2014/06/10/knn-rust.html <comment><USER3> From the perspective of a compiler writer, the most interesting thing about this code is that it contains no bounds checks while still being safe. Using the high-level iteration APIs like map/filter/etc. is not only good for readability, it's good for performance as well. C-style for loops require bounds checks to maintain safety, but there's no need for them with a properly designed iterator API.

<comment><USER4> What about all those calls to unwrap? Don't those sweep some of the bounds checking under the rug? It's okay in a proof of concept like this, but I wouldn't be comfortable running that code "for real".

Edit: to be more clear, I wouldn't expect it to have an impact on performance, but I'm not convinced this is a good example of expressiveness and safety in the same package.

<comment><USER5> .unwrap() is checked, if it goes wrong, it will safely cause task failure and stack unwinding. There won't be any memory unsafety.

<comment><USER4> You can't get corruption, but I don't consider a program that violently terminates on unexpected input to be "safe". Just semantics, I guess.

<comment><AUTHOR> Yeah, saying 'safe' around Rust is generally interpreted as meaning memory safety.

</comment></comment></comment></comment></comment><comment><USER6> For reference, a straightforward translation of the Rust code to C++, compiled using clang, halves the running time. There are two reasons for this:

\- `int` is the fastest available integer type in C(++), whereas in Rust it is defined to be pointer-sized. This allows the C++ version to vectorize better than Rust by using 32-bit integers (also there aren't native SIMD 64-bit multiplications in current x86).

\- Even when changing the native type from `int` to `i32`, to match the C++ code, rustc does not vectorize the distance function. I do not know the exact reason for this, but I would guess the iterator code is unable to elide null pointer checks. It's unclear to me whether this is a language limitation or simply a current compiler limitation.

<comment><USER3> Rust doesn't have null pointers, so I see no language-level reason why that wouldn't vectorize. LLVM's vectorizer tends to be pretty brittle, so probably tweaking the generated IR a bit would cause us to vectorize. Feel free to file an issue if you have time :)

<comment><USER6> Well Rust _is_ checking for null pointers at the assembly level: [http://goo.gl/eh2aqc](http://goo.gl/eh2aqc) (lines 22--27).

<comment><USER3> Blech. I'm pretty sure LLVM, not the frontend, is inserting those null checks for some reason.

<comment><USER7> The slice iterator yields `Option<&T>`, the None variant is represented by a null pointer. That's probably the null check.

</comment></comment></comment></comment></comment><comment><USER8> Rust's iterators are really nice. As far as I can tell, the idea is to do only one check on each iteration, which doubles as an array bounds check (for memory safety) and a loop condition check (for loop termination). That's much better than the usual "for" loop with an index into a checked array, which uses one check for loop termination, and two more checks upon array indexing. Why don't more languages do that? It seems like a simple enough idea, I blogged about it sometime ago.

<comment><USER3> In the case of Java, I believe it's because the underlying JVM only supports bounds-checked array indexing. So even though the iterator APIs in Java could in theory eliminate the bounds checks, the high-level information is compiled away and the JVM has to prove on its own that the bounds check is not necessary.

<comment><USER8> I wonder if the language can support similarly fast access to user-defined data structures. Though maybe it's not a very interesting question, if arrays are built in. Most user-defined data structures are already their own iterators in some sense. For example, iterating over an ML-style linked list obviously requires only one check per iteration.

</comment></comment></comment><comment><USER9> A Factor version compares favorably at 13 lines of code, and as fast as the parallel OCaml version.

[http://re-factor.blogspot.com/2014/06/comparing-k-nn-in-fact...](http://re- factor.blogspot.com/2014/06/comparing-k-nn-in-factor.html)

</comment><comment><USER10> Very cool! The code is quite clean and readable. I'm quite impressed by the D sample linked as well. I had a brief foray with D a year or so ago and liked it a lot. I'd like to see a speed comparison. I'm not surprised the author had trouble getting it to compile though; D seems to be similar to Rust in that it is still actively evolving as a language (I recall several times where I couldn't get the code in Alexandrescu's book to compile).

<comment><AUTHOR> The author of the D post and I are having/had a discussion on reddit about the problems I had: [http://www.reddit.com/r/programming/comments/27s7g6/comparin...](http://www.reddit.com/r/programming/comments/27s7g6/comparing_knn_in_rust/ci3v7y9)

</comment></comment><comment><USER11> In summary, the Rust code in the direct source translation is about 3.5–4× faster than the OCaml. The parallel version is even faster. This is in safe code with bounds checks.

<comment><USER12> In addition, "I made no effort to remove/reduce/streamline allocations", which is a bit of a cruel tease. I want to know how much faster it could still be! :)

<comment><AUTHOR> I just ran perf on it: the slowest allocation function takes 0.04% CPU time in total, meaning there's not much time to gain from just removing the allocations directly. There may still be a benefit from better data locality from fewer allocations.

<comment><USER12> In the future I'd recommend perf for benchmarking as well. `perf stat -r 3 ./foo` will do the repeated runs for you, and give you output like "1.002251432 seconds time elapsed ( +- 0.025% )", where that latter number appears to be the coefficient of variation.

<comment><AUTHOR> Oh that's nice, thanks.

</comment></comment></comment></comment></comment><comment><USER10> For any interested, I wrote up a Haskell version[1]. Initially, it was immensely slow (~ 2 minutes); however, switching over to unboxed vectors brought it to be on par with OCaml. There are still opportunities for improvement.

[1] [http://lpaste.net/105413](http://lpaste.net/105413)

<comment><USER10> And here's one that runs in half that time (or possibly less if you have a lot of cores)[1]. Speedups due to suggestions in this thread[2].

EDIT: now runs in parallel and is faster than the Rust single-threaded version, and on par with the parallel Rust version, but only ~35 lines.

[1] [http://lpaste.net/105456](http://lpaste.net/105456)

[2] [http://www.reddit.com/r/haskell/comments/27tcvz/knearest_nei...](http://www.reddit.com/r/haskell/comments/27tcvz/knearest_neighbors_in_haskell_is_elegant_but_slow/)

</comment></comment><comment><USER13> Related: Has there been any ETA announced on when Rust will stabilize? I'm very interested in learning more about it, but not until I don't have to read changelogs regularly.

<comment><AUTHOR> A 1.0 release is wanted at the end of the year. Note: it will really only be stabilising the core language and an unspecified set of core libraries; it will likely take a while after that until there are stable libraries on a scale rivaling Python or Go.

<comment><USER13> I'm just hoping to avoid the level of instability that I've experienced in my Ruby projects over the years. It makes it nigh impossible to keep a project maintained sanely long-term as its dependencies evolve and even the language or stdlib change in backwards-incompatible ways every couple of years.

<comment><USER14> Not to dismiss the importance of language stability, but forward porting in Rust _should_ be significantly easier than Ruby for a few reasons:

* Rust's strong type system means the pieces fit together only in specific ways - roughly, if you can get it to compile again it will work; in more dynamic languages you have little confidence that the code works until runtime.

* Co-evolving the language with the downstream community is such a critical issue that Rust is developing several tools and processes to help, and this should set it apart from other open source languages that have gone down this path:

The Rust process already attempts to tag all breaking changes in the commit log with `[breaking-change]` and we've heard anecdotally that this has made forward-porting Servo much easier. This log isn't published anywhere besides the commit log yet, but it will be.

Secondly, Rust has a [stability]([http://doc.rust- lang.org/rust.html#stability](http://doc.rust-lang.org/rust.html#stability)) system that tracks API stability at a fine level. This is influenced by node.js, but in Rust stability is detected and use of unstable API's can be enforced by the tooling. This is still in development but you can see it in the [docs]([http://doc.rust-lang.org/std/intrinsics/](http://doc.rust- lang.org/std/intrinsics/)).

</comment></comment></comment></comment><comment><USER15> I've been watching rust from the sidelines for a few months now, cheering it on. I'm really excited for the language to stabilize a bit.

Has anyone here who uses it run into any downsides in comparison to other languages (aside from it being new and changing)?

<comment><USER16> I love rust, but the entire system of tracking lifetimes is both a major upside and a downside. When it "just works", it's like a dream where you can make a mess and have it cleaned up automatically, cheaply, and at exactly the right time. When you start getting errors or want to refactor across function call boundaries, it can be frustrating and/or require a quite deep understanding of the workings of the system to figure out how to fix it.

tl;dr: If you consider "has a fairly complex concept that is unfamiliar and necessary to learn with a fair degree of depth" a downside, then I think it has one.

<comment><USER17> I somewhat agree with your characterization. Lifetimes definitely adds a bit of complexity to the language. And you're right about the benefit; lifetimes are frankly awesome. It's really _really_ cool to write memory safe code without using a GC.

When I first started with Rust (was also my first foray with lifetimes), the compiler completely kicked my ass for at least a few days. I struggled a lot with writing anything beyond a few functions, and especially when those functions were returning borrowed pointers. I think the code I wrote at the point could be fairly characterized as, "the bare minimum that I could convince the compiler to accept."

But as I wrote more code, I got better at it pretty quickly. At this point, I can look at most Rust code and feel pretty good about spotting lifetime errors before consulting the compiler. I'd say it only took me a couple thousand lines of code to get there, which isn't a huge price to pay.

Anyway, this is obviously a personal anecdote. But it's coming from someone who thought Rust was crazy complex only a few months ago. FWIW, it took me about 48 days from knowing absolutely zero Rust (other than random Internet buzz) to writing and getting libregex merged upstream.

<comment><USER16> We're in violent agreement. (Though you've gone much further with rust more quickly than I - libregex is beautiful.) A couple thousand lines to feel pretty solid with lifetimes sounds about right - I'm getting close to that range and the issues I'm hitting are increasingly of the obscure kind rather than the initial "nothing works, I guess I'll put it all on the heap!" kind.

This is basically why I said _if_ you consider this a downside. I think it's only a "downside" in the same way that purity is a "downside" in Haskell - <USER2> isn't _accidental_ complexity, and wrapping your head around it is just a part of really learning the language.

</comment></comment></comment></comment><comment><USER18> By replacing the distance function with:

        let distance (a1 : int array) (a2 : int array) =
          let open Array in
          let len = length a1 in
          let acc = ref 0 in
          for i = 0 to len - 1 do
            let v1 = unsafe_get a1 i in
            let v2 = unsafe_get a2 i in
            let d = v1 - v2 in
            acc := !acc + d * d
          done;
          !acc

the OCaml goes 3 times faster. This is what would be produced if OCaml's inliner had triggered on the original definition of `distance`, so that is probably the main difference in the two language's performance. If you inline some of the other functions by hand (and tidy up some of the sillier parts of the OCaml code) it easily runs 4 times faster than the original.

<comment><USER18> Indeed using the improved OCaml inliner ([http://www.ocamlpro.com/blog/2013/07/11/inlining-progress- re...](http://www.ocamlpro.com/blog/2013/07/11/inlining-progress-report.html)) on the original OCaml gives a speedup of 2.75.

</comment></comment><comment><USER7> How much work would it be to rewrite `slurp_file` to return an `Option<..>` result, that is replace all of the .unwrap calls into some kind of short- circuit return?

<comment><AUTHOR> I wrote it up; [http://huonw.github.io/2014/06/11/error-handling-in-rust- knn...](http://huonw.github.io/2014/06/11/error-handling-in-rust-knn-case- study.html)

<comment><USER7> Ok that's the amazingest answer you could give to my question! Very cool, it doesn't look so bad.

In my mind this style should be the default for error handling when coding (i.e. I'd prefer to push the choice of using .unwrap or not to the caller)

</comment></comment></comment><comment><USER19> you could use move_iter() instead of iter(), its more idiomatic.

<comment><USER17> Huh? They serve two different purposes. `move_iter` returns an iterator that consumes values (i.e., ownership transfers) while `iter` consumes borrowed references to values (i.e., no ownership transfer).

The only place in the code, that I can spot, where `move_iter` is even available is on line 46. But I don't see any compelling reason to use move_iter there (plus, `validation_sample.len()` in the final println would have to be moved up and let bound before the call to move_iter).

<comment><USER20> I think they were trying to say that borrowing is preferred over ownership transfer.</comment></comment></comment>


External implementation of tags on HN - <AUTHOR> http://hntags.com

<comment><AUTHOR> I know this is a duplicate, I feel that in this case the situation merits it. The discussion over here : <http://news.ycombinator.com/item?id=1069377> : is concentrating on the idea of discovering (an approximation to) your internal HN id.

Much, _much_ more interesting is the potential for tagging items. If just 1% of people took the time to tag things then it could become a really useful resource. It might even become my first portal to HN.

Two suggestions: Please can we have somewhere a list of used tags, and please can it not show dead items?

</comment><comment><AUTHOR> I have found what appears to be a bug. Putting "algorithm" as a tag to search for it returns:

        1 Computer algorithm to decipher ancient texts (reuters.com)
          (1 point) (discuss)(tag)tags: hacking algorithm

        2 Computer algorithm to decipher ancient texts (reuters.com)
          (2 points) (discuss)(tag)tags: hacking algorithm

The discuss links, however, go somewhere weird and apparently unrelated.</comment>


A Great Alternative to an NDA? - <AUTHOR> http://geniusarmour.com <comment><AUTHOR> Preparing for a formal launch here soon, but wanted to get some feedback on this from you guys. Any and all thoughts ( even if they hurt my feelings ) are "appreciated". If you want to sign up and give it a go, I trust you're smart enough to figure out how ;)

<comment><USER2> I am just thinking that if I wanted lots of people's secret plans or ideas, I would totally set up a cloud service such as this, because then people who bought my marketing page would totally just... upload their secrets, right to my server.

Or, in friendlier terms: You probably should have more on your front page that indicates why you should be trusted with this information. What kind of liability do you have?

Speaking of trust, I find this horrifically questionable: "Finally an NDA without the hassle. I wish I had this years ago!" \- @thegrossprofit

Are you providing a testimonial of your own product?

Finally, a technical comment, on Microsoft Edge (1607 build), if you visit the signup page, it flashes the screen white a lot.</comment></comment>


Xorballs: A tile puzzle game with balls - <AUTHOR> http://xorballs.dskl.net/

<comment><AUTHOR> Some discussion and background can be found here:

[https://plus.google.com/communities/115544462558726220980](https://plus.google.com/communities/115544462558726220980)

Looks like it's Turing complete too...

[http://forum.dominionstrategy.com/index.php?topic=7739.new#n...](http://forum.dominionstrategy.com/index.php?topic=7739.new#new)</comment>


Amazon To Target $5.5 Billion Textbook Market With New Kindle? - <AUTHOR> http://www.techcrunch.com/2008/07/17/amazon-to-target-55-billion-textbook-market-with-new-kindle/ <comment><USER2> I don't own a kindle and haven't played with one, but in messing with the Sony one, it seemed like the pages turned verrrryyyy slowly.

When using a textbook, I find it helpful to be able to flip pages quickly. I wonder how this will affect folks.

<comment><USER3> When using a textbook it's also helpful to be able to search for a word or phrase. Besides, the Kindle right now isn't bad, and this is the FutureKindle that doesn't have any flaws yet.

I was going to say I was skeptical of textbook publishers liking this, but there are no used book sales on the Kindle!</comment></comment>


Ask HN: What do you think about C++ 20? - <AUTHOR> <comment><USER2> With the right tooling, I find it a lot more productive than the C++98 I learned in early university. A lot of memory management patterns are easier to write/maintain, and more fine-grained tuning for performance is still available to you if necessary.

Bjarne Stroustrup writes "Within C++, there is a much smaller and cleaner language struggling to get out." and I think I can see elements of that language in newer and newer editions. It's nice to have both the new and the old in the same toolset, although sometimes I look at Rust and I think "this might be better in a newer manual-memory language".

</comment><comment><USER3> Modules: hopeful

Concepts: finally

other language features: nice

library features: okay

what was left out: I have to wait ANOTHER three years for reflection?

ABI: just break it already, cowards.

overall: how long 'til I get it?</comment>


A New Tool from Google Alarms Sites - <AUTHOR> http://www.nytimes.com/2008/03/24/business/media/24ecom.html

<comment><USER2> What the author doesn't mention is that this "tool" has been around for a while and is available for every site in google's index.

<comment><USER3> You could always do site-specific search if you knew the syntax, sure. But I'd never seen the extra inline per-site search box before reading the article.

Is that second box what you're talking about, and how long do you think it's been displaying?</comment></comment>


Man Survives Steve Ballmer's Flying Chair To Build '21st Century Linux' - <AUTHOR> http://www.wired.com/wiredenterprise/2011/11/cloud-foundry/

<comment><USER2> For hackers, this is how PR is done. The hook is Steve Balmer's flying chair, but the aim of the stsory is to position Cloud Foundry as what Microsoft isn't. Very well done. If anything it might convince people to take a closer look at it.

I had downloaded cloud foundry when it was announced but did little with it. I might have a closer look again.

<comment><USER3> As I was reading that story I was imagining the pitch email that was sent by VMWare's PR team to this journalist.

Sometimes it is a little too artificial. You are right though, if you give most writers an interesting hook, they will use it and then recite the remainder of your pitch deck almost verbatim (as in this case)

<comment><USER4> Don't be so sure this started as a PR pitch...Cade has been covering Cloud Foundry and Appfog since they adopted Cloud Foundry, see all of his articles about it over at the Register, example: [http://www.theregister.co.uk/2011/09/13/appfog_adds_ruby_and...](http://www.theregister.co.uk/2011/09/13/appfog_adds_ruby_and_node_dot_js/)

</comment></comment></comment><comment><USER5> Mark, that is my direct superior, and Derek, are the two guys that made possible the whole Redis development funded by VMware story (together with a CEO saying yes of course).

Also if Redis was left as a completely open source affair is thanks to both.

</comment><comment><USER6> I used to work at Google near the Ajax APIs team and used to see Mark, Derek, and Vadim hacking away. They are a talented bunch; when I heard they went to VMware I was sure they would come out with something awesome, so its great to see details on Cloud Foundry come out. Congrats!

</comment><comment><USER7> Kudos to VMWare for open-sourcing this, it'll be interesting to see how they leverage this product. Google open-sourced Android because they wanted to have people to search using Google on their mobile phone.

I am also quite amazed that a team of 6 was able to build this seemingly complex product.

<comment><USER8> That wasn't the entire team. The original team was only 3! It grew to larger than 6 before Cloud Foundry launched in April (I'm talking specifically about Engineers). If you add other people the team is far, far larger.

</comment></comment><comment><USER9> Sometimes I feel we went about embracing virtualization the wrong way. We added instructions and changed silicon to efficiently run multiple, isolated OSes on a single computer.

The bigger problem that needed fixing was how to make the hardware scale transparently. I don't have any solutions to this of course. But I do imagine that someday, a good team might build transparent virtualization that scales over a network of connected nodes without having to code this explicitly.

<comment><USER10> In some senses we have this already: with some clouds you just have to boot a node from a tiny PXE image or a USB key, and it'll discover the cloud, join in, and VMs will migrate onto it.

Unfortunately physics simply won't permit _transparent_ scaling of workloads across nodes. For any application involving communication between parts (anything not "embarrassingly parallel") messaging between the parts gets slower and harder as the parts get further away and there are more of them communicating. 1000 nodes have a million possible connections between them, so you can't directly wire them. You need a switching fabric, so your messages have to deal with multiple hops and contention -- slower and harder.

</comment></comment><comment><USER11> HN doesn't go for snark, but it seems reasonable to observe that in the end we will all survive Steve Ballmer, and projects like Cloud Foundry will be the reason.

</comment><comment><USER12> I have tried it myself, with their beta hosted service - good stuff. I am very happy with Heroku but something similar, open source, and multiple vendors is also good.

<comment><USER13> so this is essentially an open source/VMware backed competitor to Heroku?

and Strobe for sproutcore is now facebooked i suppose

</comment></comment><comment><USER14> So what is their business model? I'm happy they open sourced the project, but they have to make money _somewhere_ to remain a viable business. The article was unsatisfactorily vague about how VMware is going to make money off the project.

<comment><USER15> The article wasn't vague. It explicitly pointed out that there's no business model at all yet:

 _Maritz says VMware doesn't have a concentrate plan for making money from Cloud Foundry. "A leap of faith," he calls it._

I imagine the obvious business model though is to position themselves as the world experts on this platform and provide hosting and support to enterprise customers that would rather pay a premium for peace of mind as opposed to startups that would shop around for the cheapest option.

<comment><USER16> For one, this puts VMWare in a very good light with engineers who might have to choose a VM platform, just as with Redis. I confess that I generally like Google because they gave away a lot to the community, this can work for VMWare too. Kudos to them :)

</comment></comment></comment><comment><USER17> Has anyone here built anything on top of Could Foundry yet?

<comment><USER18> We're dogfooding at AppFog. We self-host our web management console (see [http://blog.appfog.com/creating-your-first-app-in-appfog- in-...](http://blog.appfog.com/creating-your-first-app-in-appfog-in- under-5-minutes/)).

When we needed a staging environment, it was just an `af push` away.

<comment><USER19> what's the relationship between appfog and cloud foundry? is appfog source available? i just watched the video and it said "open source", but that seems to refer to cf, not af? what does "registering" for appfog mean? is that pre- registering? or does it exist? can i try it out? what do you pay for? please forgive the questions, but i'm looking at all this for the first time and a bit confused...

<comment><USER18> CloudFoundry manages the application lifecycle of AppFog apps (deployment, binding to services, etc.) What you see in the open source CloudFoundry project is what we run on our servers, with minor changes in our private repo that are specific to our product (e.g. billing).

We are now in our private beta program. Signing up at <http://appfog.com/> places your email in our beta list, which we create accounts for regularly and often.

We will announce paid subscription plans very soon, so stay tuned for the details.

</comment></comment></comment></comment><comment><USER18> We at AppFog are extremely proud to be a part of the CloudFoundry ecosystem!

If you want to get involved and try CloudFoundry for yourself, add your email to our list at <http://appfog.com/> and I will personally add you to our private beta!

<comment><USER20> added eric at ericschrijver.nl , curious!

</comment></comment><comment><USER21> I'm hesitant to build on these technology without information on the pricing.

<comment><USER22> Very wise. VMWare has established a precedent with ESXi V4 starting out free, then drastically changing terms, conditions, and pricing with V5. Their prerogative of course, but there is no way I would build a business around free beer software unless it was also free speech so I can fork it if I have to. They have open sourced this code, so you can take a chance on it, but you have to be certain there is enough of a critical mass of code commits from the outside that it could fly on its own were VMWare to close it back up.

</comment></comment><comment><USER23> What I can't understand is how the hell Ballmer, who comes off like a clueless psycho, managed to get and retain such high position at Microsoft?

<comment><USER24> He's a sales guy, and it's hard to overestimate just how much of Microsoft's revenue depends on sales relationships with big, big companies.

</comment></comment><comment><USER8> Great write up about Cloud Foundry, Mark Lucovsky and Derek Collison</comment>


Show HN: Listen to Curated Playlist - <AUTHOR> https://playlisten.xyz <comment><USER2> Pretty cool, but straight up turns your laptop into a radiator.

</comment><comment><USER3> The UI is minimal and good, but need to reload sometimes to play song.</comment>


Google's Wikipedia clone Knol launches. - <AUTHOR> http://googleblog.blogspot.com/2008/07/knol-is-open-to-everyone.html <comment><USER2> There are many things about this project that don't make any sense, as others have commented; it is not a wiki, does not compete with Wikipedia, seems to stand alone from other Google products in terms of design and yet they still haven't changed the name even after the owner of knol.com refused to sell.

One of the things that I like about Wikipedia is that I can just hand craft a /wiki/Title URL - Knol's URLs are obfuscated behind strange ID's and author's names. Do they not consider these things?

On a similar topic, I'll never understand why they decided to shelve Google Answers - there could have been a great synergy between that community and a wiki.

Knol will fail simply because it does not beat Wikipedia in any respect.

Was this born from a 20% side project by any chance? I can imagine some executive sitting behind his desk thinking "we need to buy wikipedia, but we can't.. so anyway, this knol thing looks close enough.. let's promote it to production".

<comment><USER3> They have a plan. :)

I posted this when they launched Lively:

> in this view it also makes sense for them to take over Wikipedia and Flickr

<http://news.ycombinator.com/item?id=244629>

Now they've got their own product that fills the Wikipedia gap and is also more suited to their purposes.

</comment></comment><comment><USER4> Looks like an About.com clone, to me. There's no "wiki" involved here...the point of a wiki is "anyone can edit it", not what data the wiki happens to contain. WikiPedia is first, and foremost, a wiki. (Secondly, it's a culture. The data it contains only comes in a distant third, I think.)

<comment><USER5> It looks like a Squidoo clone to me, more than an About.com or Wikipedia clone.

<comment><USER6> Agreed. Squidoo clone.

</comment></comment></comment><comment><USER7> Does anybody else think the design looks a bit two-faced?

Serious-looking, authoritative text - and a round, cartoony button asking you to help out.

EDIT: Also, the site can't seem to decide whether it wants to be single-spaced or double-spaced. And it's not certain of what fonts it wants to use, either.

<comment><USER8> Word. I'm getting sick of Google's lack of design sense. Either stick with the spartan, or hire some good designers. I'm sure that horrendous 'write something' button was the result of an A-B test, but the knol logo is an embarrassment.

<comment><USER7> Yeah. That's the problem I have with Google. They have functionality that's second-to-none, but they have no taste for visuals. I'm debating moving entirely over to MobileMe for email, for instance, forsaking lack of tabs for the sake of not hating my screen when Gmail's showing. (I also find it funny that Google-leaving founders have the same taste: FriendFeed's visual update is one of the few updates that was noticeably a step backwards.)

And for the love of God, you're right. That is embarrassing logo if I ever saw one. Writing the message out in plaintext, the logo itself, and the miniature scaling... I was hoping Knol could actually look BETTER than Wikipedia, and this is not looking good.

<comment><USER9> That begs an important question: What's good design?

Good design in a magazine print ad is different from good design on a fashion blog is different from good design in a web app or a mail client.

So good design should be judged in terms of what it's supposed to do. In that light it seems the best design for Gmail is that which _gets in the way least_ , because it's efficiency that counts when you're using it.

<comment><USER7> It's a matter of form follows function, always. But form includes the impression the end user gets. That's why big buttons don't always work.

For Knol, that feel ought to include a stately manner. Something large buttons don't convey well.

With Gmail, there's quite a lot of clutter. Google tends to have a lot of clutter. Curves where you don't need curves, visual tics that don't have to be there. the ribbon that highlights the Inbox. The bulkiness of the selector.

I noticed this on Windows, much more now that I'm on a Mac. Google wastes pixels not for functionality but for this idea of a design. They could smooth it out, add much more color contrast, make things more usable while still looking nice, without much of an effort. But they rarely do. Gmail and Google Reader are the two hugest offenders, I find; Maps and their actual Search are good comparisons, because very little space is wasted.

</comment></comment></comment></comment></comment><comment><USER10> Not really sure why people keep calling this a Wikipedia clone - seems much closer to Squidoo than to Wikipedia, to me. Granted, that's a debate that's already been had and done (back in December, if I recall correctly).

* disclaimer: I have worked with Squidoo in the past, and still have a couple of lenses there. I'm not taking a position on which is better - just pointing out a better comparison.

<comment><USER11> Don't know about Squidoo, but based on my brief look at Knol it seems very distinct from Wikipedia for a single reason: individual authors credited along with name, photo and profile link.

I think this flies in the face of many things that made Wikipedia a success.

Not to mention my first instinct was to visit knol.com, the website of a Dutch company who manufactures something resembling a crippled R2D2 using a walker.

I vote against this project as a serious rival for Wikipedia but only time will tell.

<comment><USER7> Squidoo and Knol seems to have the same idea behind it. Knol has the advantage of looking very nice in the process, and - of course - being sponsored by Google. Seth Godin is bright, but Squidoo is not fun to use and not fun to look at. Knol has an edge there.

The fact that Google didn't buy Knol.com is sort of odd, agreed.

I don't think this can compete against Wikipedia. It can, however, serve as a supplement - it doesn't have the disadvantage of tyrannical, half-crazed admins. That makes it much freer than Wikipedia, in a sense, and that'll give it an advantage in quantity, if not quality.

</comment></comment></comment><comment><USER12> Curious the front page has "Who needs a search engine? Ctrl+F" on the right hand side above the listing of Knols...

<comment><USER7> I saw that as a typical example of Google humor. But from the way the site's laid out it also looks like they're trying to make Knol a standalone thing. They don't want people looking at this page and thinking Google.

<comment><USER13> If that was the case, they would probably get a dedicated domain for it instead of using knol.google.com.

<comment><USER7> Yeah. As I said elsewhere in the thread - that's weird for them. Possibly a sign of the product's being so new?

</comment></comment></comment></comment><comment><USER14> From the article:

 _We are happy to announce an agreement with the New Yorker magazine which allows any author to add one cartoon per knol from the New Yorker's extensive cartoon repository. Cartoons are an effective (and fun) way to make your point, even on the most serious topics._

Is today April 1? Does adding a pseudo-intellectual New Yorker cartoon to every page really make the information seem more useful to people?

<comment><USER15> I missed the cartoons bit. Where can I access the cartoons collection of the New Yorker magazine?

I am totally just going ratings whore on those knols. If a nice cartoons makes users rate my knols higher, that's fine by me - whatever. It is simply a game Google forces me to play to increase the search rank of my web sites.

<comment><USER16> _It is simply a game Google forces me to play to increase the search rank of my web sites._

Can you expand on that?

<comment><USER15> I assume that links from Knols will factor quite well into the search rank, at least if they also have good ratings. Therefore to compete with other sites on the same subject as my web site, I will have to create a knol with good ratings linking to my site.

Of course the professional SEOs will also fake the ratings by creating their own voting networks and so on. We will see...

<comment><USER16> Well, I'm assuming (hoping?) Google won't tamper with PageRank to give special consideration to Knols (if they did, the backlash would be huge). I don't really see how a Knol's rating would affect its impact on any external pages it links to - I'm assuming their search rank will be determined the same way as that of any other site, based on keywords and incoming links rather than rating.

<comment><USER15> That's the optimistic view, but I am not taking chances for the time being.

</comment></comment></comment></comment></comment></comment><comment><USER15> Great, another Google service I am forced to use to increase the search rank of my web site :-(

Edit: done entering a knol about "Mondkalender" (moon calendars). I really have mixed feelings about this... What would people's incentive be to write on knol rather than on their own blog? Presumably Knol articles will be rated higher, so Google's power forces people to use Knol (certainly no SEO will skip knolling). On the other hand with the rating and personal credibility effect, it could yield some interesting results.

</comment><comment><USER17> One of the reasons I love wikipedia is that its neutral and no ads. Google Im sure will have plans to stick in some adsense and share revenue with the author. Why should I contribute to an article bcos of which the original author might get paid.

Even if there willbe no ads , with the author's profile there, any contribution I may make doesnt feel like, Im part of it. I love all contibutors being annonymous in wikipedia

I vote this me-too project down.

<comment><USER18> Obviously Knol is structured to reward/encourage _authors_ , not _contributors_. Hopefully the result will be not a Wikipedia-killer but something with a different flavor.

<comment><USER17> Wont it be more like a blog then? Except ofcourse worrying about how to get traffic

<comment><USER18> Yeah, Google needs to add some kind of benefit that you can't get from just posting an article on your blog. The real name verification is interesting but hardly compelling.

<comment><USER19> They pay you a piece of ad money from your page. (If you want. You can also disable ads.)

<comment><USER18> Blogs also have this feature.

</comment></comment></comment></comment></comment></comment><comment><USER20> This looks like something really great. I think that a "google wikipedia clone" can only benefit the web, by offering innovative features to the "web encyclopedia" space. This is something distinctly different and I like it. From the short time i've spent on the site it looks like this could be pretty big.

<comment><USER21> You're joking right? Basically, they're going to populate their encyclopedia by pillaging the information out of wikipedia. Search engines should not be competing with content providers.

<comment><USER22> How can it be pillaging when the whole point of Wikipedia is that the information in it is free for everyone else to use?

<comment><USER5> Problem is that Google will rank their articles higher than Wikipedia's and will suck the traffic out of Wikipedia and then who will edit Wikipedia?!

<comment><USER23> If this is the case, then it would compromise the credibility of Google search results. I think it's too early to say for certain if Google views Wikipedia as such a huge threat that it would go out of its way to create a new project for the sole purpose of intentionally ranking them higher than Wikipedia.

Wikipedia is as much of an icon of the internet as Google. I'm predicting that Knol will go the way of Google Answers for the same reason why Digg remains a stalwart of user generated news - it's the community.

<comment><USER5> Google definitely views Wiipedia as a potential threat. Just look at their SERPs... Wikipedia links are usually in the top 5 on pretty much every factual term.

</comment></comment></comment></comment></comment></comment><comment><USER8> In other news, knol.com seems awfully slow today.

</comment><comment><USER24> The big difference I see is that you can have several competing knols on the same or overlapping subjects.

Big consequences \- you don't need to spend a lot of time and effort enforcing NPOV through consensus \- people can express their own POV

</comment><comment><USER25> The articles, even those by MDs, read like the sort of padded, plodding writing-for-hire crap used to manipulate Google's rankings.

Google should be fighting "MFA" (Made-For-Adsense) content, not joining the party.

</comment><comment><USER26> Still, what I'd like most from an open encyclopedia project is a simple, stable API. There are external projects bringing this to Wikipedia, but Google (API frontrunners that they sometimes are) don't have this at all. Hope they add it soon.

</comment><comment><USER27> Knol? Knoll?

Will there be any confusion with Knoll, the 80 year-old internationally recognized and respected design institution?

</comment><comment><USER28> What is to stop people from ripping articles from wikipedia and posting them en masse to earn adsense revenue?

<comment><USER18> Why would anyone visit such pages? Much will depend on how Google Search treats Knol pages.

</comment></comment><comment><USER29> Knol doesn't distinctly look like a google page. It seems like they are trying a new layout and design.

</comment><comment><USER30> Yet another attempt by Google!!! Knol.... hmmmm... Maybe Google should try acquiring wikipedia instead.. ;) !!!</comment>


Adobe releases public betas for next round of Creative Suite apps - <AUTHOR> http://labs.adobe.com/

<comment><USER2> It's worth noting that the betas only work for two days if not activated by a CS3 serial.</comment>


Does it scale? Who cares (2011) - <AUTHOR> https://jacquesmattheij.com/does-it-scale-who-cares <comment><USER2> Couldn't agree with this article more.

I built the biggest social network to come out of India from 2006-2009. It was like Twitter but over text messaging. At it's peak it had 50M+ users and sent 1B+ text messages in a day.

When I started, the app was on a single machine. I didn't know a lot about databases and scaling. Didn't even know what database indexes are and what are their benefits.

Just built the basic product over a weekend and launched. Timeline after that whenever the web server exhausted all the JVM threads trying to serve requests:

1\. 1 month - 20k users - learnt about indexes and created indexes.

2\. 3 months - 500k users - Realized MyISAM is a bad fit for mutable tables. Converted the tables to InnoDB. Increased number of JVM threads to tomcat

3\. 9 months - 5M users - Realized that the default MySQL config is for a desktop and allocates just 64MB RAM to the database. Setup the mysql configs. 2 application servers now.

4\. 18 months - 15M users - Tuned MySQL even more. Optimized JDBC connector to cache MySQL prepared statements.

5\. 36 months - 45M users - Split database by having different tables on different machines.

I had no idea or previous experience about any of these issues. However I always had enough notice to fix issues. Worked really hard, learnt along the way and was always able to find a way to scale the service.

I know of absolutely no service which failed because it couldn't scale. First focus on building what people love. If people love your product, they will put up with the growing pains (e.g. Twitter used to be down a lot!).

Because of my previous experience, I can now build and launch a highly scalable service at launch. However the reason I do this is that it is faster for me to do it - not because I am building it for scale.

Launch as soon as you can. Iterate as fast as you can. Time is the only currency you have which can't be earned and only spent. Spend it wisely.

Edited: formatting

<comment><USER3> > I know of absolutely no service which failed because it couldn't scale.

I would say this is because of the simple fact of visibility and adoption. You've probably never heard of these services probably because they ground to a halt with a mere 1000 users, so they never got mainstream enough to be recognised as a viable service. It is a bit like how no one remembers the dozens of people who failed to achieve sustained powered flight before the Wright brothers. Doesn't mean there weren't any, and scalability, technical or planning issues killed those efforts before anyone knew of it.

Some 'scalability' issues are inherent to your initial design, and not just the choice or configuration of your hardware/software platforms.

For instance, what if you were building a contact database of some sort. At first, you may have things like 'Phone Number' and 'Email Address' as part of the 'Person' database. Then, as your service gets popular, you notice people asking for extra contact like Twitter handles, LinkedIn pages etc. So you start adding _those_ to your Person table as extra columns.

Eventually, you realise that you should have though more about this at the outset and have contact details stored in another data table altogether, linked to a 'Contact Type' table and related back to the Person table. This would have been mitigated at the start via better database design and catering for eventualities that you might never have foreseen. Migrating the original database to normalise it is a massive effort in its own right, and probably will take _more_ time, cause more outage time, and cause more bugs in existing code than designing for that eventuality in the first place.

Even if 99% of your users only ever enter Phone and Email contact details, the second option, designed for scalability, will still handle that without a sweat, and 'scaling' to meet additional demands later is merely a matter of adding new contact types in the 'Contact Type' data table so that they become an extra option for all your users.

I am willing to bet that 9 out of 10 'weekend projects' have had to be thrown out completely and redeveloped from scratch when the number of users became significant. Of those rebuilds, I would be interested to see some research into how many users abandoned the said platform when (a) the original one started to grind to a halt or constantly fell over with errors and (b) the new platform came out with new features or a different UX that broke the 'look and feel' of the original.

<comment><USER4> You're refusing to learn from someone who lived it. I also know of zero services which failed because they couldn't scale their technology. But I know of 100s that failed because they couldn't get enough users or usage.

Your example about the DB tables is exactly the trap to avoid while you are iterating rapidly to try and find product/market fit.

<comment><USER3> You are assuming that I haven't "lived it". Over the past 2 or 3 years, I have built around 8 web apps. Some which got virtually no traction at all, and some which have reached a happy medium of users and income. None which have reached mega scale or millions of users (yet).

Some of the (real world) feedback I got from the web apps that failed to get off the ground were due mainly to our customers complaining that:

* pages were taking too long to reload.

* not enough fields on a particular data table to store information in

* missing API

* pages that would refresh in entirety instead of just updating the changed portions

Most customers didn't stick around to wait for us to address or fix the issues - there were plenty of other competitive products that fitted them better that they could start using that same day.

A couple of those sites also got negative feedback on Reddit or HN because I hosted the front end website on a $5 VPS server and when the site suffered the inevitable 'hug of death' from posting to these sites, they immediately went down due to inability to scale under the sudden deluge of visitors, and I received uncomplimentary feedback on that (where people actually elected to post feedback rather than just close the browser tab and completely forget and move on from my app).

Yes, over thinking scaling and design is bad, but putting it aside as a 'totally not important now' factor is also just as bad, if not worse, in my 'lived it' experience.

<comment><USER2> It is great that you got a few which got traction out of 8 tries. This is an incredible success rate.

Most people see much less success. The original suggestion is geared towards first few tries that people make. Once they have made a few attempts, they learn from it and naturally build more scalable products without spending extra effort. You have already read my story about my first try which had a very poor start. My subsequent efforts have scaled in that order without needing a single rewrite.

However, if they spend too long procrastinating, worrying about and investing in scale - they are wasting precious time which would be better spent finding product market fit.

<comment><USER3> Thanks, and also thank you for not reading my posts the wrong way. I am in no way having a go at you or refuting what you say. You've built something and got it to a level that many of us can only dream of, and for that you have my admiration and respect.

Like you, each subsequent app that I built contained the lessons learned from the previous efforts - better front end frameworks, better data table normalising, better hosting infrastructure etc.

Part of me always thinks back to the ones that _didn 't_ work, and I always ask myself - _would_ they have worked if they had faster page refreshes, or more flexible data entry? Perhaps if I had spent more time in the planning and design before I launched them, they may not have sunk as quickly? Those 1000 users that time who came from my HN post and saw an 'Error 500' page - could a fraction of them been the ones who would have signed up and made us profitable if they didn't see the error page as their first introduction to my app??

For that reason alone, I am always skeptical of any post that promotes 'iterate often and fast' or 'fail quickly' rather than 'spend time on design and a unique experience'...

<comment><USER2> It's all in good spirit of sharing and learning.

When you are thinking back, also consider the alternative where could you have missed opportunities and product launches because of extra effort spent on scaling upfront.

It's all good learning in the end. It's great to be in your situation. Keep at it and you will see great success in future!

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> I care.

It's easy to brush off scaling concerns as not important, but I've had personal experience where it's mattered, and if you want a high profile example, look at twitter.

Yes, premature optimization is a bad thing, and so is over engineering; but that's easy to say _if_ you have the experience to make the right initial choices that mean you have a meaningful path forward _to scale_ when you do need it.

For example, lets say you build a typical business app and push something out quickly that doesn't say, log when it fails, or provide an auto-update mechanism, or have any remote access. Now you have it deployed at 50 locations and its 'not working' for some reason. Not only do you physically have to go out to see whats wrong, you have to organize a reinstall at 50 locations. Bad right? yes. It's very bad. (<\---- Personal experience)

Or, you do a similar ruby or python app when your domain is something that involves bulk processing massive loads of data. It works fine and you have a great 'platform' until you have 3 users, and then it starts to slow down for everyone; and it turns out, you need a dedicated server for each customer because doing your business logic in a slow language works when you only need to do 10 items a second, not 10000. Bad right? yes. Very. Bad. (<\---- Personal experience)

It's not premature optimization to not pick stupid technology choices for your domain, or ship prototypes.

...but sometimes you don't have someone on the team with the experience to realize that, and the push from management is to just get it out, and not worry about the details; but trust me, if you have someone who is sticking their neck out and go, hey wait, this isn't going to scale...

Maybe you should listen to what they have to say, not quote platitudes.

Ecommerce is probably one of those things where the domain is well enough known you _can_ get away with it; heck, just throw away all your rubbish and use an off-the-shelf solution if you hit a problem; but I'm going to suggest that the majority of people aren't building that sort of platform, because its largely a solved problem.

<comment><USER6> The article is about choosing a business idea where technical scale isn't important. Twitter would fall under a "media play" which is what the author is telling the reader not to do. They aren't saying "try to build twitter but skimp on the tech" they're saying "don't try to build twitter, build something where people pay you money to use it and you'll be raking in millions in profit by the time technical scaling is an issue". Terrible example imo.

<comment><USER7> Twitter is not exempt. They focused on the product before scale. They were regularly overloaded in the early days.

</comment></comment></comment><comment><USER8> Taking a completely blasé approach to efficiency is potentially as dangerous as becoming hyper-focused on it.

Not all businesses become roaring successes, and those who achieve moderate success often don't get the resources to fix deep-seated performance or architectural issues (either via engineering and/or throwing hardware at it.) Eventually these technical woes can completely halt momentum and I've seen it even drown some businesses who just aren't able to dig theirselves out of the hole the find themselves in.

People always seem to be arguing for extremes, but the most sensible approach for most tends to be somewhere in the middle.

<comment><USER2> Agreed that completely blasé is pretty bad.

However in this case being blasé would mean, not working hard to scale when you users are getting a bad experience. A basic stack these days node.js+mongo, go+*sql can easily handle more than 100k users even with one of the worst implementations. Most products don't reach that point!

<comment><USER8> > A basic stack these days node.js+mongo, go+*sql can easily handle more than > 100k users...

That is making some very large assumptions about application workload. For an application which is purely a CRUD interface to a database, yes.

<comment><USER2> Agreed on this point.

Many a times there is heavy lifting - recommendations, machines learning etc. However that is don't using specialized technologies in a non user facing process and the results are then dumped into a DB available for a CRUD app.

I am hoping that products with such requirements will have some obvious tools for such tasks (Hadoop, Hive etc) and they would find a way to scale such processes with time.

So their stack might be go+*sql+Hadoop.

Can you please suggest some use-cases which don't fit the above pattern and maybe we can brainstorm. Seems like a fun exercise!

</comment></comment></comment></comment><comment><USER9> I agree with the general premise of avoiding premature optimizations, but designing systems that scale is important for several reasons:

\- Startups grow exponentially, if you're playing catchup as you're growing you are focusing on keeping the lights on and hanging on for the ride. Important for a growing company to focus on vision.

\- Software that scales in traffic is easier to scale in engineering effort. For example, harder for a 100 engineers to work on a single monolith vs 10 services.

\- Service infrastructure cost is high on the list of cash burn. Scalable systems are efficient, allow startups to live longer.

\- If the product you are selling directly correlates to computing power, important to make sure you are selling something that can be done profitably. For example, if you are selling video processing as a service, you absolutely need to validate that you can do this at scale in a profitable manner.

I also don't agree with the premise that speed of development and scalable systems are always in contention. After a certain point, scalable systems go hand and hand with your ability to execute quickly.

<comment><USER10> In the projects that I was involved in in the past years, the ones that decided to build a scalable infrastructure before gaining traction were exactly those that were burning cash on infrastructure. There is just a reasonable minimum of servers you need to run such an infrastructure and then you need something similar as a staging environment to make sure it all works together correctly.

That being said, there are of course choices that can be made early on that will help you in case you need to scale at some time. Spending a bit of time thinking through what would happen if you do need to split up and scale out your system will help you avoid pitfalls such as relying too much on the local filesystem being shared across pageviews.

In general I believe there is more benefit on spending time on performance early on. (not caching, that is just postponing the problem) as it benefits not just your ability to run on a single system for much longer, it will also make life better for your users.

<comment><USER9> Scalable system does not imply needing many machines. There is no reason you can't just deploy your entire system on a single host, but maintain the ability to reconfigure exactly when needed.

But yes - its about finding the right balance.

</comment></comment></comment><comment><USER11> I care because it usually goes like this: Product manager > "Niche sass app {x} will never need to support more than 10-20 users"

Two weeks after launch > "We have 10k users and counting, why didn't you architect this for scale?"

Always assume you underestimated the scope of the project.

<comment><USER12> I've literally been waffling back and forth between UUID and BigInt for the last week. The reason for this is I need to handle eventually distributed systems. Do I need UUIDs? Maybe not, but after much debt, I've decided that the storage requirements of such an index in memory is worth the ability to move from Postgres to Postgresql-xl.

<comment><USER13> The problem is not with memory problem is that after checkpoint postgres will do full page writes for serial you will be touching way fewer pages compared to UUID so write amplification for UUID vs bigint can be 60X+

<comment><USER12> Can you go into a bit more detail? I've seen amplification referenced before. My estimation is that the database will be pretty much read heavy. I will need to split a given database across multiple instances.

<comment><USER13> [https://blog.2ndquadrant.com/on-the-impact-of-full-page- writ...](https://blog.2ndquadrant.com/on-the-impact-of-full-page-writes/) this is fairly detailed analysis of this issue

<comment><USER14> How about simply using non-random UUIDs?

<comment><USER13> That would def. help

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> I'm in the unfortunate position where this question actually matters from day 1. I learnt the hard way a few days ago when I hit the bottleneck (about 50-100 concurrent users) and I'm not sure how to proceed.

It's a multiplayer drawing site built with Node.js/socket.io. I'm already on the biggest Heroku dyno my budget can allow and it's too big of a task to rewrite the back end to support load balancing (and I wouldn't know where to start). Bear in mind that this is a side-project I'm not making any money of.

I had a lot of new features planned but now I've put development on hold. It's not fun to work on something you can't allow to get popular since it would kill it.

<comment><USER16> Socket.io can't handle many connections you're right. I would use (universal) Web Sockets (This is a good abstraction library, very easy to implement).

[https://github.com/primus/primus](https://github.com/primus/primus)

Maybe put it on a Digitalocean Server and just reference your Dyno's IP address if possible.

<comment><USER15> Thanks! Looks good so that's definitely something I should look more into.

</comment></comment></comment><comment><USER17> Flexibility vs efficiency. Agile vs high momentum.

As a rule of thumb, start-ups need to be more agile as they are mostly exploring new territory, trying to create new value or re-scope valueless things into valuable things.

Larger companies operate at a scale where minor efficiency improvements can mean millions of dollars and thus require more people to do the same thing, but better. Individualistic thinking on new directions to go is not needed nor appreciated.

Of course there are excepttions. The question boils down to whether or not the ladder is on the right walk before charging up it.

In rare circumstances you can do both. Either the problem is trivial, or the problem becomes trivial because you have a super expert. 10x programmers who habitually write efficient code without needing to think too much have more bandwidth for things like strategy and direction. The car they drive is both more agile, accelerates faster, has a higher max speed, etc...but even this can't move mountains. The problem an individual can solve, no matter the level of genius, is still small in scope conpared to the power of movements and collective action and intention.

The most poweful skill is to seed these movements and direct them.

Abstractly, this is what VCs look for in founders and also a reason why very smart and technical people feel short-changed that they are not appreciated for their 10x skills. (Making 500k instead of millions/billions) They may have 10x skills, but there are whole orders of magnitude they can be blind to.

</comment><comment><USER18> The reason scale isn't so important today is because most DBs can actually scale vertically to really high numbers. The tipping point is high enough that if you have this problem, you probably can also afford to fix it.

What matters though is performance and availability. No matter what scale you work at, you can't be slow, that will drive people away. You also can't be unavailable. This means that you might have to handle traffic spikes.

Depending on your offering, you probably also want to be secure and reliable. Losing customer data or leaking it will drive customers away too.

So, I'd mostly agree, in 2016, scale isn't a big problem. Better to focus on functionality, performance, security, reliability and availability. These things will impact all your customers, even when you only have one. They'll also be much harder to fix.

Where scale matters is at big companies. When you already have a lot of customers, you're first version of any new feature or product must already be at scale. Amazon couldn't have launched a non scalable prime now, or echo. Google can't launch a non scalable chat service, etc.

<comment><USER19> > Where scale matters is at big companies. When you already have a lot of > customers, you're first version of any new feature or product must already > be at scale. Amazon couldn't have launched a non scalable prime now, or > echo. Google can't launch a non scalable chat service, etc.

This is the point I was going to make. When you are designing the very platforms on which all these "does it scale? who cares" startups are going to be built, you do not have the luxury of having that attitude. Definitely don't take that mindset into an interview at google or amazon. :)

I do agree with the OP's sentiment for startup projects in general. I have had the experience of worrying about scale too early and over-engineering a system which never had more than a few dozen users, and the opposite experience of tossing something together that wouldn't scale and then going through the hairy scrambling at every order of magnitude of scale through tens of millions of users. The latter was definitely a better strategy.

</comment></comment><comment><USER20> Healthcare.gov was a site that failed and suffered due to scaling issues.

However, it was an anomaly because unlike a product someone this article is intended towards would be building, that site had an immediate audience of millions of users from the get go.

Also, the fact that it took a few weeks to be rewritten to handle the load at which point it became extremely successful, strengthens the original article's point.

By the time scalability becomes a problem, you will have enough resources to tackle the scalability problem.

<comment><USER21> This is not an anomaly.

It's the norm for all government projects, and most projects started in established companies that already have millions of users.

To be working in these domains, the "doesn't need to scale" mentality" is very inappropriate and I find it to be doing a lot of damages.

The guys at healthcare handled most the scaling problems, accounting for the means at their disposal and the time frame they had, judging by what was published in the news. That it took a few weeks to smooth showed that they handled scaling beforehand. A launch from 10 users to 10 million is always a bit bumpy for the initial weeks.

</comment></comment><comment><USER22> No one else bothered by "End-to-end tracking of customers" as the primary concern? Ok then.

On the subject of scaling, I think it's good to have an idea in your head about a path to scalability. One server, using PHP and MySQL? Ok. Just be aware you might have to load balance either or both the server and DB in the future, and that's assuming you've gotten the low hanging fruit of making them faster on their own. But as this thread's top comment illustrates, learning that stuff on the fly isn't too hard. So maybe it's better to make sure you're going with technology you sort of know has had big successes elsewhere (like Java, PHP, or MySQL) and even if you're not quite sure how you might scale it beyond the defaults you know others have solved that problem and you can learn later if/when needed.

</comment><comment><USER23> He makes the valid point that performance for each individual user, like page load time, does matter. Just that building for an audience size you don't yet have is mostly wasted time.

Seems reasonable. I wonder, though, if PHP feels like an anchor to the average Facebook developer. I realize they architected around it, but it must have some effect on recruiting, retention, etc. I use PHP myself, and don't hate it, but the stigma is there.

<comment><USER24> Any stigma should be prioritizing tech over the business. Your business exists to turn a profit, stack be damned.

<comment><USER23> That works to motivate some employees, assuming their comp is relative to your business success. Facebook has been able to do that for some time, but there's probably a plateau or two in their future.

</comment></comment></comment><comment><USER25> The overall premise of the blog is exactly correct; though I would say some areas you probably need to consider more than others.

Spending a lot of time figuring out what exact microservice/sharding/etc strategy you need to serve a zillion visits a day and building it before you've even got customer/visitor one is overkill out of the gate. But that shouldn't mean you shouldn't think about how you'll scale over the short term or medium term at all.

When I approach scaling, I'll tend to spend much more time on the data retention strategy than anything else: databases (or other stores), being stateful, means that it's a harder problem to deal with later than earlier as compared to the stateless parts of the system. Even so, I'm typically not developing the data services for the Unicorn I wish the client will become, I'm just putting a lot more thought into optimizing the data services I am building so it won't hit the breaking point as early as it might if I were designing for functionality alone. I do expect there to be a breaking point and a need to change direction at some point in these early stage designs. But in that short to medium term period, the simpler designs are regularly easier to maintain than the fully "scalable" approaches that might be tried otherwise, and rarely do those companies ever need anything more.

</comment><comment><USER26> I like the overall idea here. Focus on building something quality first then worry about scaling later. Most servers can handle a decent amount of traffic. Seems like common sense to me. I guess some people can get too hung up on engineering to make their site scale before actually deploying or innovating on the product. Wonder if people have encountered this in the workplace before?

<comment><USER27> I think the point is to make something that makes money first, then use the money to make something quality.

</comment></comment><comment><USER28> I agree with this article; however, there are considerations that can be made early on, to ensure an easy path for future scalability, that don't waste any time or money during the project's nascency. For example, if I know I want my app to scale at some point in the future, I may opt to build it in Elixir, or I may choose to use a Riak cluster rather than of MySQL.

</comment><comment><USER29> Ok but please don't do things like using nested array searches with bad runtime when you can use hashmaps instead. I hate seeing code or using programs that are extremely unoptimized.

<comment><USER23> That seems to be the real story behind most "We switched from stack X to stack Y and gained an Z-fold increase in performance" stories. They tend to leave out the "and we also fixed some generically bad things we found when porting".

</comment></comment><comment><USER30> Once worked at a startup where we expected 'some activity' in our webshop at product launch, and didn't think about scaling for that. Well, some activity turned out to be 450mbit/s for five hours, which our unscalable application/webshop didn't handle very well. It became overloaded in the first minute, and took us more than an hour to get remote access again. It's one of those things we did better for our next big event (major sharding, basically replicated the application 32 times of the largest VM instance we could get. It was needed and it survived).

</comment><comment><USER31> I agree with this article only for launching new products. But if you already have a product which is serving millions of customers, you better worry about scale while you change anything.

</comment><comment><USER32> While a point the article tries to make (fix your leaky funnel before acquiring users) is true, I disagree with the article. If your application is converting well, scalability problems are not acceptable.

I have seen applications that convert very well, but were limited by scalability problems. That meant that the business had to hold on on marketing and user acquisition, missed their financial targets, and that cascaded into breaching contracts. The phrase that nobody wants to hear in that situation is "who cares about scalability".

Now, if you did not have a lot of problems scaling in your particular case, that just means it was not an obstacle for you. e.g: you had good intuition around performance/scalability, or the problem was coincidentally a good fit for your technological choices.

Unfortunately not everyone has a good intuition about scalability, not everyone is risk averse and not everyone is good at picking a good technology for their use case. So I disagree with this article in the sense that it is not in the best interest of a random reader to not care about scalability.

</comment><comment><USER33> Having working on an app that we just throwed more hardware at, to the point where the azure subscription cost could be lowered by my whole anually salary, by 3 months work of optimization.

I believe performance does matter. We where a 4 person team and could have added a fifth if we had a cheaper design.

</comment><comment><USER34> I started working at a company 6 months ago, and in that time I've fixed a half dozen performance problems.

Some of them didn't matter THAT much, but some of them did. My team manages an authentication -service. Some of the calls were averaging hundreds of ms which added terrible overhead to other services' calls. In other places had CICD builds running tests twice, logs logging twice, inefficient algorithms, single HTTP transactions making dozens of DB calls. You name it.

Some of these were simple things that if you stopped to smell the roses you could notice and fix.

Let's all be boy scouts and make code better while we're in it :)

</comment><comment><USER35> In general: don't fix a non-existing problem. You don't know beforehand what the problems of the future look like. Fancy technology X of today is technical debt in 10 years. So do invest in solving technical debt along the way in products you keep.

</comment><comment><USER36> There is a similar argument with regard to making code reusable. I have seen inordinately complex code come from a desire to make it reusable, even if the prospects for it being reused were slim to nonexistent.

</comment><comment><USER37> Evolution is a beautiful thing.

I once worked for a monolith who decided to invent a new way of programming. They built something massive and ready to scale even larger. And then they discovered no one wanted the product.

</comment><comment><USER38> Fundamentally disagree with the ethos of this article. What about ambition? What happened to that?

> You won't make the cover of Time Magazine and you won't be ordering a > private jet but that Ferrari is a definite possibility, if that's the thing > you are hurting for. (college education for your kids is probably a better > idea ;) ).

I'd like to be on the cover of fortune or as Russ Hanneman might say, "I wanna make a fuckton of money all at once".

I don't see any problem with being ambitious or wanting that private jet.

</comment><comment><USER39> A better title would be: scalability is a luxury problem.

</comment><comment><USER40> Came across a service last week with a free trial and paid plan. How to upgrade? Contact by email! Why spend time and resources on a payment process if you don't have any paying customers yet?

Obviously not right for everyone, and I'm not saying it doesn't have its own challenges, but the core product deserves the most attention early on.

</comment><comment><USER41> I do agree, but being at the "we need to scale up asap" stage atm makes it harder to. There's a balance to be struck. Maybe about approach of "who cares" with the POC, MVP etc stages, then keep it more and more in mind at each stage after that would be best.

</comment><comment><USER42> It really depends the type of growth. Organic growth is driven by the quality of product therefore scaling issue comes later. But most venture-backed startup services such as O2O need quickly dominate market by throwing cash to get users so scaling is an issue from day one.

</comment><comment><USER43> i concur. it's fun to dream, but sadly, statistically most of us will never have to worry about scaling! so save yourself the energy and don't worry about it.

</comment><comment><USER44> IMHO until you hit scalability issue don't try to spend your time and money there yet

</comment><comment><USER45> I agree BUT it's not that hard to ensure your app scales. It's more about using appropriate tools for the job.

</comment><comment><USER46> Can we have (2011) in the title?

</comment><comment><USER47> I liked the article and agree with its premise. But as a side question, why do developers use so many parenthetical expressions?

Those ideas (like this one, which happens to add nothing) are often either throwaway statements (like this one) or are by themselves complete thoughts that should be a separate sentence. (I see this so often in posts written by devs.)

<comment><USER48> Nice writing :)

I would blame it as commenting habit. Need to explain everything twice. "What if the reader doesnt understand _exactly_ what I mean?"

<comment><USER49> So use a separate sentence or formulate your ideas more clearly? I see this so often when developers write. From tutorials to official documentation etc.

Extra words where a simpler sentence would have sufficed, poor structuring of ideas, not splitting text into appropriate paragraphs and sentences. I always feel dumb until I figure out what was trying to be said and then you realise just how poor the writing is.

<comment><USER50> You should write a post on the parallels between legible code/english.</comment></comment></comment></comment>


Stop, just do it. - <AUTHOR> https://medium.com/@johndavidback/stop-just-do-it-c17195042644 <comment><USER2> Excellent post! The feeling of having accomplished and learnt after going through those task lists at work or with kids or managing money is something unexplainable & you have put it in words. Bookmarked !</comment>


ManyActive App – Classpass for Africa Launched in Nairobi - <AUTHOR> https://play.google.com/store/apps/details?id=com.app.manyactive <comment><AUTHOR> No more rigid membership programs, no more rigid schedules, no more being blindsided by subpar quality of service across Africa. ManyActive provides flexibility, reliability and affordability to fitness and wellness clients through its booking membership platform.</comment>


Type Folding in Guile - <AUTHOR> http://wingolog.org/archives/2015/10/29/type-folding-in-guile <comment><USER2> I have a WIP game engine written in Guile that is eagerly awaiting the day that this optimization makes it into a release. I was thinking about creating a small C library to supplement the Guile codebase whose sole purpose was to perform the currently expensive floating point math stuff like matrix multiplication and vertex buffer packing. Looks like I should be able to use pure Guile after all. Awesome!</comment>


IPhone 4G: is this it? - <AUTHOR> http://www.engadget.com/2010/04/17/iphone-4g-is-this-it/

<comment><USER2> If this is a prank, I'm really impressed by whoever thought it up.

<comment><AUTHOR> yeah, it's pretty elaborate if it's a hoax. I believe engadget has been hands on with it themselves, right?</comment></comment>


Prehistoric Art Found to Contain Stenciled Lizard Hands - <AUTHOR> http://www.livescience.com/53944-prehistoric-rock-art-nonhuman-hands.html <comment><USER2> "It's unclear why the ancient people at Wadi Sūra II used reptile hands as stencils, but Honoré said she's working on a tumblr post that analyzes possible reasons."

...Tumblr is now where scientific articles get published?

</comment><comment><USER3> That entire process described seems rather bizarre - as just _glancing_ at that image I can see that those are lizard feet stencils - and the fact that she had the brainwave after visiting an crocodile farm underlines how clear they are.

I wonder how many research opportunities are missed because scientists hoard information that is mysterious to them but obvious to others.

I suppose it's the broken publication system that drives this behaviour.

<comment><USER4> Well, I'm sure future people will figure out if it's obvious to madaxe_again and skip the tedious process of hypothesis and argument.

<comment><USER3> My point was rather that she went depth-first (i.e. let's exhaustively study baby hands) rather than breadth first, due to her specific domain of knowledge. Had the material been shared with a broader audience of her peers, perhaps it would have saved rather a bit of time and effort.

</comment></comment></comment><comment><USER5> Sometimes I think people need to spend more time outdoors. Because before even reading the article, I took one look at the pictures, and thought, "Oh, ok, animal tracks."

</comment><comment><USER6> Of all the animals in the world, it had to be a lizard. This is going to fuel about 2 more years of InfoWars.com speculation on the lizard people

</comment><comment><USER7> Flintstones. Meet the Flintstones. They're the modern stone age family...

</comment><comment><USER8> inhabitants of Lovecraft's Nameless City

</comment><comment><USER9> Non-clickbait link title: Prehistoric Art Found to Contain Monitor Lizard Hand-Stencils

<comment><USER10> Haha.. sheesh man, it is super sad when a "science" site uses such a blatant clickbait title. Shame on them.

</comment></comment><comment><USER11> I just hope the new and 'improved' X files show, won't try to take this subject as an opportunity to make yet another dubious episode ... Seriously though, could simply be a deformed human hand.</comment>


Ask HN: What are red flags when you interview prospective people? - <AUTHOR> Although I'm curious about most things, I'm more curious about technical stuff, like is a certain set of developer/programming habits (or lack there of) that in your eyes count against an applicant? <comment><USER2> DHH's perspective addresses some of your question:

[https://medium.com/@christophelimpalair/why-the-founder- of-r...](https://medium.com/@christophelimpalair/why-the-founder-of-rails- automatically-rejects-80-of-software-engineer- applicants-4e2a4d255f58#.nfpjoaub0)

</comment><comment><USER3> Have them explain to you what they have understood of your line of business. If they show no interest or are not willing to be "corrected" when they (inevitably) make a mistake, you have a non-team player in front of you.

</comment><comment><USER4> Not being able to explain things that are on their resume.</comment>


Sampling and Measuring Generators: Tutorial - <AUTHOR> http://www.possibilityspace.org/tutorial-sampling/ <comment><USER2> Why does your website not have RSS feeds?</comment>


Using D3 and Meteor to generate SVG - <AUTHOR> http://blog.benmcmahen.com/post/41124327100/using-d3-and-meteor-to-generate-scalable-vector

<comment><USER2> Since I wrote this tutorial, I've substantially rewritten the d3/timeline portion of the website. It's a bit cleaner and more efficient now. [https://github.com/bmcmahen/Subtitles/blob/master/client/scr...](https://github.com/bmcmahen/Subtitles/blob/master/client/scripts/timeline_class.js)

</comment><comment><USER3> Wanted to see but last link 404's - [https://github.com/bmcmahen/Subtitles/blob/master/client/scr...](https://github.com/bmcmahen/Subtitles/blob/master/client/scripts/timeline.js)

<comment><USER2> Ah, apologies. I wrote this a while back and the repo has changed within the last month. I'll update the links. Thanks for catching this.

</comment></comment><comment><AUTHOR> This might help <https://github.com/bmcmahen/Subtitles></comment>


LiShield Is a Smart LED Bulb Prevents Photos by Confusing Cameras - <AUTHOR> https://petapixel.com/2017/11/03/led-light-bulb-protects-privacy-confusing-cameras/ <comment><USER2> Very cool. Does it work against HDR? Or can you remove the noise by combining multiple exposures?

<comment><USER3> Would be a pain in the ass to remove either way. I'm very sure though, that long exposures work just fine.

</comment></comment><comment><USER4> EW comes to cameras...

</comment><comment><USER5> What are the health risks?</comment>


Wisconsin company to offer microchip implants to its employees - <AUTHOR> http://kstp.com/news/wisconsin-company-to-implant-microchips-in-employees-three-square-market/4549459/ <comment><USER2> Can someone explain why people prefer implants over rings? Functionality wise it's same: read on RFID tag, maybe with some light computation.

People wear rings all the time, application is painless, easy to change once compromised or if there is a new model, and provides same features. Chips would have advantage if they would provide better IO, but currently they don't.

<comment><USER3> I guess if you want 100% 'coverage' an implant wins. A ring could still be forgotten.

But I agree the disadvantages of the implant make the ring sound better.

<comment><USER4> I have had NFC rings and I have gone through a few of them because they break or fall apart, particularly when I would need them most.

Thankfully I have 2 NFC implants so it has been no big.

</comment></comment></comment><comment><USER5> Meh. I got an rfid implant in 2010 ish, but took it out after a few years because there were so few benefits. If there was a universal standard maybe, or if the range was > 10 cm, or if it had more than a few bytes of memory. I think most people who got a chip implant over the last 10 years came to the same conclusion. The only applications that show up in the press every now and then are like this - for payments. But never something that is widely available.

It's great to get yourself labeled a freak though. I got mine done in a a piercing shop, and when I walked in, the place was full with people with dozens of facial piercings, stretched earlobes and full arm and neck tattoos. But as soon as I mentioned the chip implant and showed that I was serious by showing the actual one I wanted put in, they all started murmuring and looking at me like I was send back in time from the year 2210. The owner wasn't sure how to feel when I pulled out a laptop and rfid reader and grinned like an idiot when I successfully logged on to the machine by waving my hand over the reader.

<comment><USER6> Got rid of it? Why not just leave it in?

Also, I think you can get chips with kilobytes of memory easily. Sure, not enough to store too much data on there, but fairly reasonable for a bunch of stuff.

<comment><USER5> Well it was still a foreign thing floating around in my hand. Back then I still trained bjj/mma and I was always slightly nervous it would break or pinch a muscle or something. Since it was of no use anyway, I figured it'd be better to take it out.

Re: memory, what would be a useful use case for having a few kb of data under your skin? It's not enough to store e.g. crucial documents, plus you need a custom reader.

When I got it, I thought 'uses will pop up when I have one'. Turns out they didn't, and it wasn't for lack of trying. Most people have come to the same conclusion.

(Amal Graafstra, one of the earliest people who did it and blogged about it, made a career out of it - but that's only realistic for the first person to do it)

</comment></comment></comment><comment><USER7> Two things I'd want to know before even entertaining the idea:

1\. Are these safe during an MRI?

From what I've been able to find some chips seem fine during an MRI (Kari of MythBusters had one implanted and had an MRI done with no problems on an episode), but the FDA lists MRI incompatibility as a potential health concern for chip implants.

At least one manufacturer that says their chips are safe for MRI do say that people undergoing an MRI with their chips need to be continually monitored visually and aurally and told to alert the operate if the feel anything unusual, and patients who are sedated or anesthetized or confused should not be given MRIs.

2\. Will these show up during the security check at airports? I dislike commercial air travel to the point that I have no intention of ever taking it again, but if I do, or if these oppressive security theater shows get extended to other forms of transit that I'm still currently open to, I don't like the idea of something that might trigger more extensive screening.

Bonus concern: how standardized is this stuff? If implanted chips for payments, opening doors, etc., take off and all kinds of places support them, is one chip enough or am I going to need one to unlock my office, one for my home, one for my car, one to pay via my credit card account (or worse, a separate one corresponding to each credit card account), one for buses, one for each store's rewards program, and so on?

<comment><USER8> > how standardized is this stuff?

Yeah, this is a good question. Something Visa-level reliable might make sense, conditional on your other questions. But getting the Discover implant that doesn't work most places? Or the Diner's Club implant that's the first big player but fades in popularity?

I don't really want to take sides in a format war using my own body.

<comment><USER9> There's literally only one time I've tried to use a Discover card and not been able to, and it was a local DQ franchise (yet they still took amex?). My wife's daily driver is her Discover It card, and even traveling to small rural towns she's never been in a situation where she had to break out her shelved Visa cards.

<comment><USER8> Huh... Now I'm confused, I seem to see them fail maybe 20% of the time, anywhere except the biggest cities. Maybe it's regional?

<comment><USER9> That's possible, but both here in Idaho where we live and Mass. where we went for Red Hat Summit this year my wife hasn't had issues using her discover card aside from at that one DQ franchise.

I know many years ago on various credit forums the joke was always that Discover has really bad acceptance rates, but generally speaking I'm much more likely to see a business decline to take an AmEx than Discover assuming they take credit cards at all. Discover's transaction fees are extremely similar to Visa and MC, and most merchant accounts handle it without issue so why not take it?

Personally from a cardholder point of view, my wife loves her Discover card because they're the only bank she has a card with that doesn't make her wade through phone menus only to get routed to some outsourced call center 1/2 the time - having the first option presented when you call being "press 0 to talk to somebody" and always getting an American support representative is pretty awesome.

</comment></comment></comment></comment></comment><comment><USER10> The justifications for this are so utterly marginal. I'm sure some could benefit but it's vanishingly few people who will.

A ring (as others suggest) gets you most of the benefits - and maybe rings have the downside of being forgotten, but I've left my work passcard a few times over the years and it's not the end of the world... Not so bad I'd prefer a minor surgical procedure! And the supposed advantage of not getting it caught in things? I might change my mind when I personally know five people who've lost limbs, but right now I know zero people who lost limbs...

<comment><USER8> > And the supposed advantage of not getting it caught in things?

There are definitely people who take off their rings regularly, like electricians and climbers. But even then, I virtually never hear about them _losing_ rings, and they can put them on any time they'd be shopping. I'm really missing the advantage here.

</comment></comment><comment><USER11> I remember talking to an ex colleague who worked for now no longer relevant mobile operator, about the setup his colleagues had who worked in Korea:

\- they were required to have their "tags" on them all the time as it opened door and things like that...

\- but they were also timed on when and how long their toilet breaks were. Or if they went to the canteen too early or stayed too long for their lunch. For all the "offences" their pay was docked.

</comment><comment><USER12> OK, maybe I'm old or old-fashioned or just not creative enough...

But what exactly are the advantages of this implant over NFC-cards or something like Apple Pay? That I cannot forget my card or my phone? I don't even know when this last happened to me...

<comment><USER13> Hygiene and safety, I would guess. A card in a lanyard can get caught up in all sorts of machinery and even a wristband can be slightly difficult to keep clean.

<comment><USER14> Um, almost the same applies to hands and arms.

<comment><USER15> I don't know about you, but my body's sense of proprioception[1] doesn't extend to lanyards or other things attached to my clothing.

[1]: [https://en.wikipedia.org/wiki/Proprioception](https://en.wikipedia.org/wiki/Proprioception)

<comment><USER14> Yeah, but getting your arm ripped off by some machinery is also rarely deliberate.

<comment><USER16> I think the fact that you're arguing this shows that you've never worked around heavy machinery.

</comment></comment></comment></comment></comment></comment><comment><USER17> Funny they think GPS tracking is the problem with this.

The problem is that it's a way to check your identity even if you'd prefer not to voluntarily provide it. I can scan you as you pass our flower pots without your knowledge and, even if, at first, I can't identify you, with time I will.

And by then you won't be able to easily remove the implant.

<comment><USER18> Facial recognition is improving so rapidly that having an extra microchip does not seem to add much value for identifying people. It's simpler to get the same information from cameras, which are ubiquitous. On the GPS side there's all that location data streaming out of your cell phone, not to mention the semantic information about what you are looking at/doing on the Internet.

There's a lot to be concerned in the privacy realm but many of the threats are already implemented and getting more effective very quickly.

<comment><USER17> Face recognition is not that great and can be defeated with some tricks (never tried IR paint, but I guess it'd be effective at night). You can also leave your phone in the car or at your house, or give it to someone else who'll be you to those sensors.

It's much harder to detach (and reattach) your hand.

Also, I never volunteered to be tagged by facial recognition (except for my passport) and these people are volunteering to be tagged.

</comment></comment></comment><comment><USER19> Someone asked "Why not a ring instead?" and someone mentioned they had the imbed done by a tattoo shop full of people with piercings, etc.

So my thought was combine the two into an RFID nose ring or something.

But the downside is you'd have people swiping various body parts in checkout lines. "It didn't go, try again. Wait, please don't try again."

</comment><comment><USER20> Good to know you can steal money from these employees with a handshake.

<comment><USER21> I was wondering the same thing. What happens if you find a hardware fault/vulnerability, and the company has to recall the chips? Do you disable it and leave it inside the person? Do you cut your hand to get it out? This is a bit hilarious tbh.

</comment></comment><comment><USER22> I liked the part about it being encrypted and secure. Uh-huh. At least until one of these employees picks up something with an embedded RFID cloner... Even if the underlying data in encrypted and considered unusable by the 'bad guy', they can still use it in the encrypted form to impersonate the employee... sooooo....

¯\\_(ツ)_/¯

Implants are great for both the novelty and the convenience, but I don't like it being pitched as somehow being inherently more secure than a standard access card or whatever (beyond it being more difficult to have your hand stolen or misplaced).

</comment><comment><USER23> Queue fundies freaking out about the Mark of the Beast.

</comment><comment><USER24> How would/could this kind of stuff work with e.g. EMV / contactless payments? Or, OpenPGP over NFC?

I've seen tons of RFID implantable chips which aren't that interesting, I've also seen NFC ones but they just look to be read/write storage...

</comment><comment><USER25> Amazon Go figured out how to do this without implanting microchips in people.

</comment><comment><USER26> The title is, of course, misleading. They are offering employees a microchip implant. It's not required.

Still crazy that anyone would opt-in to do this, but a misleading headline all the same.

<comment><USER27> I dunno, I'm surprised you thought it was mandatory. Pretty confident in the state of Wisconsin you cannot force someone who does not have life threatening ailments surgery.

<comment><USER28> The original title is "Wisconsin Company To Implant Microchips In Employees", which is different from the current "Wisconsin Company To Offer To Implant Microchips In Employees".

The difference is not so subtle; atfirst I assumed too that it was mandatory.</comment></comment></comment>