Is C# a low-level language? - <AUTHOR> https://mattwarren.org/2019/03/01/Is-CSharp-a-low-level-language/ <comment><USER2> If you really wanted to, you can program in a subset of C# that is similar to C. You can avoid the garbage collector by using a native memory allocator and then manipulate pointers with the usual * and -> operators.

While you probably don't want to write a whole program like that, sometimes it is helpful to use these features when porting code from C or for performance reasons. See for example this implementation of memmove that is used for copying strings and other things:

[https://github.com/dotnet/coreclr/blob/7ddd038a33977b152e856...](https://github.com/dotnet/coreclr/blob/7ddd038a33977b152e856448443425cbc6b591c6/src/System.Private.CoreLib/src/System/Buffer.cs#L183)

<comment><USER3> This is basically what I do. We don't have real time constraints, but we do have a limit to how long processing can take so we need to shave as many ms off how long our code executes as possible, so we pretty much use just the bare minimum features of the language and profile the crap out of everything.

One could argue that C# wasn't the best choice, but that was out of my hands.

<comment><USER4> Are you able to share any examples of functions where writing C# like that gave measurable benefits? I'm over in web-land and it's rare that C# itself is the bottleneck.

<comment><USER5> One example from my line of work that could conceivably translate to web-land would be parsing numbers. I wrote a version of double.Parse() with less features for an order of magnitude speedup. The program was doing data analysis on a bunch of CSV files, and just parsing the files was way slower than EBS I/O.

</comment></comment></comment></comment><comment><USER6> For those saying a GC is too high level, malloc is also a high level abstraction. There are relatively simple implementations of malloc, but allocators like jemalloc are starting to look quite a lot like a GC in the ways they manage memory.

The real issue with GCs is the lack of control that makes it very difficult if not impossible to do things like grouping allocations together. However, this capability comes at a cost since then you can't move around existing allocations without going to extreme lengths and can easily lead to memory fragmentation.

</comment><comment><USER7> This conflates the language, a particular implementation of that language, and a particular runtime that said implementation uses.

As far as the language goes, you can do anything in C# that you can do in C in terms of memory-unsafe programming - raw pointers, pointer arithmetic, unions, allocating data on the stack - it's all there, and it's not any harder to use. Since semantics are the same, it should be possible to implement it just as efficiently as in C. At that point, the only overhead that you can't remove by avoiding some language feature or another is GC, although you can avoid making any allocations through it. So the real question is whether a language with GC can be considered low-level.

</comment><comment><USER8> C# is managed code, so no, it's not low-level by any reasonable definition of the term and calling it so would be confusing to anyone getting started in this stuff.

<comment><USER9> C# _targeting the .Net runtime_ is managed code. There are subsets, including Unity's new HPC#, that compile directly to assembly.

I think it's important to separate the language from the runtime so people come out less confused versus conflating them to cover the 90% use case.

<comment><USER10> Pedantically asserting that it's possible to use a subset of a language and feed it through a special compiler to write low level code is _not_ the way to make it so people are _less_ confused.

We live in an era where you can boot Linux in JavaScript. If every time you make a statement about computing you have to list the exceptions, that's sinking in to the Turing tarpit for documentation.

<comment><USER9> Normally I'd agree with you, especially when concerned with languages like JavaScript. But C# is a different beast. It's being used quite frequently in large gaming projects and even operating systems where it is frequently less managed.You can even use it out of the box in a more, but obviously not entirely, unmanaged way to increase performance.

I don't consider this pedantic in this case. But the line isn't hard so we'll have some disagreement how to teach / not teach this.

<comment><USER10> Do you have any examples of projects where it's used in a "less managed" context? Are you just talking about avoiding GC, or something more advanced?

Even when you write in a low level style using the .Net/Mono VM, you're still fully protected by the guarantees of the language and runtime. You can't chase bad pointers around through memory or overflow the stack. It's impossible to access an array without a bounds check unless the JIT can prove it's not needed. The safety this provides is night and day to what it's like coding close to the metal (I develop games in C# and have written a fair amount of C/asm).

But as you say, we can agree to disagree about that...

<comment><USER11> > You can't chase bad pointers around through memory or overflow the stack. > It's impossible to access an array without a bounds check unless the JIT can > prove it's not needed.

Many native languages have these features without having a managed runtime.

</comment></comment></comment></comment></comment></comment><comment><USER12> Unity is also going to do some C++ -> C# conversions [https://blogs.unity3d.com/2019/02/26/on-dots- c-c/](https://blogs.unity3d.com/2019/02/26/on-dots-c-c/)

<comment><USER13> Unity has gone far beyond cross compilation of C# to C++ now. Their Burst compiler is capable of compiling C# straight to assembly with vectorization optimizations. They've even ported core C++ components of the engine into bursted C# because the resulting code is faster and a quarter of the size. It's impressive stuff.

<comment><USER14> I wonder why they choose c# over other language common for scripting / gaming engine, like lua c++ or even java. I think C# is good and designed well (over java), and I wonder if it's the same for them.

<comment><USER15> Unity features three scripting languages; JavaScript/UnityScript, C#, and Boo

<comment><USER16> This is technically true, but these days using anything other than C# is strongly discouraged.

</comment></comment></comment></comment></comment><comment><USER17> I remember back when they called C a high level language- because it wasn't assembler. Yes, I'm old. But, my point is that there probably isn't a definitive answer to that question that won't change with changing technology.

<comment><USER18> Speaking as another old person (50+) yes i too remember when C started becoming in-vogue for apps (shortly before VB4) and it was considered high- level by a lot of folks. Even in a COBOL enterprise system in which i worked at the time C was considered more high-level than low-level although we used it to build a runtime for COBOL apps. I have seen this type of discussion go on for decades, literally, but to my simply mind low-level means at the machine instruction set level. Everything above that is something else and i think the label of high or low level is frankly both arbitrary and meaningless. In recent years having spent time working with C on Arduino and Python for apps/hacks, and I also have dabbled with pascal(several variants of it), the only term i can think of to meaningfully describe any language is 'fit for purpose'. And if your purpose is to do ray-tracing from an environment that needs be supportive of programming noobs then maybe C# with tweaks is the best fit. If your environment requires burning programs directly into silicon then maybe verilog is best fit for purpose.

Its not about what you like, what you know, what is trendy, what is top of the pops this week - its about getting shit done and that happens when you use the right tools. The tech industry, like every other industry, ultimately involves people and people are as subject to fashion, peeves, and emotional attachment to their investments(i.e. the languages you know well) - a comment on C# vs C++ seems to start wars just as religious as vi vs emacs as we had back in the 80s with COBOL vs RPG3!

End of rant.

</comment></comment><comment><USER19> Some people say that C isn't low-level (though I disagree). I personally don't think of C# as even remotely low-level.

<comment><USER20> The author takes this into consideration:

      * yes, I know 'low-level' is a subjective term

I used to work in the embedded world, and there C has historically been considered a "high-level" language for many platforms. However, we have started to see languages like C# and Python make their way into the world of tiny micros thanks to more power coming to the platforms themselves and the clever work being done by MicroPython and Microsoft.

<comment><USER21> The problem is that most legacy code (especially firmwares) is C and will never have a chance to be rewritten in another language. If you get a chance into VLSI field you will be amazed that they are still relying on Tcl to do complicated stuffs. Only part of the world's software (most in IT companies) can afford rewriting in a new language regardless of costs/upstreams.

</comment></comment></comment><comment><USER22> This has a click-baity title. A mostly math/calculation heavy C++ program is translated into a mostly math/calculation heavy C# program. You could replace either side with any language and get the same outcome. At best, the end of the article lists some hacks you _could_ write in C# to get what you consider "low-level", but ultimately defeat the purpose of using a "high-level" language in the first place. If you're using unsafe calls and platform intrinsics, it's more than a one off situation, and the language doesn't encourage it, then maybe you're trying to hammer a nail with a shoe.

<comment><USER23> If they replaced C# with a language like ruby I suspect it would not get within the same order of magnitude of performance.

I agree that it may not be the best choice, but it is still interesting to see what is possible.

<comment><USER24> Sure, but I could write a computer for some new flavor of assembly tonight. The output would not by performant, but the language would certainly be low level.

</comment></comment></comment><comment><USER25> Slightly to the side of the topic, but this quote here:

>Yep, Bob uses i++ instead of ++i everywhere. Meh, what's the difference.

I know what the difference is, but if you're just using it on its own line or in a for loop, why would you use `++i` instead of `i++`?

<comment><USER26> Why didn't you ask the question the other way around? :-)

For some inexplicable reason the postfix operators are usually taught and learnt first, and thus considered more natural, even though there are more objective reasons for the opposite, at least in C++ world.

<comment><USER27> > For some inexplicable reason the postfix operators are usually taught and > learnt first, and thus considered more natural

The (unary) postfix operators might have _semantics_ that are more surprising than the prefix variants, but the postfix _syntax_ itself feels a bit more natural and fitting with other syntax of the Algol language family, IMHO, when compared to the prefix syntax. I think that's what leads people to introduce it first.

You can sort of read `i++` as an "abbreviation" of `i += 1`—in both cases, you've got an operator that follows an lvalue variable, and which both reads from and mutates the memory referred to by that variable. The only difference is that one has an additional "argument"—the amount to mutate the lvalue _by_ —while the other has a "default" argument of +1.

`++i`, on the other hand, is a _surprising_ bit of syntax, the first time you see it. It takes (and mutates) an lvalue... on its right! None of the (few) other unary prefix operators in Algol-like languages take lvalues, so it's kind of a shock.

(Also, for newcomers to programming, unary - [numeric negation] is commonly interpreted as part of the grammar of a number literal rather than being an expression; and unary ! is commonly seen as just "part of the language" (i.e. less like & and |; more like && and ||). Unary ~ is the only one I'd expect it would occur to any new programmer as even _being_ a "unary prefix operator" rather than just "the way the language is." And it's a pure-functional transformation of its input.)

</comment></comment></comment><comment><USER28> As soon as you default to a particular policy of how to allocate, and most importantly free, memory on the heap, you have committed yourself. Low level means: no commitment in that realm, aka, do what you please. The fact that you can possibly overrule that default, does not make much of a difference, because almost any language allows this.

C does not even have a standard (dynamically-sized) list concept built in, because that would amount to committing oneself to a default heap allocation/deallocation policy. All you can get is a contiguous range of bytes with some vague, default interpretation as to what it is supposed to be, through the use of malloc/free (possibly hacking it through realloc). That is why C is considered low level.

Still, in a true low-level solution, you would use the sbrk system call directly. So, in a sense, C may already "add too much value" to be considered truly low level.

<comment><USER29> You can easily can sbrk (or mmap) from C directly.

<comment><USER28> Yes, exactly. You can even do that from any arbitrary scripting engine that supports executing arbitrary C functions.

For example, here, complete access to the linux/bsd/osx system call interface, including sbrk, from lua: [https://github.com/justincormack/ljsyscall](https://github.com/justincormack/ljsyscall)

Just load libffi ([https://sourceware.org/libffi](https://sourceware.org/libffi)) or a similar module in any arbitrary language, and off you go!

</comment></comment></comment><comment><USER30> Why was the conditional expression in the C++ code converted to an if statement in the C# code? C# has conditional expressions.

<comment><USER31> It's been a while since I've used C#, but I'd guess it's because the C++ is doing a "+=" with ",", to cram two statements in there, while C# considers "+=" a toplevel statement only and doesn't allow it to be used with ",".

</comment></comment><comment><USER32> It's subjective but recent language and runtime updates have made massive updates in performance and flexibility. There are projects like Unity, RavenDB document store, FASTER KV store, Trill analytics, ML.NET and many more that show that C# is incredibly capable of competing at low-level/high-performance scenarios.

</comment><comment><USER33> I would say no, but its all about lingo, low level languages, or system languages, can be used to bootstrap a computer.

</comment><comment><USER34> Can't you just do pinvoke. It is easy enough to do. Just design a good interface in the c side to pass the data.

</comment><comment><USER35> Are trees tall?</comment>


Another take on the million dollar homepage : MillionDollarCu.be  - <AUTHOR> http://milliondollarcu.be/ <comment><USER2> While you're dropping by, be sure to try entering the Konami Code on the home page.</comment>


Assembly tutorial for linux - <AUTHOR> http://www.cin.ufpe.br/~if817/arquivos/asmtut/index.html#intro

<comment><USER3> When I learned assembly years ago, my favorite assignment was a binary bomb. The goal was to "defuse" the binary bomb, which you did by using gdb to disassemble and step through the code in order to figure out how to get to the next phase. There were 10-12 phases, IIRC. It was a great assignment - <USER2> helped you understand assembly better while learning how to use gdb - all in the form of a puzzle.

If anyone is interested, below is the first one I found via Google.

<http://stevebirstok.com/wp/?p=16>

<comment><USER4> Really interesting link. Thanks.

</comment></comment><comment><USER5> Note that this page is almost 10 years old, I wonder if the system call interface changed since then.

<comment><USER6> tomjen3 is literally correct that the system call interface used here (int $0x80) still works.

However the system call interface used by most Linux programs today is different in two important respects:

(1) Most(?) current Linux programs run on x86-64 and I'm not sure if int $0x80 is even implemented for this architecture. Whether or not it's implemented, it is not the one which is used normally. Programs use a special 'syscall' instruction:

[http://repo.or.cz/w/glibc.git/blob/HEAD:/sysdeps/unix/sysv/l...](http://repo.or.cz/w/glibc.git/blob/HEAD:/sysdeps/unix/sysv/linux/x86_64/syscall.S)

(2) Even on 32 bit i?86, int $0x80 has not been used by ordinary compiled programs for a long time. This is because software interrupts were discovered to be very slow, since all registers are saved whether you need to or not. There are faster methods to enter the kernel now. Originally the replacement was to use the Intel 'sysenter' instruction. This was slow too. It was replaced by a "call gate" via %gs, see ENTER_KERNEL here:

[http://repo.or.cz/w/glibc.git/blob/HEAD:/sysdeps/unix/sysv/l...](http://repo.or.cz/w/glibc.git/blob/HEAD:/sysdeps/unix/sysv/linux/i386/sysdep.h#l187)

I think modern code on 32 bit ix86 now uses 'syscall' where available. It's hard to keep up, and a detail that doesn't matter for anyone except a handful of kernel and glibc hackers.

</comment></comment><comment><USER7> Before checking the tutorial I disassembled it myself to see how it's working. Based on my interpretation I entered

       2 <enter> 1 <enter>

This diffused the bomb. Later I found out that was not suppose to be the code.</comment>


Why Ruby for startups? - <AUTHOR>

I see so many new startups being built on Ruby/Rails. Why so?
Why not Python?
PS: This is not a Python vs Ruby question. Just, why is Ruby preferred in the startup world? <comment><USER2> When Rails came up, it's "new way" of developing a webapp fast and without much hassle was exciting. In addition, Ruby is a really nice language, and switching to it may give you massive productivity boosts, depending on where you come from. Plus: the amount of high-quality libraries ("gems") is very high. But i forecast a massive decrease of Ruby usage in startups. I'll explain why in the following sentences:

Startups are not picking _Ruby_, they are picking _Rails_, which happens to be written in Ruby. Seriously, the language doesn't matter that much nowadays it's all about the ecosystem around it. You need one or more nice frameworks, as light or heavy as you want, and a bunch of libraries for common stuff you have to deal with (never invent the wheel again if not absolutely neccessary!).

But time goes on. I was a ruby zealot, but this changed over the last 2 years. Most of the webframeworks of other languages integrated the "rails way" in one way or another. To be clear: Rails hasn't special benefits or is "cool" any longer (i say this as an currently employed rails developer). In addition to this, Ruby itself is showing it's age:

\- excessive metaprogramming (like eg. in ActiveRecord) makes these things nearly unreadable/un-understandable today. \- parallel processing in MRI is not possible, Rubinius 2 didn't finish/change for the last 2 years (especially unicode support is the showstopper in non-english countries), JRuby brings the disadvantages of the JVM to the table (the startup times in short TDD-cycles are annoying). \- Ruby is still one of the slowest scripting languages in use. In addition, stuff like ActiveRecord kills performance even more, some expressions (no exact number) take hundred times longer than writing the raw sql statement in the rails app. The "convenience" of AR comes with price. (and as i mentioned, the "under the hood" isn't that easy to understand either).

To be fair: other languages have their problems, though.

\- python: the frameworks are similar to the language in their inception: quite good, but not mind-blowing, boundary-pushing or just "hip". I'd say most usage of stuff like Django results from "yeah, i know python, let's use a python web framework" if you know what i mean. Indeed, there's nothing wrong with that. Also: Python3-transition-hassle, GIL like Ruby prevents parallel processing, similar hassle like with the different ruby implementations.

\- PHP: cheap. hosting is cheap (most customers are happy with near-garbage hosting since they won't get _that_ much traffic). developers are cheap and everywhere available. developing is cheap because of the massive amount of high-quality "frameworks" (not only coding-frameworks, but also stuff like drupal, typo3, wordpress, wiki, ...). But: you get what you pay for. Innovations happens everywhere except in PHP, folks there are just playing catch-up. If you have to develop something new, where you don't have the skeleton in place, PHP isn't the best choice. Like Ruby, performance is not that good, especially when you target modern webapps with thousands of concurrent small requests. PHP isn't made for this.

\- Perl: slowly fading away. May become "cool" again, similar the way old clothes become "retro" and cool again. No pun intended, i personally like perl. And CPAN is just insane. Everything you'll ever need (and more) is available.

\- Scala: very interesting (but also complicated and not beginner-friendly) language. Biggest drawback last time I used scala: the "package manager", the single most important thing of every modern language, the thing that defines how the ecosystem will behave, was just garbage. There (as i know) is no place like "rubygems.org" and just "gem install myawesomelib". It _may_ be that SBT has involved into something great over the last year, i don't know. The whole "JVM Ecosystem" has quite a learning curve, too. Not startup-friendly and you'll need _great_ developers (my experience).

\- ASP.NET MVC/C#: This is my personal opinion: i would never use it again or recommend it to anyone. Not only C#, but the whole .NET stuff or other microsoft-centric technologies. It has fanboys for sure, but not only i hate to work with every single piece of the microsoft "stack", MS is fading away slowly. Even silverlight was abandoned, ehrm i mean, "open sourced". The only way to write C# code in a productive way is in Visual Studio. Oh, you'll need the features of the "ultimate edition"? Have fun shelling out thousands of $$ for your developers. Use MS-SQL Server? Look at the license costs. Whatever, i don't want to start flamewars here. Actually i (european) see C# stuff outsourced to indian offshore businesses more and more (no pun intended). C# Development is just "stuff that needs to be done" in some businesses, there is nothing really innovative or exciting going on and developers are cheap.

All this said and done, there is one outstanding "stack", and this is... javascript. We all know the language and the "fame" of javascript and how it evolved over the years. But today, things have changed.

\- JS is the only player in the browser. "unfair" advantage. Every softwarestack above have to deal with JS today. \- Node.js brings JS to the server. While not suited for anything, it is just _perfect_ for many apps today. \- NPM (the "rubygems" for JS/Node) is quite "better" than rubygems and seems way more active today. \- Kickstart from scratch with express/mongoDB is _really_ fast and perfectly suited for agile development. \- "Big Frameworks" are evolving rapidly the last months. \- Desktop- & Mobile-Apps tend to be written in HTML5/JS more and more. \- Databases like MongoDB use JS as their query language. \- if you don't like JS, there are preprocessing-languages like coffeescript which compile to JS. Write in the style you want, that's it. \- The raw Speed of the V8 VM is amazing.

=> if you want, you can have a Stack with JS-pieces only today. From database to the UI, everything can be javascript, which makes development of modern client-heavy apps a breeze.

So, to conclude: The future question will not be "why ruby?", but "why not javascript?".

<comment><USER3> !!! warning - an extremly biased person above !!!

"\- ASP.NET MVC/C#: ..."

1) Microsoft came up with TypeScript recently which is truly open-source and will dominate Dart/CoffeeScript etc. over the time. 2) Microsoft is supporting SignalR which is truly open-source Pub-Sub and is a replacement for WCF. 3) Microsoft is supporting KnockOut.js which is truly open-source and one of the best MV(C/VM) frameworks today. 4) Microsoft invented _modern_ flat GUI style. 5) Visual Studio + ReSharper makes the most feature-rich IDE on the market. You don't have to buy Ultimate or even Premium - Express/Professional is good enough for most people. 6) If you mentioned Scala then mention F# as well. 7) Windows and Visual Studio will now be on much shorter release cycles.

Old Microsoft != New Microsoft.

<comment><USER2> yes, i _am_ biased.

1) i'd say typescript will have its place, like coffeescript. usual MS behaviour: "oh there is something cool going on! We'll rewrite this stuff again in our ecosystem, instead of helping the original thing. Then we announce it as 'awesome new thing' with a cool buzzword!"

2) i ignore windows development currently (just as much as crossplatform toolkits need). i know there are many C# people out there, but i am just facing unix-ish based developers around me. so, i can't say something about this.

3) "is supporting". oh, great. And google supports angular. and facebook supports ... . not really an argument. Oh, and i know that microsofts actually pays some linux developers. many firms do. most of them with much less money than microsoft. (oh, when the current stock course ddrops further, this won't be true for future readers ^^)

4) As far as i know they hired a lead designer from apple to actually "invent" the design. Personally i like the tiles of windows 8, at least the spirit. What they made out of this ideas, well, not so much.

5\. Who _really needs_ IDEs? C# folks (and java'ish of course). It doesn't matter how good Visual Studio actually is (i know it is good or even the best, i have the ultimate's here), but efficient developing C# _requires_ VS, and that is, in my opinion, a central design flaw of the language itself.

6\. i didn't mentioned F# because i have no experience with it.

7\. not an argument for a startup for developing their stuff in C# right away, seriously.

Old microsoft: massive marketshares and influence. new microsoft: too little too late, fading away (PC drops, public windows 8 perception (!) is a desaster, Tablets and RT's don't sell, Phone marketshare is not enough, XBox one presentation desaster, stock price drops and drops, ...).

 _i love discussions with other biased people_ :)

</comment></comment></comment><comment> workhere-io _why is Ruby preferred in the startup world?_

I'm not sure it is. If you look at the polls there have been here on HN, Python often places better than Ruby (one example is [https://news.ycombinator.com/item?id=3745084](https://news.ycombinator.com/item?id=3745084), but there are other polls as well).

<comment> workhere-io Here's another poll that shows Django being way ahead of Rails among the YC startups: [https://news.ycombinator.com/item?id=750142](https://news.ycombinator.com/item?id=750142)

<comment><USER4> Note that this poll is 4 years old. You should add the year when you link to such content.

</comment></comment></comment><comment><USER5> I can't speak for others but I chose Ruby/ Rails over Python/ Django, because the Rails community seemed bigger and much more active. This may not be necessarily true of course, but I took a look at Ruby and liked what I saw, so much that I never looked back :)

</comment><comment><USER3> Because it is fashionable (in a bit hype-y way) and happens to be not bad :).

</comment><comment><USER6> cause with Rails, a web application is developed fast and very easy and the cost is very low. You know start ups need time and money.

<comment> workhere-io _cause with Rails, a web application is developed fast and very easy and the cost is very low._

How is that different from e.g. Django?

<comment><USER2> I think that it's a save bet to say: rails has no advantages any longer. You'll find similar features in nearly every common "web-language" and their range of frameworks today. The only difference is the language itself, and you all know the holy wars fought about which is better, right?</comment></comment></comment>


Regenerative stem cell identified and isolated in planaria flatworms - <AUTHOR> https://www.hhmi.org/news/searching-source-planarians-regenerative-powers <comment><USER2> the deadpools of the animal kingdom. I want to be able to chop off a tiny piece of skin, then make a clone to do my bidding.

</comment><comment><AUTHOR> Tldr: planarians, which are flatworms that can regenerate an entire organism, have a specific stem cell that a single cell can regenerate an entire organism. This specific cell has finally been found.

This can allow, hopefully, the study of human regeneration and perhaps drugs/cellular techniques that can restart human regeneration after previously impossible to fix injuries.</comment>


Give your cat a digital web presense - <AUTHOR> http://www.catresume.com <comment><USER2> I'm pretty sure that my cat has absolutely no need (nor even desire) for a digital web presence. The only use it has for a computer is as an object that is warmer than the floor.</comment>


This is just the beginning (A Facebook employee who worked on Google+ speaks) - <AUTHOR> http://www.thinkoutsidein.com/blog/2011/07/just-the-beginning/

<comment><USER2> You mean "who worked on Google+," not "who works on Google+." I was all excited to read a story about double agents!

<comment><AUTHOR> Sorry, mistype. And now I can't edit the title, so far as I can tell.

</comment></comment><comment><USER3> Given the title, not at all what I expected. He keeps hitting home on 'this is just the beginning' and I can't think of a phrase that is more correct for our time. I likewise agree very strongly with prediction as a fools game. Sir Clarke said it long ago and if he couldn't, does anyone really think the folks who have followed could or can? I quote the great Wiki quoting Sir Arthur:

1\. When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.

2\. The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

3\. Any sufficiently advanced technology is indistinguishable from magic.

<comment><USER4> Sir Clarke is technically incorrect. It's either Sir Arthur Clarke or Sir Arthur.

</comment></comment><comment><USER5> Almost no substance to the article.

</comment><comment><USER6> Not only is the title inaccurate (It's a Facebook employee that previously worked on Google+), but it implies some inside knowledge of Google+ and that more features or something are coming. Not really impressed and the content was rather lacking too.

</comment><comment><USER7> No need to be overdramatic about this... I doubt the average mom is worried in the middle of the night about what circle a friend belongs to. .

</comment><comment><USER8> Title says it ALL</comment>


Ask HN: Help with 401k & Savings - <AUTHOR> My girlfriend is asking me some questions about setting up her 401k and saving money for retirement... Unfortunately, my last job didn't offer it and my new one doesn't qualify until Oct, so I'm an amateur when it comes to retirement saving.
She's an RN and makes around $50k/yr right now at 26y/o.  Her work matches up to 6% of what she makes and she currently puts away 6% of each paycheck, but is considering changing it because she's not sure if she's saving too little or too much.  She's considering an IRA or something else as well.
She pays around $500/mo for student loans and doesn't have too many expenses outside of that (just phone, rent, etc).
My life is actually very similar and I'll soon have the ability to start investing in a 401k, so I figured I might as well learn about it now.  What would your advice be on how much to put away (and where) for someone at this stage of their life? <comment><USER2> Contribute the max that work will match, and put it in the safest vehicle that you are given an option to invest in, preferable T-Bills.

The money will add up over time, and it is like getting a 6% raise!

<comment><USER3> If you're 26 years old, investing in t-bills is a horrible idea. Show me a 40 year period where t-bills have outperformed the stock market.

OP, she definitely put in as much as money as her employer will match. If there's more leftover, put in another 5k into an IRA (at her salary and considering she's already investing in a 401k, probably a roth ira is a better idea).

Put it almost all in a low cost index fund (either one that tracks the S&p 500 or something like vanguard's total stock market fund). If you want you can stick a little in bonds or international stocks although neither are necessary.

</comment></comment><comment><USER4> Employer contributions should be discounted based on the vesting schedule. Because many employer matches vest over five to seven years, your access to that money is questionable, particularly in a high turnover industry. Only if the contributions vest when they are made is employer matching a straight up winning proposition - otherwise your investment return is more closely tied to the market.

I believe this article gives a good picture of long term investing [previously posted on HN] [http://www.nytimes.com/interactive/2011/01/02/business/20110...](http://www.nytimes.com/interactive/2011/01/02/business/20110102-metrics- graphic.html?ref=business)

</comment><comment><USER5> I agree, contribute to the max that the work will match, but I would put it into an age-adjusted fund that is aggressive while you're young but gets more conservative as you get older. No sense in losing 10-20 years of aggressive growth return rates...

Also, don't forget to have a liquid cash cushion on hand for unexpected expenses or things like job loss. Personally I put 10% of each pay check into savings (until I build up at least 6 months worth of expenses- after that I'll probably just use it for vacations and the like) and 5% into a retirement fund (I use a Roth IRA for now).

</comment><comment><USER6> Contribute to your 401k through your employer up to the match level, and open a Roth 401k to contribute an additional $5k/year there. Build up 6-12 months of emergency fund savings. Max your traditional 401k to $16,500 per year. Invest in "target year" low cost/fee mutual funds to get started.

</comment><comment><USER7> Here's 3 simple goals:

401k @ 6%

Max Roth IRA until $5k

Max 401k until $16500. (Employee contributions don't count against the max)</comment>


Seattle once again nation's fastest-growing big city; population exceeds 700,000 - <AUTHOR> https://www.seattletimes.com/seattle-news/data/seattle-once-again-nations-fastest-growing-big-city-population-exceeds-700000/ <comment><AUTHOR> In good news, Seattle is building mass transit ([http://soundtransit3.org/](http://soundtransit3.org/)) and building housing much faster than California.

In bad news, much of the city is still zoned for single-family housing and it ought to be doing much more to increase the supply of housing ([https://jakeseliger.com/2015/09/24/do-millennials-have-a- fut...](https://jakeseliger.com/2015/09/24/do-millennials-have-a-future-in- seattle-do-millennials-have-a-future-in-any-superstar-cities/)). And while Seattle _is_ building mass transit, it's doing so at a glacial pace. "Later" is better than "never," but the slowness and expense of construction is striking ([https://www.vox.com/policy-and- politics/2017/5/24/15681560/g...](https://www.vox.com/policy-and- politics/2017/5/24/15681560/gao-report-transit-construction-costs)).

<comment><USER2> _In good news, Seattle is building mass transit ([http://soundtransit3.org/](http://soundtransit3.org/)) _

Yes! I'm really excited for having light rail 10 minutes from where I live! And, as long as there's no delay, it's coming as soon as year 2035! Just in time when Year 2038 Problem will create huge employment opportunities for us old farts!

<comment><USER3> If the political willpower existed for building metros at Chinese speeds in North America then I would volunteer first to be the person swapping out the drill heads.

Unfortunately infrastructure is a slow moving game and we have to settle for less on this continent.

<comment><USER4> I'm gonna enjoy chilling in a self-driving car while other people stand in a crowded train in 20 years. ;)

<comment><USER2> You mean, enjoy sitting in never-ending traffic jam while people in a crowded train pass you by?

<comment><USER5> no, he should continue to work in self-driving car, otherwise, what's the point of self-driving :)

<comment><USER6> Ideally, if OP doesn't spend a load of $$$ on a self-driving car, OP wouldn't have to work more (to pay it off) and could retire sooner. But this world seems to be rather spendthrifty than thrifty.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I've lived in Seattle for 30 years and have founded three companies here. Due to the expense of labor and housing, politics, bad traffic and the loss of the city's sense of community I will be moving my business to Bellingham in the next year.

The bad parts of Amazon work culture have permeated almost every company here. It used to be very common in tech companies for people to leave the office at 3:00pm to go hiking after work in the summer or come in late after skiing powder in the morning. Now so many are working 60 hour weeks they don't have the time to really enjoy the outside or engaging in making our city better. In short, Seattle residents are in general much less friendly and more stressed than ten years ago.

Since my company builds outdoor products, our employees are happy to move to a new town with access to fanastic mountain biking, skiing and hiking with little traffic and somewhat more affordable home prices. It's too bad Seattle grew without plans in place to help preserve its livability and attractiveness to small businesses.

<comment><USER8> Bellingham? Take me with you. :-) Yeah, I don't know why everyone tries to cram into this one small geographical area. I always figured back in the day that new startups would center around the Eastside, what with a boatload of ex- Microsofties to hire. Nope, drive across the lake to Pioneer Square or SLU, bitches. It's even worse now that Amazon showed up. Instead of someplace like Bellingham, let's see if we can cram _one_ more startup into Pioneer Square.

 _It's too bad Seattle grew without plans in place to help preserve its livability and attractiveness to small businesses._

From transit to housing, I don't think I've lived in a place so much in denial about future growth. The fact that light rail is just now getting built is a prime example of this.

</comment></comment><comment> aaron-lebo Because of the way some cities annex everything around them and others don't, it makes for arbitrary numbers.

[https://en.wikipedia.org/wiki/List_of_Metropolitan_Statistic...](https://en.wikipedia.org/wiki/List_of_Metropolitan_Statistical_Areas)

This is a better/different metric. It places Seattle's metropolitan area much lower in growth from 2010 to 2016.

<comment><USER9> The Seattle metro area is 15th in _size_ on that chart; it's much lower than (44th) that if you sort by growth rate.

By absolute growth (which isn't in the chart, so I had to copy the data into a spreadsheet) it is 9th:

           METRO                     POP. GROWTH 2010–16
           -----                                  </comment></comment><comment>
         1 Houston-The Woodlands-Sugar Land       852054
         2 Dallas-Fort Worth-Arlington            807109
         3 New York-Newark-Jersey City            586224
         4 Atlanta-Sandy Springs-Roswell          502972
         5 Miami-Fort Lauderdale-West Palm Beach  501752
         6 Washington-Arlington-Alexandria        495745
         7 Los Angeles-Long Beach-Anaheim         481610
         8 Phoenix-Mesa-Scottsdale                468650
         9 Seattle-Tacoma-Bellevue                359093
        10 San Francisco-Oakland-Hayward          343775

</comment><comment><USER10> You know, it's nice to be someone benefiting from all the growth and stuff in that I guess I can complain in comfort, but...

I fucking hate it here. The wealth disparity is palpable, and people understandably resent it. Nobody treats you like a human being if you're in tech. They treat you like a wallet; how do you think it feels to never be smiled at or even acknowledged unless you're about to pay for something? Ever been a pariah? It's awful, and I wouldn't wish it on anyone.

At least you'll make enough money in a few years - not having any people-y things to spend it on - to move somewhere else and really try to contribute to something. Seattle _resents_ contribution.

If you're reading this and considering a move out here, I swear I'm not doing some kind of NIMBY thing, this is straight from the slowly-but-surely-broken heart - please, spend a week or two here first and think very hard before making the decision.

<comment><USER11> _Nobody treats you like a human being if you 're in tech. They treat you like a wallet_

Weird, I never have this experience. Where do you live? Where do you hang out?

Also, I can tell you from personal experience that people will treat you like a hero[1] if you tell them that you work on OneBusAway, so please help out on one of these all-volunteer projects:

iOS: [https://github.com/OneBusAway/onebusaway- iphone](https://github.com/OneBusAway/onebusaway-iphone)

Android: [https://github.com/OneBusAway/onebusaway- android](https://github.com/OneBusAway/onebusaway-android)

[1] Unless they're Route 8 commuters.

<comment><USER12> Another big thanks for OneBusAway! I'm in tech though, so that may not count.

</comment></comment></comment><comment><USER13> Seattle needs to aggressively address the ridiculous single-family zoning issues before we end up like the Bay Area. The city's only real advantage over San Fran/Palo Alto is it's relative affordability for tech workers and the talent pool that AMZN pulls. Beyond that, Seattle has neither the VC money or the number of start-ups and aggressively growing companies to compete with the Bay Area. If we lose that comparative affordability then the talent and businesses will start moving to lower-cost of living cities like Denver/Boulder, Salt Lake City, and Atlanta. It's going to very interesting to see what happens when AMZN selects it's second HQ. Word is it's now between Atlanta and Denver.

</comment><comment><USER14> That's less than the annual growth of Houston or the Dallas megaplex. (>800.000) They are a couple of times bigger and also grow much faster.</comment>


Ask HN: Why'd a post about my personal OSS project trending #1 on GH get flagged - <AUTHOR> I hate to be a nuisance but I was really excited for the community response when I made a post linking to Github Trending telling people that it was my open source project that was #1, but it was flagged and removed. This is a lifetime achievement for me and I'm pretty bumbed out about that, any explanation why it happened? Thanks <comment><USER2> Maybe because you've posted this project on HN 6 times in 4 days?

<comment><USER3> He's talking about it being flagged on Github, not HN.

<comment><AUTHOR> No I'm talking about being flagged here on HN, sorry if that wasn't clear.

And I apologize but the first few times the post didn't get any traction (really due to the Readme being very sparse). But last time I posted with a nice Readme and it went pretty viral and now I can't post about my lifetime historic moment of reaching #1 on GH trending? I've been working my butt off on this I'm just trying to hustle and show some people (and people are very appreciative so where's the harm?)

<comment><USER4> There are only 30 slots on the front page and they are highly prized.

The fact that an earlier submission of your project spent several hours on the front page is a great win. Congrats for that!

But the guidelines [1] and long-established norms [2] of HN are that the same story/project/topic isn't entitled to take up a front page spot a second time so soon after its initial appearance, unless it clearly "gratifies intellectual curiosity" [3] and contains "significant new information" [4].

So it's nothing personal; it's just how HN has to work to stay interesting and allow exposure for as much different content as possible.

You can submit your project again as soon as you've added any interesting new features.

[1] [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

[2] [https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20dupe&sort=byPopularity&type=comment)

[3] [https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=gratifies%20intellectual%20curiosity&sort=byPopularity&type=comment)

[4] [https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20significant%20new%20information&sort=byPopularity&type=comment)

<comment><USER5> Also, a submission on the project submitted 3 days ago did get significant traction:

[https://news.ycombinator.com/item?id=21926666](https://news.ycombinator.com/item?id=21926666)

141 points, 75 comments</comment></comment></comment></comment></comment>


Container Selection Flow Chart - <AUTHOR> http://i.stack.imgur.com/d5CDK.png

<comment><AUTHOR> and the corresponding C++11 discussion on SO: [http://stackoverflow.com/questions/10699265/how-can-i- effici...](http://stackoverflow.com/questions/10699265/how-can-i-efficiently- select-a-standard-library-container-in-c11)</comment>


Tech IPOs Return With Rackspace - <AUTHOR> http://gigaom.com/2008/08/08/tech-ipos-return-with-rackspace/ <comment> patrickg-zill Good luck to them, I feel that they do not have any special advantages to offer vs. other colocation/hosting companies.

<comment><USER2> Not even more pervasive advertising? Perhaps they could use the cash influx from an IPO to do more ads?</comment></comment>


HTTP 103 – An HTTP Status Code for Indicating Hints - <AUTHOR> https://datatracker.ietf.org/doc/draft-ietf-httpbis-early-hints/ <comment><USER2> Summary: a new status code that lets the server send headers early, before the main headers. This helps with optimisations like preloading. Example from the document:

         HTTP/1.1 103 Early Hints
         Link: </main.css>; rel=preload; as=style

         HTTP/1.1 103 Early Hints
         Link: </style.css>; rel=preload; as=style
         Link: </script.js>; rel=preload; as=script

         HTTP/1.1 200 OK
         Date: Fri, 26 May 2017 10:02:11 GMT
         Content-Length: 1234
         Content-Type: text/html; charset=utf-8
         Link: </main.css>; rel=preload; as=style
         Link: </newstyle.css>; rel=preload; as=style
         Link: </script.js>; rel=preload; as=script

The client can start preloading the CSS and JavaScript before the main headers arrive. This is a nice optimisation.

There are various security risks with sending multiple headers to non- conforming clients hence: "Therefore, a server might refrain from sending Early Hints over HTTP/1.1 unless the client is known to handle informational responses correctly."

<comment><USER3> Sounds a lot like HTTP/2 push.

<comment><USER4> From the RFC intro:

> HTTP/2 ([RFC7540]) server push can accelerate the delivery of resources, but > only resources for which the server is authoritative. The other limitation > of server push is that the response will be transmitted regardless of > whether the client has the response cached. At the cost of spending one > extra round-trip compared to server push in the worst case, delivering Link > header fields in a timely fashion is more flexible and might consume less > bandwidth.

<comment><USER5> There are cache-aware HTTP2 server push technologies that can be used to cut that down wasted bandwidth.

See: [https://h2o.examp1e.net/configure/http2_directives.html#http...](https://h2o.examp1e.net/configure/http2_directives.html#http2-casper)

</comment></comment></comment></comment><comment><USER6> To explain the use case for this (as I understand it):

http/2 push sounds great at first glance for doing things like sending your CSS/JS bundles downstream with the HTML. The problem with this is that only the system that builds the HTML knows what needs to be pushed and only the system terminating the http/2 connection can send the assets. That means your app servers would need to terminate the http/2 connection and would be serving static assets. Serving static assets from your app server sucks for a lot of reasons. Instead what you want to do is tell some upstream proxy that is good at serving static assets what it should push. This is done by having the upstream proxy parse the Link HTTP headers in the response, which many services already do. But, today they can't start pushing assets until the main response is being sent since they need the headers from it to instruct them. Ideally you'd start sending assets ASAP, while the app server is building the page. This is exactly what the 103 response is most useful for.

e.g. You have a CDN front for your app servers, the app server sends an early 103 as soon as it knows what assets the page needs, the CDN intercepts this response and uses it to start pushing the assets to the client from the local edge node using http/2 push. This lets you benefit from http/2 push of your assets while processing the main response without your app server needing to serve static assets or even know about http/2 itself.

<comment><USER7> Does HTTP2 support multiple concurrent streams over a single client connection? If not, presumably your use case would require that the client has a separate HTTP2 connection opened up to the CDN already, right? Or am I missing something?

<comment><USER8> While I disagree with mbell's interpretation of the value of this header or how it could be used, to answer you're question pcl, yes HTTP 2 does support multiple streams over a single transport connection.

To me, I would say increasing efficiency (or decreasing latency) was a central design goal of HTTP2. So HTTP2 includes it's own framing, which allows multiplexing across the connection. This helps avoid the overhead of establishing multiple parallel connections to speed up page load, head of line blocking, running slow start on each connection, etc.

<comment><USER6> > While I disagree with mbell's interpretation of the value of this header or > how it could be used

FWIW the use case I'm describing has already been added to Rails / Puma:

[http://eileencodes.com/posts/http2-early- hints/](http://eileencodes.com/posts/http2-early-hints/)

[https://github.com/rails/rails/pull/30744](https://github.com/rails/rails/pull/30744)

[https://github.com/puma/puma/pull/1403](https://github.com/puma/puma/pull/1403)

<comment><USER8> Sorry, I apologize for being unclear, I don't agree with you're interpretation of the use case that adds the most value.

While the RFC does state that what you described can happen at a caching intermediary, I don't believe that's where the value lies or the primary use case. To me, much of the value added is to get the 103 to the client early, and allow it to begin making decisions on whether the content is in it's local cache, or to begin making requests to third party servers.

This helps eliminate some of the weaknesses with HTTP push, mainly being that only content the server is authoritative for can be pushed, and that the server doesn't know whether the resource to be pushed already exists in a client cache.

It's a balancing act of course, but if the resource being pushed is above a certain size, pushing the resource on each request could add overhead, not reduce it.

<comment><USER6> The problem is that clients won't be supporting 103 for a long time, I would guess it'll be 3-5 years before you can realistically push the 103 to a browser and I don't thank any currently support it. It's also not a particularly safe thing to turn on. e.g. Chrome prior to 57 bombed on http/2 connections that sent a 103 which is in contrast to the RFP's theory that http/2 clients should be 'safer' in handling it than http/1 clients. We really don't know how many clients and proxies will have trouble with 103 and have to wait for the vast majority to at least ignore it / pass it along before it could be turned on externally.

> This helps eliminate some of the weaknesses with HTTP push, mainly being > that only content the server is authoritative for can be pushed, and that > the server doesn't know whether the resource to be pushed already exists in > a client cache.

When a server sends a push to the client it first sends `PUSH_PROMISE` command to the client and the client may cancel the push, e.g. if it already has the asset in cache based on url. Assuming things move forward the server sends a HEADERS frame which can also trigger to the client to cancel the push, e.g. in response to an etag, though at this point some DATA frames may be in flight.

You are correct that you can't push assets for another domain, but I don't see this as much of a problem as there are many other benefits to having all requests go a CDN/reverse proxy that can handle the static asset serving, like regional SSL termination. There are of course third party scripts that may be needed, but it's good practice make these non-blocking for page rendering anyway so if they are a bit behind that is probably ok, if not preferable.

</comment></comment></comment></comment></comment></comment><comment><USER9> The author of this draft is also the author of H2O (an HTTP/2 webserver). IMO the cool thing about this RFC is that you can put an HTTP/2 proxy that understands Early Hints in front of an HTTP/1 application server, and give the application server HTTP/2 push without needing to "HTTP/2 enable" the application server.

We added early hints support to Puma:

[https://github.com/puma/puma/pull/1403](https://github.com/puma/puma/pull/1403)

Then added early hints to Rails:

[https://github.com/rails/rails/pull/30744](https://github.com/rails/rails/pull/30744)

Such that if you run H2O (or any webserver that supports early hints) in front of Rails, you can get asset push support for free. eileencodes wrote a great blog post about her work on this:

[http://eileencodes.com/posts/http2-early- hints/](http://eileencodes.com/posts/http2-early-hints/)

</comment><comment><USER10> Waiting for [https://http.cat/103](https://http.cat/103) to be updated

</comment><comment><USER11> This is one of those optimizations where I'm ambivalent about it's usefulness.

Sure, Google might get a millisecond or two less in their apps, but who in their right mind has the engineering time to implement this very, very small optimization when there's many other things to be done that probably have a higher priority?

<comment><USER12> You are right, most people don't have the engineering time to implement this. Though there is definitely a market for this kind of optimizations in a SaaS solution (I know that because it has something to do with my job)...

Now, implementation of this by browsers is going to take a long time, and then we will see incompatibilities trickle down all the way, with Safari taking a few years after everybody else has it and IE/Edge also taking forever.... I should rather work in a farm and harvest tomatoes...

<comment><USER13> I feel like frameworks will implement it and most devs will get it that way.

<comment><USER12> Yes, most frameworks will implement it. I'm quite sure.

</comment></comment></comment></comment><comment><USER14> What happens to a Set-Cookie on a 103?

What happens to hints in a redirect chain?, i.e. 301 103 301 103 200

What headers are applicable to the 103 beyond Link? If a 103 included Refresh, could this be used like a timeout (redirect after Refresh time if actual request did not respond?)

This...

> A server MAY use a 103 (Early Hints) response to indicate only some of the > header fields that are expected to be found in the final response.

... implies that all possible HTTP headers from the final response may be in the 103.

RFCs need less ambiguity, lest clients and servers start to fill in the gaps and have divergent behaviour.

<comment><USER15> If the implementation decided to honor Set-Cookie in a 301, it should use the same security boundaries that it would use anywhere else. For a redirect chain and the rest, again it's up to the implementation. Since this is just an optional optimization, does it matter if there are divergent clients and servers?

</comment></comment><comment><USER16> It isn't yet _approved_. It is still a draft, not an RFC. Even if it does become an RFC, it is intended for the Experimental track, not the Standards track.

<comment><USER17> The HN post title really should be changed. Folks skimming headlines will see what is, in effect, fake news.

</comment></comment><comment><USER18> Am I wrong in thinking that these hints should include subresource integrity hashes?

Given hints with SRI hashes, the client can fetch/verify them and be ready when the HTML arrives, or even better, consult the cache and verify to avoid fetching and save bandwidth.

<comment><USER8> So I think there are a couple aspects to consider on this.

This RFC very strongly points to hints as the purpose, but to me appears to be generically implemented. So HTTP 103 can send any header, but only the final headers are authoritative. So it's really up to wherever those headers are defined to indicate what can/cannot be indicated by the headers. In other words, what a header can represent is likely a different discussion.

Subresource integrity is actually a w3c recommendation and not an IETF recommendation, so the checksum doesn't appear to be conveyed through headers. But trying to think about it logically, I don't think it's necessary to have the hashes at this stage. The web browser get's a HTTP 103, and see's the link rel and begins requesting and caching the resource. The web browser then loads the HTML, which includes the subresource integrity, that it then uses to check the result it already downloaded and cached. To validate that resource, it would need to download it anyway, the only thing HTTP 103 did was allow the the content to start downloading sooner in the process.

<comment><USER19> You don't need to download the file to verify the contents. The purpose of having a hash in the link is to allow you to cache jQuery previously downloaded from one CDN even though the link points to another.

</comment></comment></comment><comment><USER20> At some point we're just going to go with a full-on bidirectional stateful protocol, right? ;-)

<comment><USER21> And we could call it HTTCP

<comment><USER22> Or for branding, Websockets

</comment></comment></comment><comment><USER23> Are there any prior examples of sending multiple status codes in one response? I didn't think you could, but there's not much discussion of it in the draft (a little in section 3 only) which makes me think it's not seen as controversial. Seems like it'd be a heap of work to update all the servers and clients out there if it's not supported already?

<comment><USER24> Yes. "100 Continue". [1]

If client intends to send a POST request with request body large enough to try to avoid wasting bandwidth (in case server might reply with 3xx,4xx or 5xx), the client will send _only_ _headers_ including "Expect: 100-continue" header, then server indenting to reply with "200 OK", will instead first reply with "100 Continue" than client will send POST body, and finally server sends "200 OK".

[1] [https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8....](https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3)

</comment></comment><comment><USER25> This look nice to prefetch some stuff, although i have a feeling it'll break some not-so-nicely coded HTTP 1.1 clients that expect everything after the first CR/LF to be the content or -more likely- if the response isn't 200 for the request to fail :-P.

</comment><comment><USER26> Can this be abused by middleboxes to stick in an interstitial ad before and during page load?

<comment><USER27> No, its pretty much only useful for hinting css and js files that will be loaded in the <head>.

<comment><USER28> so...JS _injection_ then?

<comment><USER29> No. The JS would still be need to referenced by the page, this just affects preloading of assets.

<comment><USER28> So a far-side check, but does it not execute it until everything checks out? Y'know, now that I think about it more.

<comment> vertex-four It literally just says "please download this into the browser cache". Nothing happens to things in the browser cache - they certainly don't get executed. Later, if a page tries to load resources, it might come from the browser cache.

<comment><USER30> > Nothing happens to things in the browser cache

Really? Let's see, at least one extra DNS lookup can happen, a URL fetch can happen, this is totally enough for advertising tracking.

<comment><USER31> If you are in a position to inject a 103 response into a stream, you are in a position to inject JavaScript directly into the HTML body.

<comment><USER30> I didn't say it's an inject, it will be abused and purposely setup as a tracking tool by the webpage providers.

It's a sneaky unwanted network request un-controllable by end users. And it happens even before you load the page.

All ad-blocking tools/addons today works by parsing the webpage content, the 103 header extended the game from the body to the header.

Advertising tracking at its best.

<comment><USER31> Your issue is not with 103 but with _Link: rel=preload_ [1], which has been supported in Chrome for over a year [2].

[1] [https://w3c.github.io/preload/](https://w3c.github.io/preload/)

[2] [https://bugs.chromium.org/p/chromium/issues/detail?id=471199](https://bugs.chromium.org/p/chromium/issues/detail?id=471199)

<comment><USER30> Thanks for the link.

I think this is the case where X is innocent and Y is innocent, but combined X and Y leaves a huge exploitable surface.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> This seems like it's only of interest if you need to do time consuming processing before deciding what http status code to send, because once you pick the status code, you can send it and start sending the rest of the headers.

Is it common to serve something other than http 200 and to take a long time to do it -- but also be able to send something early sooner? Most of the the slow pages I've worked on were either slow to load all the details, but I knew it was 200 near instantly, and could get all the headers and the HTML head out pretty quickly, or had some structural problems that made them terribly slow, but we couldn't get anything out quickly anyway.

<comment><USER33> The vast majority of the cases the status would be planned as 200... unless for whatever reason a timeout/error occurs during process. Then it may end up with error status and or redirect to an error handling page.

Still very dubious proposal with minimal benefit(s).

</comment></comment><comment><USER34> Shouldn't it have a complimentary "denied" code? Or is 403 "Forbidden" the complement? Or maybe 401 "Unauthorized"?

I guess it is related to preloading? Not quite getting the purpose.

Edit: ahh, the complete story is here: [https://tools.ietf.org/html/draft- ietf-httpbis-early-hints-0...](https://tools.ietf.org/html/draft-ietf-httpbis- early-hints-05) (fixed). Note that someone fixed the capitalized "A" in "approved" in the title. It confused my initial reading of the article.

<comment><USER35> Someone only read the headline.

<comment><USER34> I read the headline and it colored my reading of the linked article. Bad headlines set up bad context. Someone also lowercased the "a" in approved in the headline since I saw it.

Someone else suggested [https://tools.ietf.org/html/draft-ietf-httpbis-early- hints-0...](https://tools.ietf.org/html/draft-ietf-httpbis-early-hints-05), which has more context without a need for a second click.

</comment></comment></comment><comment><USER36> Browsers can learn this on their own and start prefetching likely resources before the server responds. Like a cpu's branch prediction. I wouldn't be surprised if chrome already did this.

</comment><comment><USER37> This is actually great. I ran into this problem recently. I wanted to push out some CSS while waiting for some external response. Unfortunately, it was very important to be able to send a 404 in case it turned out the external response. This means we had to live with a higher TFFB.

Let's hope this becomes widely adopted soon. Does anyone know how long it took till other HTTP features that were added later (not HTTP2) were widely supported?

</comment><comment><USER38> Has anyone looked into implementing this with Varnish? It seems like a great way to handle non-streaming backend servers.

</comment><comment><USER39> Neat. Now how is this going to get abused?

<comment><USER39> For instance, you could add this to a popular site to create a really easy DDOS attack on the target of your choice.

<comment><USER40> You could also add <link rel="stylesheet"> tags to achieve a similar effect, so it doesn't really introduce anything new

<comment><USER39> It would be far more hidden in the headers.

</comment></comment></comment></comment><comment><USER41> Nice, not sure how trivial this will be to add to frameworks and still make it not as slow as two requests. I think maybe this could be a macro in Elixir's Phoenix framework that's done at compilation time; would mean it isn't changeable at runtime but would make it very fast.

</comment><comment><USER42> why not just add a "preload" flag to the style or link tag, this looks like a lot of extra work.

</comment><comment><USER43> Title should probably be changed to have a lowercase "approved". It's a little misleading as-is.

<comment><USER4> Agreed! I was confused when it was

      103 Early Hints

Not

      103 Approved

</comment></comment><comment><USER44> This seems to be meant as an AMP killer.

</comment><comment><USER45> Isn't this way too complicated to define and implement considering that HTTP/2 is already out there?

<comment><USER46> As someone who thinks HTTP2 is garbage and refuses to support it in my enterprise, this is a good step towards a MUCH better solution.

<comment><USER47> I don't know much about HTTP2; why do you dislike it?

<comment><USER48> one reason to dislike it, is because it is way too stateful. and a lot of things depends on timings. /and the spec misses some stuff, like if all my streams are done (except one long running stream, SSE, etc) and I get a new request what do do now? (there are multiple ways of doing that, one would be to just cancel the long running stream and hope that the client reconnects to the new connection).

Personally I think it is more complex than it was needed to be. stream priority can also be a PITA.

Ah and I basically forgot, due to the state it is practically not the best protocol for mobile clients over 2G/low end 3G.

It's not the worst, I think h2 would be fine if it would be 10 years earlier, since I think we can learn a lot from the behavior of h2 in real world scenarios and than use the best things from http/1.1 and h2 to make h3.

<comment><USER49> I thought HTTP2 was born out of the experimental SPDY protocol which was used in the wild for quite some time, maybe 5 years. I think SPDY was released around 2010.

HTTP2 is like the good parts of SPDY and what was learned over that time period (I think).

<comment><USER48> SPDY wasn't in widespread use (I think it had something like 30% usage), especially not in mobile environments. basically I also did not say that h2/spdy is bad, it actually solves some things, but makes others worse. it actually solves head of line blocking. multiplexing is cool, but comes with the overhead of a connection state.

I think h2 is perfect for RPC like architectures, interconnection between servers is a perfect fit for something like h2. but when it comes to real world traffic it depends on too many parameters. The sad part is, is that h2 will take forever to gain that data and to have widespread usage. the hard part will be 100% h2, a lot of stuff prolly only uses h2 at the edge.

Also most flaws of h2, will probably be fixed without a new protocol, i.e. in the next 10 years I hope that _all_ mobile environments have a widespread use of 3g networks (or to say it differently, I dream of) and hopefully all network people make world wide latency better and make all networks more reliable.

</comment></comment></comment></comment></comment></comment><comment><USER47> Wow, I thought I knew basic HTTP but I don't know anything about preloading or prefetching or early hints. Time to read up.

<comment><USER50> Don't beat yourself up _too_ much. The document is marked "2017-10-30 (latest revision 2017-10-28)".</comment></comment>


Amazon Finally Discloses Cloud Services Sales, Showing 49% Jump - T-A http://www.bloomberg.com/news/articles/2015-04-23/amazon-finally-discloses-cloud-services-sales-showing-49-jump <comment><AUTHOR> 5 billion dollars a year. That is pretty impressive.

Compared that to a company like Google that can't make any money at all off their infrastructure except with search ads[1] :-) That is the real story for me. And a tiny bit personal because when I was there I didn't feel that platforms got nearly the respect they deserved for keeping the roads rolling.

Congratulations to the Amazon team, that is an impressive feat indeed.

[1] [http://investor.google.com/earnings/2015/Q1_google_earnings....](http://investor.google.com/earnings/2015/Q1_google_earnings.html)

<comment><USER2> It's even more impressive when you consider his statement:

> "Amazon Web Services is a $5 billion business and still growing fast -- in > fact it's accelerating,"

I take that to mean that the business is growing but the rate of growth is also growing (hence "accelerating"; I like how he puts it so succinctly).

<comment><USER3> The rate is not growing: 2015Q1 49%, 2014Q1 69%.

<comment><USER4> > "Amazon Web Services is a $5 billion business and still growing fast -- in > fact it's accelerating,

Revenue 2013: $1000 Revenue 2014: $1690 (+ $690) Revenue 2015: $2518 (+ $828)

With those figures you could still argue that growth (in terms of extra revenue per year) is accelerating.

<comment><USER5> Still even more impressive is AWS keeps dropping prices year after year and has impressive revenue growth.

</comment></comment></comment></comment></comment><comment><USER6> Consider that their revenue is about the same as what Salesforce (CRM) will likely report (based on analyst estimates). This is pretty impressive:

      - Q1 2015 revenue: $1.57B (AWS) vs ~$1.5B (CRM)
      - Q1 2014 revenue: $1.05B vs $1.23B
      - Q1 YoY change: 49% vs ~22%
      - Q1 2015 operating income: 16.9% vs (~3%)
      - Q1 2014 operating income: 23.3% vs (4.5%)

Basically for all the talk that Amazon is a low-margin, commodity business that will never make money, their AWS business at least is doing really well.

I'm not taking anything away from Salesforce, it just happens to be a similarly sized comparison that most people thinks is a pretty good business. When compared, AWS looks pretty great!

<comment><USER7> It also means Amazon has massive room to shrink margin to stay competitive.

</comment></comment><comment><USER8> in the style of Drake equation: $1.5B/quarter, supposedly 1/3 of it is billed CPU time, at $1/hour per one 1U computer, at 500 hours billed per quarter per computer we have 1M computers - at 40 boxes per rack we have 25K racks, at 50 racks/row it would be 500 rows, at 50 rows per "warehouse" it will be 10 "warehouses". The storage money and racks i'd suppose is comparable to CPU boxes in numbers. So in result it would be 10 "warehouses" of 50 rows of 100 racks.

<comment><USER9> I like your approach, and have some thoughts relevant. What's a computer? The $1/hour revenue is generated by AWS from FAR less than 1U. SuperMicro sells a 2U machine with 4 full sized computers in it with 6 drives. You can put 12 cores in that, and an AWS 'ECU' core is a hyperthreaded core. So, in the Supermicro "quadnode" [1] version you get 4 * 12 * 2 = 96 cores in 2U, or 48 cores per U. An AWS computer/instance that costs $1/hour is a "m2.4xlarge" [2] which has 8 cores. So you can sell 6 "Computers" per U with this math.

[1] [http://mezz.ixsystems.com/servers/families/?family=Gemini4](http://mezz.ixsystems.com/servers/families/?family=Gemini4) [2] [http://www.ec2instances.info/](http://www.ec2instances.info/)

<comment><USER8> > SuperMicro sells a 2U machine with 4 full sized computers in it with 6 > drives. You can put 12 cores in that

i don't think AMZN or Google put 4 sockets per 1 U. While obviously it is possible, it would be pretty dense for normally powered chips. My understanding is that 2 socket/1U is more typical. At 100W/chip it would be a difference between 8KW and 16KW heat from a rack. But anyway, you're right - AMZN probably gets more than $1/1U. Their cluster 2-socket (16 real, 32 v-cores) instances go for $3.5/hour. Starting from that number we can adjust it down somewhat for pre-paid/reserved/spot pricing. Anyway, lets hope fuzziness in one number is compensated (not amplified :) by fuzziness in another ... Actually from the 2013 link you posted in the response below (that one - [https://storageservers.wordpress.com/2013/07/17/facts-and- st...](https://storageservers.wordpress.com/2013/07/17/facts-and-stats-of- worlds-largest-data-centers/)):

"Amazon data center- Amazon has around 450,000 servers in its data centers sited in 7 locations in the world. "

So adjusting for 1+ years of growth (of at least 10-20% as they had 49% revenue increase) my original estimate was less than 2 times wrong :) Edit: actually adding storage servers - may be up to 4 times wrong if they have all 1U servers, so the most probable parameter to adjust would be $/1U to something like $2+/1U.

<comment><USER10> With the photos released by Google/MSFT/FB and OpenCompute specs they are putting ~60-96 "1U equivalent" boxes per rack (each with 2x E5-2600 class CPUs). Getting datacenter densities to 25kW/rack requires a bit of extra work (Chimneys, containment, etc) but the big guys do this already.

[http://www.intel.co.jp/content/dam/www/public/us/en/document...](http://www.intel.co.jp/content/dam/www/public/us/en/documents/best- practices/data-center-facilities-paper.pdf) covers it fairly well.

<comment><USER11> It's totally possible to get to 80 general purpose compute servers to a rack, with a power draw of around 15kW. I prefer the Supermicro FatTwin, but there are other options with similar density.

It usually isn't worth going to a mega dense rack (25kW or whatever), because unless you built the entire site with this in mind, you'll probably run out of power before you run out of space. Then you spent extra on these extreme density solutions for no real return. It can still make sense, if the entire solution is thought out.

</comment></comment></comment></comment></comment><comment><USER12> Jesus, I'm occasionally amazed at GAAP for not requiring breakout of a business unit as large as $6 billion (last quarter obviously somewhat less) simply because the overall company is comparatively large; especially so when the profitability of the unit is so different from the overall company. Seems fucking material to me.

<comment><USER13> I believe that's why Amazon went ahead with it. If you don't run into SEC requirements, you run into aggressive shareholders that will cause you legal problems trying to force you to reveal the value of such an enterprise. Suddenly Carl Icahn is breathing down your neck trying to get you to reveal that info, so they can judge if it should be spun off. The shareholder risk becomes immense the larger a business like that gets without breaking out any financial information on it.

<comment><USER12> I think you're correct, it probably just hit 5%. I'm just honestly amazed given the lack of transparency and risk in super gigantic corporations that there isn't an absolute dollar threshold for lines of business as well as a percentage one.

</comment></comment></comment><comment><USER14> "Since its inception, Amazon has refined and expanded AWS while competitors including Microsoft and Google have tried to replicate its success with similar projects. Those companies have only recently started to deliver basic services on par with Amazon's."

Is this really true? I know that AWS offers many more services than competitors currently, but for the services for which there is a competing product, is the AWS offering really that much better?

<comment><USER15> Compared to Azure, yes. The IaaS offering on Azure has many, many limitations. It is also very difficult to use. There is no general pool of servers. You have to cram VMs into these groupings called "Cloud Services" which are limited to 50 VMs each. No support for TLS termination on their load balancers. SSDs are currently a "preview" feature and only work on a subset of hardware types.

In all fairness AWS had a 4-5 year head start on Azure. Also there are a lot of really exciting things coming down the line for Azure. I don't expect this gap to last long.

Competition is good!

<comment><USER16> SSDs, okay. That's something that's legitimately difficult to scale, particularly if you've invested heavily on spinning disks and made assumptions about their performance/reliability. I get that.

But no TLS termination? At a company that has invested $15bn on their cloud products and has in-house expertise on the actual source code of one of the most widely-used networking stacks? That's... surprising, to say the least.

<comment><USER17> What does the lack of SSL termination mean? We are running many services in Azure which we access using TLS1.2 via the loaf balancer so what would SSL termination add to this?

<comment><USER18> Wikipedia is short and to the point on this one

> An SSL termination proxy is a proxy server that is used by an institution to > handle incoming SSL connections, decrypting the SSL and passing on the > unencrypted request to the institution's other servers (it is assumed that > the institution's own network is secure so the user's session data does not > need to be encrypted on that part of the link). SSL termination proxies are > used to reduce the load on the main servers by offloading the cryptographic > processing to another machine, and to support servers that do not support > SSL, like Varnish.

[http://en.wikipedia.org/wiki/SSL_termination_proxy](http://en.wikipedia.org/wiki/SSL_termination_proxy)

</comment></comment></comment></comment></comment><comment><USER19> "These have since become common building blocks of Internet-based computing systems, supporting companies ranging from large enterprises like Infor US Inc. and Netflix Inc. to startups such as Instacart Inc."

When I see a brand name mentioned randomly in an arricle, I wonder who paid for it. Why would Bloomberg mention instacart specifically? Is it common practice for companies to pay for these subtle pseudo-mentions in articles?

<comment><USER20> Not paid directly - it's a combination of 1) brands being top of mind 2) what people / robots will recognize and ever so likely potentially to share or what will have the tiniest bit of extra SEO juice.

#1 only comes from a lot of ongoing PR outreach, coffee chats, briefings, etc - which takes time and $$$$ usually via an agency working nonstop on developing relationships to keep a brand top of mind for side mentions like this and to be at the top of the rolodex when a reporter needs a quote or some help understanding an industry or technology space.

<comment><USER21> It's also entirely possible that the reporter either asked AWS for some customer names and cherry-picked those, or the reporter asked their network for some names. In my experience, it's not paid other than in really shady non-mainstream media sites.

<comment><USER22> It's an interesting question because many more well know startups use AWS (Airbnb, Pinterest, Etsy, Spotify). Amazon has a webpage specifically to highlight them: [http://aws.amazon.com/start- ups/](http://aws.amazon.com/start-ups/). It's hard to imagine that Instacart would be the startup that would be offered as an example by Amazon or the reporter's network. It wouldn't surprise me if reporter was friends with the founders.

</comment></comment></comment></comment><comment><USER23> Judging by the size of the AWS bill that companies pay without a peep, I don't think anyone here is incredibly surprised.

<comment><USER24> With reserved instances, prepayment, and other tricks you can about halve AWS costs at scale.

<comment><USER25> But still get worse performance than bare metal (noisy neighbors, inconsistent EBS performance, intra-instance network latency).

Disclaimer: DevOps for AWS and bare metal infrastructure.

<comment><USER26> Sure, virtualized OS' are always going to have some overhead vs. bare metal.

<comment><USER27> My understanding is that the OS virtualization is actually a relatively minor part of the difference.

</comment></comment></comment></comment></comment><comment><USER28> With such slim margins AWS and the larger cloud services industry of today will become what the airlines industry has become.

<comment><USER29> The barriers for entry to Cloud are actually higher than for airlines IMO. In the long run it will become more like the utility industry (think electricity) than airlines.

To get into the same cloud market as AMZN/MSFT/GOOG you are going to need:

1\. Several billion dollars of Capex to get to the same scale as the incumbents. 2\. A large amount of investment to replicate all the internal software that Amazon and friends have. 3\. Goodwill from startups and/or enterprise CIO types.

Getting into the airline business is comparatively easy:

1\. You lease the planes from Boeing or Airbus. 2\. Pilots and other staff are highly skilled but otherwise fungible. 3\. Marketing through traditional consumer channels and price comparison engines is very well understood and if you're willing to eat the losses then growing share is doable.

<comment><USER30> Getting into the cloud, and getting into the cloud on the same level as Amazon, Microsoft, or Google are two different things.

Just like getting into the airline business, and getting into the airline business to compete with the likes of American Airlines, Lufthansa or United Airlines are two different things.

The same overly simplistic business plan could just as easily be applied to 'getting into Cloud', and while leasing a few business jets off Boeing has it's own page on boeing.com[1], it's still a significant expenditure.

Here's the same plan:

1\. Lease a pile of servers from Dell or HP

2\. Developers, Sysadmins, and other staff are highly skilled but otherwise fungible. OpenStack is rapidly maturing so you can take advantage of that.

3\. Marketing, marketing, marketing. Through newer online social media channels instead and compete on price.

Airlines are famous for making only meager profits, especially considering the capex required to play.

Since Cloud is still a relatively immature industry, there's still room for niches, just like the airline industry has regional airlines. All GPU cluster anybody? Bare-metal Private Servers? Digital Ocean and Rackspace are chugging along just fine.

How about selling of Cloud services that run on top of AWS? Is that still Cloud? Dropbox famously started off just running on top of Amazon's S3, and I'd definitely call them Cloud. How about if you setup Heroku for Erlang? Scala? No billion dollars of Capex required, and I'd still definitely call Heroku a Cloud business.

Trying to compete with the likes of Amazon, Microsoft, or Google without billions of dollars is tilting against windmills, but to say 'getting into cloud' requires several billion dollars at the outset is a bit of an overstatement.

[1] [http://www.boeing.com/company/about- bca/startupboeing.page](http://www.boeing.com/company/about- bca/startupboeing.page)

<comment><USER31> """1\. Lease a pile of servers from Dell or HP

You already lost the game. The entire point of cloud computing is you don't need any of the features that Dell and HP heap onto their servers. Every port, every button, every LED costs you another couple hundred mW.

</comment></comment></comment></comment><comment><USER32> Is there any chance that Amazon might spin off AWS to a separate company? Or would that be suicide to the stock price of their retail business?

<comment><USER33> What is the advantage to spinning it off to its own company?

<comment><USER13> You do that when the value inside the company is being perpetually vastly under-represented (combined with shareholders applying a lot of pressure to unlock, say, a stagnant stock price).

For example, if AWS is worth $100 billion in ten years, and Amazon as a whole is only being valued at $150 billion in the public market at the time. Separate the two might be worth $100 billion each at that point.

The argument for eBay spinning off PayPal is this same premise - that PayPal is being undervalued by a lot hiding inside eBay.

<comment><USER19> Amazon is losing money as a whole, but AWS Is profitable. Isn't that the same concept as PayPal hiding in ebay?

<comment><USER13> eBay is extremely profitable, far more so than PayPal. PayPal's margins are not particularly impressive.

PayPal however is growing much faster than the auction platform (which is hardly growing).

The old processors like Visa and Mastercard have had amazing value increases in the last ten years. Visa is now a $160 billion company with 40% net income margins. PayPayl is a very attractive target for the big four of Visa, Mastercard, Discover, Amex. That will drive up its perceived value. One of those big four is very likely to go after a merger or acquisition of PayPal after the spin-off.

</comment></comment></comment></comment></comment><comment><USER34> This article shows relative "cloud" revenues numbers between Amazon, IBM, Microsoft, and Google. In this context, Amazon doesn't look that big.

[http://finance.yahoo.com/news/official-amazon-strongest- clou...](http://finance.yahoo.com/news/official-amazon-strongest-cloud- business-204718694.html)

<comment><USER35> That article doesn't support your point, except perhaps for IBM and it's hazy to me what exactly that revenue is. It's certainly not from the type of developer-targeted infrastructure services that AWS is.

As for Microsoft, quoting directly from your link: "One person has told Business Insider that Azure revenue is at $1 billion lifetime since its debut in 2011, but is accelerating quickly."

<comment><USER36> IBM owns Softlayer in addition to internally developed services.

</comment></comment></comment><comment><USER37> Interesting to see the after hour stock price jump.... [https://www.google.com/finance?q=NASDAQ%3AAMZN&ei=HXA5VcnWBY...](https://www.google.com/finance?q=NASDAQ%3AAMZN&ei=HXA5VcnWBYSwiQLU2oHQBw)

<comment><USER38> Especially if you hold some shares :)

I thought that the potential profits of cloud business were already being factored in the current evaluation, but apparently it was more profitable than the analysts (which were probably imagining the same thin margins as the retail business) expected.

</comment></comment><comment><USER39> I don't think the growth will accelerate as the article claims as the barrier to entry is becoming less and less each day. It should be interesting to see how it plays out.

<comment><USER40> There are HUGE barriers to entry. What is the reason behind the "barrier to entry is becoming less and less each day"?

<comment><USER41> Not parent but I'd guess they are talking about OpenStack but if they are they are wrong. Running a data center is no easy or cheap task. Sure you might have SOME of the logistics cut out for you using OpenStack but the barriers to entry are still VERY high.

<comment><USER20> Openstack + spare capacity in a colo facility + a bunch of few years old servers offloaded in a facilities auction and you can build one pretty quickly.

Tech isn't the hard part - barriers to get a service up and running are dropping drastically.

Hard part is marketing & scaling, and as AWS expands services there are risks from pure-play vendors that do just one slice of the stack 2-3x better than Amazon does.

<comment><USER42> It isn't as easy as you make it sounds, just a few thoughts:

1\. OpenStack still has plenty of bugs and issues you are going to hit.

2\. You'll still need a really good colo facility.

3\. High bandwidth and Multiple internet providers are expensive. If you look at Amazon they have an excellent blend of bandwidth including direct connectivity to many eyeball providers (Comcast, Charter, RCN etc.) which usually makes your data get there quickly and prevents peering bottlenecks.

4\. If you need more than one facility then you just get to double your costs.

5\. People costs, you'll need people that can manage your infrastructure at scale.

6\. Hardware capex can severely drain companies.

7\. Vendor sprawl and support. (You still may need a CDN, DNS provider, etc.)

Doing your own thing can quickly become much more expensive than Amazon or other cloud providers.

</comment></comment></comment></comment></comment><comment><USER43> An alternate view: [http://market-ticker.org/akcs- www?post=230060](http://market-ticker.org/akcs-www?post=230060)

</comment><comment><USER44> Does anyone have insight into AWS revenue per service? Does EC2 generate the bulk of the revenue? Is Lambda the fastest growth area? How is Redshift doing?

<comment><USER45> I'm sure Amazon knows and, since this is the first aggregate disclosure, that there's no way they're going to state publicly.

</comment></comment><comment><USER46> Very Impressive

</comment><comment><USER20> TL;DR on AWS

\- $1.57b in revenue in Q12015 on $22.72B total ($5B annualized for AWS)

\- $265m in operating income (net loss for Amazon as a whole was $57m)

Looks like revenue was slightly lower but operating income quite a bit higher than most Wall Street estimates.

<comment><USER47> I just don't understand when people use TL;DR and comment on an article they have not even read.

<comment><USER48> It's a way to say "to people not interested in reading the entire article, this is the most important information:"

<comment><USER20> Yep - the article itself isn't terrible exciting outside of the core AWS numbers, but this now serves as the place for the HN community to talk about it - because the numbers are what's interesting.

</comment></comment></comment></comment><comment><USER49> I believe this happened because companies like [http://www.cloudways.com/en/](http://www.cloudways.com/en/) are integrating Amazon cloud infrastructure smartly to build a service for application developers.

Usually, application developers are not good at server side configurations. They want something that's easy to setup and help them deploy their applications like WordPress, Magento, Drupal, Joomla etc.

Companies like Cloudways are taking away a lot of pain and giving those application developers a chance to easily setup their apps with premium support.

Don't you think that's attractive? and a business opportunity as well.

<comment><USER50> Shillways. Your comment history is amusing.</comment></comment>


Ask HN: Charge in Euro or Dollars for an online service? - <AUTHOR>

We are running an online service (http://decor-fb.com/) and are currently charging our customers in Euro.
Users subscribe with a monthly plan and we are using facebook payments.
Our customers are from all over the world, our top countries for already paying customers are Brazil and Italy.
We are considering changing our plans to charge in dollars instead.
I wonder have any of you have experience in charging in both USD and Euro and if the wrong currency this is a deal breaker for potential customers. <comment> workhere-io Only 45% of Europeans use euros ([http://en.wikipedia.org/wiki/Eurozone](http://en.wikipedia.org/wiki/Eurozone)), so even for some of your European customers the euro is a foreign currency. If, on top of that, you have a lot of customers from outside Europe, I would say go with USD.

Having said that, I don't think you charging in EUR would be a dealbreaker.

<comment><AUTHOR> Thanks. I wonder if there are studies in conversion rates when using different currencies...

<comment><USER2> I wouldn't be surprised if it impacts it a bit. While I wouldn't mind paying in Euros, my currency is USD. When I see prices in Euros, my first thought is "that's not actually that much, it's actually more expensive." Then I catch myself and go and covert the price to figure out how much it actually is.

I have an aversion to fees though, and while I wouldn't mind buying the SaaS, I then have to remember which of my credit cards charge foreign exchange fees and how much they are, and then add that to the price of the service I'm buying.

So I guess it depends on how logical your customers are, where they would stop in that thought process, or if they would care if your prices were 3.5% higher to them.

EDIT: Also, on pricing I think maybe you should consider getting rid of the 0.99 cents on there. There's a bunch of logic in pricing, but I think in general $X.99 is what people expect to see, whole numbers is premium (think upscale restaurants), $X.95 is a bit better than $X.99, and then if you have an odd amount like $X.82 they would think it's discounted.

<comment><AUTHOR> Thanks for the feedback! We are now trying out USD with the .95 price point instead to see if there is any difference in conversion rates.</comment></comment></comment></comment>


ARM Targets New Cortex Processors at Machine Learning - <AUTHOR> https://www.hpcwire.com/2017/05/30/arm-targets-new-cortex-processors-machine-learning/ <comment><USER2> Hard to see this making a dent against GPUs for training. But the article doesn't specify that these devices are for inference.</comment>


Ask HN: Why the next Facebook won't come out of an accelerator - <AUTHOR>

There was a blog post here by that title or similar. May replace "Facebook" with the "next big thing" or "accelerator" with "Y Combinator". But my Google search skills and HNsearch isn't helping me out here. Anyone bookmark it? <comment><USER2> [http://www.quora.com/Technology-Trends/What-will-be-the- next...](http://www.quora.com/Technology-Trends/What-will-be-the-next-big- thing-after-Facebook-and-Twitter-1)

Is it this? One of the answers matches your phrasing.

<comment><AUTHOR> Sorry Isaac, but it was on a blog with much similar posts to yours and swombat's. Btw, one of my all time favourite posts actually is your "Two paths to greatness" one. +1 Thanks for that.</comment></comment>