The new PHP - <AUTHOR> http://programming.oreilly.com/2014/03/the-new-php.html <comment><USER2> While the gist behind this post is right, the article contains a number of factual errors. E.g. the version numbers in the "language features" section are pretty messed up:

* Namespaces, closures and FPM were already in PHP 5.3

* The built-in web server was already in PHP 5.4

* Improved variadic functions, argument unpacking and phpdbg will be in PHP 5.6, which goes to beta in about a week.

<comment><USER3> Hi nikic. Thanks for the feedback! (I'm the author of that article). The O'Reilly editors made a few changes to the wording without my review that make it more ambiguous as to what features were introduced in what version. I agree as is it can be confusing. But the point is that the latest version of PHP provides all of these features. The variadic function statement was an error on my part and it has since been corrected in the article.

<comment><USER4> Do you really think tacking on more badly designed features makes PHP better? PHP's "closures" require you to write down the free variables in an enclosed function and tell PHP that they exist, that is something a compiler should be doing. Google "closure conversion".

<comment><USER5> > PHP's "closures" require you to write down the free variables in an enclosed > function and tell PHP that they exist

Can you give an example? I googled "closure conversion" but didn't understand.

<comment><USER6> In order to use variables from the scope that the anonymous function came from, you have to explicitly import them into the anonymous function with the use[1] block:

        public function getTotal($tax)
        {
            $total = 0.00;

            $callback =
                function ($quantity, $product) use ($tax, &$total)
                {
                    $pricePerItem = constant(__CLASS__ . "::PRICE_" .
                        strtoupper($product));
                    $total += ($pricePerItem * $quantity) * ($tax + 1.0);
                };

            array_walk($this->products, $callback);
            return round($total, 2);
        }

In other languages that have true closures, the anonymous function "closes over" the lexical scope in which it was declared.

[1]: [http://www.php.net/manual/en/functions.anonymous.php](http://www.php.net/manual/en/functions.anonymous.php)

<comment><USER7> Yeah, so? Sounds even better, as you can only declare what you'll actually use from the enclosing scope.

Besides, doesn't Python work the same way?

<comment><USER4> Wrong. You only need to use the free variables of the closure, you don't need to copy the entire environment from the function you're defining your closure in. By the definition of a free variable you actually use it, otherwise it wouldn't be a free variable of the function! Python definitely does not work the same way, but in Python "x = 3" can inadvertently shadow (make a local name) something defined in the outer scope, but that's a completely different problem.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> > generators for simpler iteration, namespaces, and variadic functions and > argument unpacking. With PHP 5.4, traits were introduced (a la Scala or > Perl) to allow code reuse in single inheritance languages, as well as > closures, which allow you to code PHP in a functional style.

"The new Java"

It's good to see PHP maturing. However sometimes the most important features of a language are the features you _don 't_ add. I think PHP would do itself a big favor by cleaning up its main APIs and standard library first. Maybe they will do that in PHP 6, since I doubt they want to break APIs in minor releases.

<comment><USER2> PHP has a rather strict no-BC-break policy for minor releases. As such the 5.x series improves the language mostly through additions. I think that's good. PHP has been missing a number of things that are now present.

However that doesn't work forever, at some point you need to clean up some of the old stuff. That's why a PHP 6 release is planned in the near future (i.e. somewhere in the next three years ^^).

<comment><USER9> The very first programming book I bought was "PHP6 and MySQL5" by Larry Ullman. I bought that one specifically because I had another job (career, really) and I knew it was going to take a while before I really got into programming and I didn't want to buy a book that was going to be out of date in 2 years. That book is now 6 years old, out of date, and PHP6 is still not released. Maybe 6 is just an unlucky number with Perl unable to make that goal as well, but either way I'm not holding my breath.

I've since moved on to more well thought out languages, though PHP keeps pulling me back in. I'm currently having to support a CI app that hasn't had a line of code added to it since 2008, and the only thing I can say, even though I appreciate the language and how far it's pushed the web, I'm glad it's no longer my go-to language of choice. Keep PHP5 around for a while so apps like this one can continue on, but PHP6 is _LONG_ overdue.

<comment><USER10> Literally bought the same book by Larry Ulman.

<comment><USER11> I bought the same book metaphorically.

<comment><USER8> Same here. Larry's a great author. I got started with his books years ago. He definitely makes Web dev feel more approachable, which is invaluable to a newbie. I believe Patrick Collison from Stripe also got started on Larry's books (for some reason I recall a conversion on Twitter or the like about this).

</comment></comment></comment></comment></comment></comment><comment><USER12> It really pains me that there are so many utter misunderstandings about modern PHP from people that used it years ago and have no clue about the current landscape, even in this thread.

Yes, the PHP core api is still a bit messy due to backward compatibility, but everything else it pretty awesome really. Please take a closer look if you haven't touched PHP in years, before you talk it down.

<comment><USER13> Oh, did you mean PHP the language? The webserver? The FastCGI server? The runtime?

PHP starts as a fucking mess and gets worse. Maybe once the developers figure out what it is I'll take a look but yeah it's pretty much the developers taking standard features from other languages and fucking them up just like they did yesteryear.

Closures with a use block... even in C you don't have to do that... it's a joke and a mess... How is it that a 44 year old language has better features and less cruft than one 15 years old?

Does it have a ==== operator yet?

<comment><USER14> Yeah, the functional programming side of PHP is ugly as sin.

Forgot to add your latest variable to the use block? No "closing over" for you.

What's that? _All_ array function are prefixed with "array_"... except for the old ones which aren't, making it both verbose _and_ confusing.

</comment></comment></comment><comment><USER15> I'm a Drupal dev by trade, and I consider any day that I don't have to get into the guts of Drupal and write PHP a good day.

Recently, however, I had to get in there. This was a few days after I upgraded my local environment from 5.3 to 5.5. I've been writing Ruby for fun for a while now, and I love how I almost never have to look API related questions up, at least in comparison to PHP API questions. So I just wrote some PHP without looking up whether it was going to work, and it worked, first try. That rarely happens. Then I pushed it to dev, which is still on 5.3, and took the (dev) site down. Turns out the feature "array function dereferencing" is not available in 5.3, so I had to rewrite my code a little bit.

Point being, I could see myself liking PHP more when we move to 5.5 in all our environments.

<comment><USER16> I did the same job for 6 months. I really like PHP nowadays, but Christ Drupal core is a mess (or was, that was v6).

<comment><USER17> If I may ask, what other languages do you have experience with and what are your opinions of them?

<comment><USER16> Ruby, extensively. It's enjoyable and quite useful. Meta programming makes me think of Lisp, but need to be careful of side effects.

Go, recently I've been using it for certain services and APIs. Really great for concurrent programming for services, syntax is nice too.

Python, I've used a few times over the years and have used it with personal projects a number of times. Still like python quite a bit.

(Bonus: nimrod, which I'm helping build a new type system for, Clojure and Scala I've played with extensively but never had a chance to use in production, and C/C++/Vala I've used when doing desktop programming on Linux for Elementary)

</comment></comment></comment></comment><comment><USER18> All this is very true.

Modern PHP is not the PHP of yesteryear. With Composer for dependancy management and sticking to the PSR's you can build very stable, testable, and modern applications that change minds about PHP.

<comment><USER19> The thing is you have to be a medium-to-expert to be confident about Composer dependencies, every new dev is going to use the language API, which resembles a bunch of functions with no general pattern.

PHP users need to keep it together and set a common base, a standard library with sane defaults.

<comment><USER20> I am new to PHP and I started right off with composer -- all you have to do is composer require pkg dev-master [or other pin].

I don't see how this is different from gem install pkg.

</comment></comment></comment><comment><USER21> > It contains powerful new features and helpful developer tools, such as a > built-in web server

I haven't finished the article yet, but really? Is that what PHP needs? A built-in web server? It strikes me that adding more tools that incompetent web developers can abuse is what got them there in the first place.

How long until we start having security releases for the PHP web server, because so many clueless devs decided to launch and run their site with it?

<comment><USER22> The web server is explicitly for development purposes. It is _not_ meant for production.

> It strikes me that adding more tools that incompetent web developers can > abuse is what got them there in the first place.

This is profoundly ridiculous. It's the equivalent of saying Home Depot shouldn't sell power tools because some do-it-yourselfer might saw his foot off.

Just because a tool can be misused is _not_ an argument against it nor its inclusion.

<comment><USER23> _Just because a tool can be misused is not an argument against it nor its inclusion._

I used to believe this, but now I couldn't disagree more. People can and do misuse things all the bloody time, and the more you enable them to do that, the worse your tool is. How people use what you make is every bit as important, possibly even more important than the technical merits of what you make.

I'd rather a builder use a second hand hammer to nail something than try doing it with a jackhammer.

<comment><USER24> I don't hear people complaining about Python's builtin webserver. Maybe thats because Python only attracts people who do things correctly right?

<comment><USER25> Python doesn't have a builtin webserver, but there is one in standard library of CPython.

I've yet to see an article that would argue that its existence is a proof that you should be using Python now.

<comment><USER16> Then you missed the point of the article, and also obviously don't use PHP regularly. It's a super handy feature.

</comment></comment></comment></comment></comment></comment><comment><USER26> I sometimes ponder what I'd fix, given the chance, about PHP:

* Make the "stdout == response body" an explicit option, and make a rendering engine the default instead. Just sending all output is a senseless DEFAULT.

* Remove all the array_x functions and turn arrays into a class instead, and change the parameter order to be consistent across all the functions. A similar action could be done across many other classes of functions, too.

* Tighten equivalence requirements, == should work like ===.

* Etc.

But I always realize I'd just end up with Ruby or Python, both of which already exist and have fantastic ecosystems. Oh well.

<comment><USER27> Make the "stdout == response body" an explicit option

Why? It's a primary differentiating factor for PHP, and one of the cornerstones of its popularity. Given that it powers a non-trivial percentage of the web, from single page "hello world" sites up to multi billion dollar ecommerce sites, I'd say 'fixing' that one aspect is not something that needs to be.

"== should work like ===". Why? If you want ===, use ===. But given that HTTP, the lingua franca of the web, is typeless, and PHP is targeting web developers, having a language that doesn't enforce types in all cases isn't all that bad.

<comment><USER26> 1: "Explicit option" means it's still possible, but shouldn't better practices be encouraged? Anything to push developers away from interleaving logic and templates

2: PHP, however, has types. == is wildly unpredictable

<comment><USER28> 1\. Why add complexity when it isn't necessary? Inline output is one of the best features of PHP in that it makes it _extremely_ easy to get started using it. If you want templates you can add them. Not everyone wants them.

2\. PHP is dynamically typed, like many other languages, and so you just have to know what types something can be and how they behave together. Even in a statically typed language you need to know how type conversions work. That's what the documentation is for ( [http://php.net/manual/en/language.operators.comparison.php](http://php.net/manual/en/language.operators.comparison.php) ). It's not "wildly unpredictable", it's defined and deterministic.

<comment><USER26> Easy to get started, then what? I didn't learn how to structure big projects until I moved to better languages that encourage (through defaults) better practices.

Predictable !== well defined. If you have to look through a chart for equivalence, it's unpredictable to the programmer. But this is a theme for all of PHP, you can't deduct equivalence, function names and function arguments orders, you have to memorize or peruse the manual. Sure, it works, but it has drawbacks.

<comment><USER27> "I didn't learn how to structure big projects until I moved to better languages that encourage (through defaults) better practices."

Do you think that PHP is the only language where developers look to other practices in other language communities to learn different/new/better/changing practices? Every _good_ developer is aware of patterns and structures in other languages/platforms - I dare say it's almost the definition of a good developer. I would _not_ regard a Ruby developer who'd only ever done Rails projects as a 'good' developer, regardless of how clean/elegant the code seems.

</comment></comment></comment></comment></comment></comment><comment><USER29> Whenever I hear "the new PHP" or "its not the old mess anymore", I say to myself, thats hardly the point. The key flaw I find with PHP is with its community and lack of any mature frameworks. Half of the PHP coders are hopeless script kiddies, thanks to low barrier entry it has, and I don't feel a single framework exists that can match Rails or Django. For the matter of fact, the framework with largest community, Codeigniter, only has inline test functions for any kind of testing and doesn't even come with a auth library.

Being a PHP developer myself, I can't refute that only selling point of PHP, albeit, a major one, is its so "easy" to get things done. I feel in the near future, with advent of tools to make mature frameworks more accessible, PHP would cease to be a tool for any serious web development.

<comment><USER30> Codeigniter has been all but abandoned by EllisLab, the community is giving up on it and there are far better frameworks available now. For example Laravel, the growth that Laravel is experiencing right now is huge, it has overtaken Codeigniter as the most popular PHP framework on GitHub and has a growing and active community. Anyone even _thinking_ about Codeigniter any more is doing themselves a disservice, Laravel is leaps and bounds ahead of Codeigniter. Laravel is on its way to being the Rails of PHP.

[http://www.google.co.uk/trends/explore?hl=en- US&q=laravel,+s...](http://www.google.co.uk/trends/explore?hl=en- US&q=laravel,+symfony,+codeigniter,+zend)

<comment><USER31> I recommend FuelPHP [1] - it has amazing documentation, a lot of built-in libraries, takes advantage of PHP5 features, is quite mature and really easy to dive in.

[1] [http://fuelphp.com/](http://fuelphp.com/)

<comment><USER32> +1 for FuelPHP - well thought out and easily extensible.

</comment></comment></comment></comment><comment><USER33> To me the criticisms about PHP are pedantic and is a result of misunderstanding the philosophy behind PHP. The kneejerk reaction language modifications the PHP community made because of the 'PHP sucks lol' meme is detrimental to the language itself.

PHP is a mature webdevelopment language that features an easy to learn, read, and develop feature set. Scala or Perl are not. (See Perl 6) So I don't see how emulating it will provide any form of benefit. Picking up a language feature because a guru attacks PHP because they can write a feature X in Y lines is almost an immature.

The reusability and performance issues were genuine, but these were to be expected given version iterations and the fact PHP introduced namespaces a while back.

<comment><USER34> I think most people don't really compare PHP to Scala: it is an entirely different language. I think most people who talk down about PHP do so because Python and Ruby are so much easier to understand and use. But then again I'm of the unpopular opinion (having worked professionally in all four) that Perl, PHP, Python, and Ruby should go into a cage, and only one should emerge. The others must write converters that turn their code into working code of the winner's, and we should stop having four languages that are basically all fighting over the same dynamic scripting language mindshare. Imagine if instead of worrying about "keeping up with the Rail's" you could just think about how to actually work on converting those Java/Haskell/Lisp programmers!

</comment></comment><comment><USER35> This may be of interest to some: I did research and found out that 58 out of 67 web hosts in Finland either offer PHP 5.4 or 5.5 right now or at least starting from summer 2014 (5.3 EOL is in July). An increasing number of web hosts give their customers the ability to switch PHP versions (with .htaccess or some web interface). It seems this trend will speed up the installation of fresh PHP versions.

</comment><comment><USER4> PHP's "closures" are basically you the programmer calculating the free variables in an enclosed function and then telling PHP you want them to be bound in an environment. I would laugh if it weren't so pathetic.

</comment><comment><USER36> I don't get it. Why people can't just admit the fact that PHP had his time and now, no one with common sense would not start new project (except simple wordpress stuff) in PHP.

<comment><USER37> In most enterprise environments, you have your choice between .NET and PHP. Given the option, I'll take PHP, thanks.

<comment><USER38> Twitter's code is "enterprise" code in that it has to satisfy the organization's needs and a huge part of it is not user-facing, but targeting other enterprises (for example, Twitter ads). At Twitter, we use Scala.

So, no, you're not necessarily stuck between these two options (or Java, which is another popular choice in the enterprise scene). Scala was chosen specifically, among other things, because Twitter had a lot of Ruby developers who would cringe at the idea of PHP, Java, or .NET.

<comment><USER39> Twitter is not what he meant by "enterprise." You work at a tech company. Enterprise connotes big corporate IT department software development.

</comment></comment></comment></comment><comment><USER40> I don't see any mention of the "new" zend opcache which has great performance.

</comment><comment><USER41> I used to write PHP before I got into Ruby. I'm glad PHP is getting it's shit together, but it's still a no-language for me.

</comment><comment><USER42> "There are only two kinds of programming languages: those people always bitch about and those nobody uses." \-- Bjarne Stroustrup

</comment><comment><USER43> I often wonder why a PHP killer hasn't yet been created.

I don't mean a Ruby or another vastly different language.

I mean a language similar in approach to PHP, but with the gotcha's removed, some order and consistency introduced into the API, and a few changes to the defaults. Open source, free, and on all major OS's.

<comment><USER36> check what PyPy did (or is doing with PHP).

<comment><USER44> Could you please explain it a bit or provide a link?

<comment><USER45> [http://morepypy.blogspot.com/2012/07/hello- everyone.html](http://morepypy.blogspot.com/2012/07/hello-everyone.html)

> I'm proud to release the result of a Facebook-sponsored study on the > feasibility of using the RPython toolchain to produce a PHP interpreter. The > rules were simple: two months; one person; get as close to PHP as possible, > implementing enough warts and corner cases to be reasonably sure that it > answers hard problems in the PHP language. The outcome is called Hippy VM > and implements most of the PHP 1.0 language (functions, arrays, ints, floats > and strings).

<comment><USER44> Thanks, seems very impressive

</comment></comment></comment></comment></comment><comment><USER46> What I don't comprehend is how someone can know of all this and then still stay "you know what? fuck namespaces and PSR, we are doing it old school!" and come up with arguments like "I/O overhead is costly in one class per file scenarios"[0].

These people will be the death of all of us.

[0] [https://www.sellvana.com/blog/on-composer-psr-and- namespaces](https://www.sellvana.com/blog/on-composer-psr-and-namespaces)

</comment><comment><USER47> The article compares PHP now to PHP in the past. But programmers should not do this, they should compare PHP to other languages and their ecosystems, and conclude that it is not fit for a greenfield project.

The new libs'n'tools are nice; good to see them showcased. But the bottom line for any developer should be to avoid it --like Perl-- for any from-scratch code. This is a legacy language now.

</comment><comment><USER48> [http://phpthegoodparts.tumblr.com/](http://phpthegoodparts.tumblr.com/)

<comment><USER49> > Here's a rule of thumb: If the O'Reilly company publishes a book called > "<blank>: The Good Parts" the thing that's in the <blank> is evil!.

\-- Matthew Butterick, RacketCon 2013

[http://shop.oreilly.com/product/9780596804381.do](http://shop.oreilly.com/product/9780596804381.do)

</comment></comment><comment><USER50> Here's what would make me accept PHP as passable practical web programming language: A good REPL, with good support for it over all frameworks. That's all it would take.

Given that it doesn't have one, python beats it easily.

<comment><USER51> You mean like boris? [https://github.com/d11wtq/boris](https://github.com/d11wtq/boris)

<comment><USER50> Looks good, but here's the practical question: Can I enter this REPL with all the libraries and models of my web framework loaded so that I can query a model through it, modify the object and save?

<comment><USER52> No more than you could with any other execution environment. Autoloaders should find your libraries if you are using the same entry point, and you can query a model as you could in any other language. It looks like people have made something like this for CakePHP: [http://josediazgonzalez.com/2013/12/04/interactive- command-l...](http://josediazgonzalez.com/2013/12/04/interactive-command-line- repl/)

And there are some REPLs with tab completion: [https://github.com/ErikDubbelboer/php- repl](https://github.com/ErikDubbelboer/php-repl)

</comment></comment></comment></comment><comment><USER53> > The memory usage in PHP 5.5 is far less than earlier versions.

Regarding Zend Engine, does anyone have a link for just how much 'less'?

</comment><comment><USER54> Let the hate begin

<comment><USER55> Ha! It's a pendulum that swings in both directions, and I think people are moving on from wasting their time and energy complaining about PHP. Here's what I have learned.

1\. Developers complain a lot, and that's a good thing. While it can seem unproductive at times and devolve into flame wars, the truth is you're not likely to choose this profession if you aren't curious and care about the right damn thing happening.

It's just a byproduct of what it takes to be a good dev. We research, we understand, and then we want to stand by our opinions because of that research and understanding. But we can also get lost in that sometimes. It's important to have pragmatism in our toolbelt.

At the end of the day, core maintainers or contributors make sure to cherry pick the best from those arguments. Pull requests are made. Merges happen. Things improve. It's not always pretty, but discourse is like that.

2\. The world isn't perfect. Neither are languages. PHP has its share of rough spots, but then it's how you use it. We've all seen some truly awful Ruby on Rails code, just as we've seen some solid, testable PHP code. Your job is understand the deficiencies of a language (any language!) and craft the best code around those limitations.

3\. Shiny new things give us blinders. The antithesis to ad hoc PHP might be Ruby on Rails. Yet people discount some drawbacks that are unique (from PHP) to RoR. Do generators, which are encouraged, really help teach a programmer about how their application stack is operating? Maybe you could tell someone to avoid scaffolding. Is Rails faster than well-architected PHP? Hell no, but maybe you could teach someone how to tweak middleware or use JRuby. But you'll notice the same pattern I mentioned in #2: understand deficiencies, create workarounds to those limitations. It's not unique to PHP, or any other language/framework.

And finally...

4\. When you are building things meant to be consumed by the general public, more goes into a language decision than the features of that language. You might, for example, have a business requirement to hire up and move very quickly. Are you going to round up a bunch of seasoned, veteren Go engineers in a few weeks to build the next sprint of some great app? It's probably not impossible, but it's not likely either (today). The trick is to solve the problems you actually have.

I'm not advocating everyone use PHP. I'm advocating everyone use the language that best suits their personal or larger business needs. If you care about improving PHP, help make it better. We, the general dev community, are all too busy, considerate, awesome, hard-working, friendly, and creative to spend much time on flame wars. :)

</comment></comment><comment><USER56> TL;DR: "sucks less?"

</comment><comment><USER57> Love the way they avoid mentioning Rails.

<comment> e-tron does anyone actually use rails anymore... node is the new bling!!!

</comment></comment><comment><USER58> same article could have been written like 1 year also .

</comment><comment><USER59> Same as the old PHP.

</comment><comment><USER60> The title is misleading; I expected an article about Javascript.

</comment><comment><USER61> Never go full retard.

</comment><comment><USER62> PHP is and will always be the choice of script kiddies and freelances looking for a quick small buck.

Because it suits and is made by that niche, copy-pasted "solutions" and monkey-ing others, just as the latest versions of PHP try to monkey other language and framework thinking, shows a profound character of its community, monkey-patches thrown together to look like some thought was put into it.

It is not the language of the future, its not where inventions happen.

Its still the same old to its core, pieces cobbled together to look like something it isnt, trying to hide the inconsistencies in its core.

</comment><comment><USER63> Nothing in that article fixes the issues that make PHP unpalatable to me. They are all new features added to the current broken set. Even if they are new and shiny they don't make the rest of the language suddenly better.

Which is really kind of the problem with PHP. All of that broken stuff was allowed to be broken for so long that it's effectively impossible to fix it. All you can do is layer on more features.</comment>


New course on building APIs with MongoDB and Python launched - <AUTHOR> http://training.talkpython.fm/courses/explore_eve/eve-building-restful-mongodb-backed-apis-course <comment><USER2> Eve is a great Python module</comment>


FastMail's servers are in the US – what this means for you - <AUTHOR> http://blog.fastmail.fm/2013/10/07/fastmails-servers-are-in-the-us-what-this-means-for-you/ <comment><USER2> > There are of course other avenues available to obtain your data. Our > colocation providers could be compelled to give physical access to our > servers. Network capturing devices could be installed. And in the worst case > an attacker could simply force their way into the datacentre and physically > remove our servers.

> These are not things we can protect against directly but again, we can make > it extremely difficult for these things to occur by using strong encryption > and careful systems monitoring. Were anything like this ever to happen we > would be talking about it very publically. Such an action would not remain > secret for long.

> Ultimately though, our opinion is that these kinds of attacks are no > different to any other hacking attempt. We can and will do everything in our > power to make getting unauthorised access to your data as difficult and > expensive as possible, but no online service provider can guarantee that it > will never happen.

This kind of frank disclosure should be highly rewarded. I provided similar frank disclosure text (elsewhere) only to have it whitewashed.

When everyone is underplaying the real limitations it's impossible for people to choose alternative tradeoffs— "Why should I use this slightly harder to use crypto thing when foo is already secure?"— because the risks have been misrepresented. Underplaying the limitations also removes the incentives to invent better protection— "Doesn't foo already have perfect security?".

<comment><USER3> "This kind of frank disclosure should be highly rewarded."

With all due, Im sorry but, no.

Had it come before the Snowden leaks, absolutely. But it didn't.

After the event, facing a danger of customer loss or loss of confidence, it can only be seen as too late and defensive move. All these companies must have known something about these risks, yet remained in a passive conspiracy of silence. Not one stood up until Snowden did. By then, too damn late.

<comment><USER4> Before the Snowden leaks Fastmail was owned by Opera, it has since been bought by Fastmail staff.

[http://blog.fastmail.fm/2013/09/25/exciting-news-fastmail- st...](http://blog.fastmail.fm/2013/09/25/exciting-news-fastmail-staff- purchase-the-business-from-opera/)

</comment></comment></comment><comment><USER5> > Australia does not have any equivalent to the US National Security Letter, > so we cannot be forced to do something without being allowed to disclose it.

This is not true. The Australian Crime Commission has some of the most extensive secret coercive powers in the Western world.

[http://www.austlii.edu.au/au/legis/cth/consol_act/acca200228...](http://www.austlii.edu.au/au/legis/cth/consol_act/acca2002289/s29b.html)

I would suggest that either:

a) Fastmail is aware of this and is covertly spreading the word that it might be compromised; or

b) Fastmail needs better lawyers.

<comment><USER6> I would argue that section 29 is very narrow in its scope, and allows for disclosure once an investigation is completed, and allows for disclosure to an attorney, whereas my understanding of an NSL is that it can order pretty much anything it wants without limitation. That seems quite different to me.

But then, I'm not lawyer. You're probably not either. Which is why I keep telling people to get their own legal advice if they're concerned about it.

<comment><USER5> Actually I am a lawyer. In the past I have even advised clients who received ACC notices (they are more common than most people would think).

Needless to say I was staggered at the scope of the powers granted. Forget about transparency, justice and the rule of law. If you receive one of these you _can_ be compelled to give evidence or documents in secret, without judicial oversight or public scrutiny.

<comment><USER6> I just checked upstairs. The advice we have is roughly:

\- ACC has judicial oversight

\- its unclear how this interacts with the Telecommunications (Intercept and Access) Act

With my boss throwing in:

\- law is a giant mess

\- until you have two extremely well-funded parties disagreeing vehemently about the interpretation, you'll never get a final answer

We're still happy with our publicly-stated position. You might disagree, and I'm not really in a position to argue with you. Its my corporate masters with their necks on the line, and they seem relaxed about it. That's good enough for me :)

<comment><USER7> Either way, it makes your service completely vulnerable to the government's interpretation of the law. If they force you to disclose your customers' data in secret tomorrow, or face jail time, I have no doubts what your choice will be.

I'm not calling you a liar, btw, I just think you're naive/oblivious, and considering you just now discovered what ACC is and had to check with your lawyer (who isn't even sure how it interacts with other laws), I wouldn't use your service to send any critical information. Ever.

<comment><USER6> > If they force you to disclose your customers' data in secret tomorrow, or > face jail time, I have no doubts what your choice will be.

We have no doubts either. The privacy policy clearly states we will give your data to the Australian authorities if supplied with the proper supporting documentation.

I didn't just find out about the ACC, though I wasn't aware of the details. But I'm not a lawyer, just a sysadmin, so I don't need to be. The "its not clear" bit is simply that there are two laws that appear to be in contradiction with each other. Its never been tested in court. And thus, its not clear. But we have confidence that what our position is legally supportable or we wouldn't be here.

<comment><USER8> Laws that appear to be in contradiction with each other, never tested in court -- so, yeah, quite like the US legal situation, right?

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Hi, FastMail employee and author of (most of) that blog post here.

Just so we're clear, the point of this post was not that we don't think the rules don't apply to us. Instead we're trying to make it clear where position on these things are. The topic of this thread is a sensationalist sound-bite, nothing more.

I'm not going to go over the points again here because I'm pretty sure we said it all in the post (but ask questions if you like, I'll be here all week!).

The most important point to take away from this post is that your privacy is your responsibility. We're trying to provide you with as much information as we can to help you determine your own exposure, and to let you know what we will work to protect and where we can't help. Its up to you to determine if our service is right for you. No tricks, and no hard feelings if you'd rather take your business somewhere else!

<comment><USER9> I may have missed this elsewhere, but why are you're severs in the US at all?

<comment><USER6> [https://news.ycombinator.com/item?id=6506626](https://news.ycombinator.com/item?id=6506626)

</comment></comment></comment><comment><USER10> Note the obvious caveat though:

"There are of course other avenues available to obtain your data. Our colocation providers could be compelled to give physical access to our servers. Network capturing devices could be installed. And in the worst case an attacker could simply force their way into the datacentre and physically remove our servers."

As the colocation providers are based in the U.S., they would be subject to the National Security Letters. FastMail claims this is no different from any other hacking attempt. But in a normal hacking attempt, colocation providers would be free to explain to FastMail the extent of any hacking on their end. Moreover, hackers typically do not have physical access to any data. Even with encryption, physical access opens up a lot of attack vectors that most sysadmins don't anticipate.

<comment><USER11> If they mount webcams and other sensors inside the cabinet, they could detect unexplained access to their servers. Not sure what it'd really accomplish. The colo provider would either say "tech mistakenly opened that cabinet" or "no comment". The only real defense is to assume any such access is a breach and have servers immediately overwrite FDE keys in RAM and power off - and if they were that committed, they wouldn't host in the US in the first place.

<comment><USER12> There is some historical precedent for such methods. I believe one popular CDN (possibly Akamai?) has its nodes set up with sensors of some variety to discard sensitive data if the hardware is exposed to light.

<comment><USER13> Dell (and possibly others) servers have chassis intrusion sensors that you can trap in software, and do with as you please.

<comment><USER12> This goes beyond chassis intrusion, though - the servers are set up to freak out if anyone even opens the cage to _look_ at them.

<comment><USER13> Yeah, that is just bar room banter between nerds. I've stood next to unprotected racks of Akamai servers and nothing happened.

Nobody really builds systems where an HVAC engineer walking into your cage to move a cooling tile will cause an outage, they just love to talk about how they would build them.

</comment></comment></comment></comment></comment></comment><comment><USER14> The personal location of the operators is probably the #1 most important security risk; location of customers, location of servers, and country of incorporation are also important.

It's much easier to compel operators to do something (through legal threats or potentially physical threats) than it is to do any active modifications to a complex system, undetectably. Passive ubiquitous monitoring is a concern because it's passive and thus hard to detect -- it's highly unlikely TAO can go after a large number of well-defended systems without getting caught. Obviously they'd be likely to hide their actions behind HACKED BY CHINESEEEE or something, but even then, it's relatively rare to have a complete penetration of a large site in a way which isn't end-user affecting, and rarer still for the site not to publicize it.

That said, if I wanted to compromise Fastmail, I'd either compromise a staffer or some of their administrative systems to impersonate staff.

</comment><comment><USER15> The US government will just take their server. They don't care if you go out of business.

Look at what they did to megaupload.com.

<comment><USER16> This is the same megaupload where FBI agents took part in a raid on a house in a non-US country?

[http://www.listener.co.nz/commentary/the-internaut/kim- dotco...](http://www.listener.co.nz/commentary/the-internaut/kim-dotcom- megaupload-new-zealand-timeline/)

As I said in a response on our forum, if the stakes are high enough, no datacentre in the world is safe.

Bruce Schneier recommends protecting against terrorist attacks by improving emergency response capabilities - with the side benefit that your measures also help against natural disasters:

[https://www.schneier.com/essay-292.html](https://www.schneier.com/essay-292.html)

(edit: that's not a great version of his point actually, [https://www.schneier.com/blog/archives/2005/09/katrina_and_s...](https://www.schneier.com/blog/archives/2005/09/katrina_and_sec.html) is more on point)

Similarly, our main focus for security is protecting against all forms of attackers, including common theft or misplacement of our servers. We consider that to be more valuable for the overall security of our users (including security against denial of service) than fighting an impossible fight.

FACT: if the three letter agencies in the USA want your data desperately enough, they will get it. With FastMail, they have a legal way to obtain it which is quite a lot of effort, but (hopefully) less expensive to them than taking our servers offline.

What they can't do, by Australian law, is require our cooperation in blanket surveillance on all our users.

<comment><USER17> "As I said in a response on our forum, if the stakes are high enough, no datacentre in the world is safe."

The stakes being relevant to US that is.

</comment></comment></comment><comment><USER16> Hello inflammatory headline.

That's a very small part of a lot of what we have to say, most of which is:

* we can't be compelled (under current laws) to install blanket monitoring on our users

* we can't be compelled to keep quiet about penetration that we notice

* there are always risks, including the risk that any random group knows unpublished security flaws in the systems that we use

We have written some things about techniques we use to reduce those risks (physically separate internal network rather than VLANS on a single router for example) - these help protect against both government AND non-government threats. But we can't make those risks go away entirely.

What we're saying is - the physical presence in the USA only changes one low- probability/high-visibility threat, which is direct tampering with our servers.

Regardless of the physical location of servers, we would still comply with legally valid requests made through the Australian Government.

It is our belief and hope that this process is difficult enough to mean that US agencies only ask for data when they have good cause rather than "fishing" \- but still easier than taking our servers and shutting us down, with all the fallout that would cause.

</comment><comment><USER18> I found this article brutally honest. What they are saying is that (1) NSA snooping is more expensive for the NSA as they can't engage in blanket surveillance on all of their users, while keeping them silent, but on the other hand (2) you can't expect and shouldn't assume privacy, because if the NSA wants to listen on your traffic, they will.

This in combination with FastMail being acquired by its former employees, coupled with their investment in CardDAV and CalDAV, makes me really excited about them. I was actually looking for a good replacement to Google Apps and FastMail might be it. It's still a little expensive though, compared to Google Apps, I hope they'll bring those prices down just a little.

<comment><USER19> I am more than willing to give FastMail twenty USD per year, so it is not expensive in that regard, but it is expense for what you get. 1GB of space? Give me a break. All of the tiers need to shift down a notch while keeping the price the same. $20 for 10 GB would be reasonable.

<comment><USER18> Well, that's what I meant. I pay something like $50 / user account yearly in Google Apps and I get 30 GB of space, plus Contacts, Calendar, Google Hangouts, Drive and all the other goodies. Paying $60 per year for email with 15 GB of storage seems kind of expensive.

</comment></comment></comment><comment> workhere-io There's one question they haven't answered: Why do they even need to have their servers in the US? Their blog post admits that there's a big chance that the US is spying on their customers. Given the fact that FastMail is a Norwegian/Australian company, why don't they just move their servers to e.g. Norway?

I realize that even if the servers were in Norway, an email from a FastMail user to a gmail.com account would still be read by the NSA (because it would pass through American servers), but email sent from FastMail to other email hosts in relatively safe countries would not be read by the NSA.

<comment><USER20> We're no longer Norwegian :)

[http://blog.fastmail.fm/2013/09/25/exciting-news-fastmail- st...](http://blog.fastmail.fm/2013/09/25/exciting-news-fastmail-staff- purchase-the-business-from-opera/)

<comment> workhere-io Alright, but the point still remains: You could theoretically place your servers anywhere in the world, so why choose the US?

<comment><USER20> Like what Bron mentioned above:

'Which comes back to the point I've been trying to make all along here. In the most serious extreme, nowhere in the world is "safe"'

Do you have any suggestions for countries that have excellent data connectivity, would successfully resist pressure from US/UK/X authorities to hand over our servers, and at the same time would not themselves want access to?

<comment> workhere-io Norway, Iceland and Switzerland come to mind.

As for whether or not they want access to data: There's nothing wrong with governments accessing data if there's a court order in place and their request is part of an investigation. It's the automatic surveillance of _everyone_ that NSA does that's a problem, and it's certainly not all countries that do that.

 _In the most serious extreme, nowhere in the world is "safe"_

Sure, but there are _levels_ of safety, and the US has turned out to have a low degree of safety for a Western country. The fact that you probably can't find a perfect country shouldn't be an excuse to pick a notoriously unsafe one.

<comment><USER20> We're already in Iceland - from [http://blog.fastmail.fm/2012/07/03/a-story- of-leaping-second...](http://blog.fastmail.fm/2012/07/03/a-story-of-leaping- seconds/)

"We have a complete live-spare datacentre in Iceland. Eventually it will be a fully operational centre in its own right, but for now it's running almost 100% in replica mode."

I'm not so sure about the safe-haveness of Switzerland these days. They already caved to the US, giving them access to banking info (what they're famous for... which leaves me wondering what Switzerland got in return):

      http://uk.reuters.com/article/2013/08/28/uk-switzerland-usa-tax-idUKBRE97R0CY20130828

<comment> workhere-io _We have a complete live-spare datacentre in Iceland. Eventually it will be a fully operational centre in its own right_

Let me know when that happens and I'll gladly sign up for your service :)

 _I 'm not so sure about the safe-haveness of Switzerland these days. They already caved to the US, giving them access to banking info (what they're famous for... which leaves me wondering what Switzerland got in return):_

I don't see how bank secrets have anything to do with Internet surveillance. There's a general tendency now both in the US and the EU to pressure tax havens such as Switzerland, Andorra, the Bahamas, etc. to give up their bank secrets so that corporations and rich individuals can't hide their income and avoid paying taxes. That seems fair enough, and I don't see a direct link between that and Internet surveillance.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> The persuasive part of this is disclosure. It's a promise to be open about any breaches, plus an observation that the US lacks the legal clout to stop the promise from being kept.

</comment><comment><USER22> I know that my word doesn't mean much, but I have had the chance to talk to several of the guys working at Fastmail during their years at Opera Software. They are -serious- about mail and they are -serious- about privacy.

Next time I'm out shopping for email services, I will give my moeny to them! (And, to give something back for all the Tim Tams brongondwana brought with him to Norway ever time he was on a visit ;) )

<comment><USER6> If you want to just send timtams, that would be fine too. We seem to have run out of them in the office...

<comment><USER16> I'll get you timtams if you run the fire escape with us...

<comment><USER6> I'm afraid that if get fit and stuff I won't want them anymore! :'(

<comment><USER16> Hasn't stopped me.

<comment><USER23> Stick to IRC for the internal chats guys.

Wait, I meant email... ;)

</comment></comment></comment></comment></comment></comment><comment><USER24> So they are saying that they can never get a NSL to turn over information, but where are these servers? Who has the keys to the door of the server room?

So maybe they don't get the NSL, but the people/group/company that is handling the servers might. This seems disingenuous. I could be wrong, but it feels like they are making claims that will dupe people into their service because they feel safe.

<comment><USER25> > So maybe they don't get the NSL, but the people/group/company that is > handling the servers might. This seems disingenuous.

well they do say explicitly that, near the bottom. Hardly disingenuous.

</comment></comment><comment><USER11> The only real benefit I see here is that your IP won't be easily revealed. That is, given a fastmail account, the e.g. FBI cannot quickly get your login IP, like they can with e.g. Outlook or Gmail. So, for just low-level anti- surveillance, SSL to fastmail might suffice instead of using Tor with Gmail.

Unless you're using PGP or S/MIME, SMTP is still most often unencrypted.

<comment><USER14> I think the assumption is that FBI has to obey the law to produce evidence for prosecutions. NSA doesn't, particularly vs. "foreign".

</comment></comment><comment><USER26> Since the Silk Road bust we know the US LE is able to convince or force colocation providers to provide them with an image of a server. After that, pretty much any communication can be considered open to the NSA. I am not surprised that he does not clearly mentions this.

So FM should move their servers out of the US even if that's inconvenient.

<comment><USER6> Actually we did clearly mention it:

      "Our colocation providers could be compelled to give physical access to our servers."

But in the very next paragraph:

        "These are not things we can protect against directly but again, we can make it extremely difficult for these things to occur by using strong encryption and careful systems monitoring. Were anything like this ever to happen we would be talking about it very publically. Such an action would not remain secret for long."

Its not hard for a skilled sysadmin to take an image of a running server. Its extremely difficult to do it without administrative access to the machine AND to do it without anyone noticing.

<comment><USER27> You could move the servers to a country with more respect for rule of law. That would be awesome!

</comment></comment></comment><comment><USER28> > our primary servers are located in the US

Why would you do that, especially when you're not even a US company?

<comment><USER6> Because most of our customers are in the US. If your goal is to provide the fastest service around, it helps to put your servers near your users.

<comment><USER28> You're implying that you would make less money by trading in your US location for more security. That means that you believe not enough users care enough about their privacy to accept that (really light) trade-off.

<comment><USER16> It might also mean that many of our users believe in the same tradeoff that we do - that we're not overreacting to one low probability/high visibility risk by throwing out the incredibly good reliability we've had for years to shut everything down, ship it to a location with unknown reliability and spin it all back up again - complete with new IP addresses and all the headache that would cause tons of customers who have hard coded things on their own domains (annoying but true - recycling IPs is hard)

There are tons of downsides to shutting down everything that's working well in a knee-jerk reaction to one possible risk - never mind that the government of whatever country we choose could very well cooperate with the same agencies we're running from - or they could just corrupt an employee of the datacentre we're in - or...

So maybe if you're going to put words into our mouth you could put ones about how much we care about our users and our reliability that we don't jump on unproven setups just because of a single (unchanged, just more public) risk.

<comment><USER29> You're not representing your company very well. If you're going to be mean, you'd better be right. But in the scenario you describe, the solution is to move incrementally, one server at a time, not "shut everything down, ship it, then reboot everything simultaneously."

FYI you have about 1.5 hours to edit your post. You may want to do that, because otherwise it will probably scare off most informed potential customers who read it.

<comment><USER16> Do you have a realistic idea of how long that would take, and what the risks and costs involved are? How would we "move" the servers, without a significantly higher risk of the data being leaked? Assuming Europe, that's an 8 hour flight at the least.

I'm guessing people are assuming Europe as the bastion of all things good here. Certainly it's more affordable for hosting than Australia, and more reliably connected than anywhere else.

A more realistic scenario, if we had the budget for it, would be to buy a duplicate set of hardware, install it in the theoretical new location, duplicate all the data, grandfather everything running at NYI.

This would be a process that would take months or years of real time as well, plus quite a lot of admin time. Just duplicating all the email, well - I did it recently, I carried an almost full set of backups on encrypted hard disks from New York to Australia (the key was only ever in tmpfs on the host in New York, copied in over ssh inside a VPN link, and all copies nuked and the server rebooted and reinstalled before I left New York) Even filling those disks at the maximum IO rate we could sustain took over a week - and unpacking it at the other end would take as long again.

All this for theoretical security against one of very many risks we face. It is my considered opinion that we can get better return on our security investment (both time and money) in other ways than scrambling to get everything out of the USA.

And "emails being read by the US Government" is only one of very many security threats. We could make our users' emails VERY secure by putting all our servers in the shredder - it might reduce uptime and recoverability of data somewhat...

... so I'm hoping most informed potential customers understand that there are other risks in the world, and we balance our defenses amongst the various risks.

Throwing away everything that's good about our New York hosting in exchange for maybe being more secure against one particular risk is not a decision to make lightly, your assertions nonwithstanding.

<comment><USER30> You could also just create a second, completely separate setup in Europe running on a new domain. People who don't care about their @fastmail.fm domain or those use their own domain can move to the European setup.

<comment><USER16> Yes, we could. It's certainly an idea that's on our radar.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> As Australia is a member of the five eyes group, I do not see any added protection from FM being incorporated there rather than in the USA.

This is why I use a email service in Norway (runbox.com), which, as far as I know, is not sharing information by default.

<comment><USER16> The legal situation in Norway is... in flux at the moment. The Snowden revelations might stop information sharing from coming in, but Norway is looking like leapfrogging Australia pretty much with data retention (along with much of Europe):

[http://theforeigner.no/pages/news/updated-parliament- passes-...](http://theforeigner.no/pages/news/updated-parliament-passes-data- retention-directive/)

Norway isn't some magical safe haven from legal data requests. We receive law enforcement requests through the Norwegian system for mail.opera.com users (which, despite running on the same infrastructure, is operated under Norwegian law, not Australian - isn't life complex)

[http://en.wikipedia.org/wiki/Telecommunications_data_retenti...](http://en.wikipedia.org/wiki/Telecommunications_data_retention) tells a few interesting stories.

Australian law may indeed change, and we'll be compelled to update our policies to match. So far, we've avoided it.

[http://www.smh.com.au/technology/technology- news/government-...](http://www.smh.com.au/technology/technology- news/government-shelves-controversial-data-retention- scheme-20130624-2oskq.html)

</comment></comment><comment><USER32> They don't need to seize the server. SMTP is plaintext and on a well known port number. I'm sure the NSA have a record of every email sent through the US in the last few years.

<comment><USER33> It is possible to encrypt SMTP connections with standard SSL/TLS technology.

FastMail has been using opportunistic encryption on their incoming and outgoing SMTP servers for years. If you send an email to another service that does opportunistic encryption, and if both the sender and recipient uses SSL to access their mailboxes (as FastMail requires), the email will never be transmitted in plain text over the Internet.

<comment><USER34> The problem with such opportunistic encryption, is that you could insert a man in the middle which basically intercepts the traffic and modifies the handshake to exclude the STARTTLS extension.

With opportunistic SMTP encryption this will cause things to proceed in plain text. The sinister thing about this is that e-mails still flow, so it still works.

<comment><USER6> There's a solution for this. Its called DANE. See [http://tools.ietf.org/html/draft-ietf-dane- smtp](http://tools.ietf.org/html/draft-ietf-dane-smtp)

We're currently investigating it.

<comment><USER35> I don't suppose you got any numbers easily at hand about how much of your port 25 traffic negotiates a TLS encrypted connection?

<comment><USER6> A very naive estimate based on one day of logs from one server says over 75% of our incoming port 25 connections are encrypted. Although that says nothing about the quality of the cipher in use and the type of messages that come through, its still significantly higher than I would have expected.

I can see I'll be spending some time on this in the next few days!

<comment><USER35> Thanks for that. They're useful numbers for me, because I've got this plan…

My current side-project involves a RaspberryPi (sitting in my loungeroom on my home ADSL connection), iRedMail, full disk encryption, a handful of inexpensive VPS providers with APIs that allow automated provisioning (DigitalOcean, NineFold, and Hetzner – to spread out the jurisdictions) – with the RasPi opening a reverse SSH tunnel for ports 25 and 465. Add in a DNS provider with a useable API so the 'Pi can spin up and shut down VPSes itself and update MX records to suit, and VPS images configured to not log anything mail-related, and I think I've gone as far as I can to secure my end of all my email. Having physical control of the hardware/storage that my email relies on won't protect me against NSA level targeted-at-me snooping, or even local law enforcement with sufficient "probable cause" to get a judge to sign a search warrant, but at least I'll _know_ if someone grabs my server hardware. (Hmmm, I wonder if there's some NSL-type coercion that could be used against my partner to force her to let someone take/image my 'Pi while I'm not home, and not be allowed to tell me?)

Possible over-paranoid ideas include refusing port 25 smtp connections that wont negotiate a secured connection in response to a STARTLLS command, and possibly blacklisting mail originating from any of the 8 known PRISM collaborators. I like the _idea_ of ensuring none of my mail arrives from known-intercepted sources, but reality dictates otherwise since way too many of the people I really do want to communicate with are exclusively using gmail/yahoo for email (or worse still, have migrated largely to Facebook messaging instead of email).

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> As far as I know, Australian law is common law and would allow a judge to seal a warrant. So, fastmail's asertion that there is nothing like an NSL where they couldn't disclose a search is incorrect. I'm sure it is just lack of awareness, rather than intentional deception.

(Ianal, ianaa, but I am pretty sure I am correct on this point.)

</comment><comment><USER36> While some describe this as "frank", I think to have that quality TFA would need to specify where the decryption keys are stored. Are they in the USA colo's too? (I realize I could probably figure this out myself if I could be arsed to do so, but why not just tell us?)

</comment><comment><USER37> I've been having a discussion with a fastmail staff member about surveillance and fastmail. You can see the discussion here:

[https://www.fastmail.fm/html/?MSignal=TZ-**378397*97ae93f3](https://www.fastmail.fm/html/?MSignal=TZ-**378397*97ae93f3)

</comment><comment><USER38> FastMail's servers on on the internet, and so you're fucked.

Just sayin'.

</comment><comment><USER39> Transparency takes precedence over everything else in this post, aka the thing you haven't seen US companies doing at all.

Hmmmmmmmmmmmmmmmmmm.

</comment><comment><USER40> Or the US could just go to the Datacenter and force them to give access.

</comment><comment><USER41> This makes me very happy to continue being a Fastmail customer.

</comment><comment><USER42> Thank you, Fastmail. This is why I pay for you.

<comment><USER43> Despite that they just stated that your data will be owned by the US government in a raid on the US-based fastmail servers? And with no apparent way for US-based users to avoid that?

<comment><USER44> In all fairness, how are they supposed to combat that without moving their server location?

</comment></comment></comment><comment><USER45> Now swear in blood you weren't under any kind of nondisclosure order when you wrote that.

</comment><comment><USER46> This is a joke right? How much were they paid by the NSA to write this post?

<comment><USER47> Ffs, why even bother writing junk like this at all?

</comment></comment><comment><USER48> If I was going to set up a honeypot for evil-doers/dissidents, this is the message I would spread.

<comment><USER6> If I was an evil-doer/dissident I wouldn't be trusting my life to the collective wisdom of the internet ;)</comment></comment>


A new report reveals Obama misled the public about a quiet giveaway to Iran - <AUTHOR> http://www.vox.com/world/2017/4/24/15407078/obama-iran-prison-swap <comment><USER2> Interfering in DoJ law enforcement, trading a bunch of Iranian spies and money for some people caught up in the Iranian police state, and then lying about it. For what? An unverifiable deal that blesses Iran as the hegemon of the middle east?

That's just the icing on the echo chamber cake that the Obama white house used to sell the deal

[http://freebeacon.com/national-security/wh-partner-asked- sor...](http://freebeacon.com/national-security/wh-partner-asked-soros-to- fund-echo-chamber/)

[http://www.foxnews.com/politics/2016/05/06/obama-aide- rhodes...](http://www.foxnews.com/politics/2016/05/06/obama-aide-rhodes- claims-built-echo-chamber-to-sell-iran-deal.html)

According to Ben Rhodes:

"Most of the outlets are reporting on world events from Washington. The average reporter we talk to is 27 years old, and their only reporting experience consists of being around political campaigns. That's a sea change. They literally know nothing," he said.

</comment><comment><USER3>
      What's important to note here is that Iran's progress
      developing those centrifuges — the ones Jamili was allegedly
      helping procure parts for — is part of what prompted the
      Obama administration to try to negotiate the nuclear deal in
      the first place. In other words, its prisoner swap
      undermined its own nonproliferation objectives.

How does inking a deal which verifiably stopped the uranium refinement program undermine the objective of stopping the uranium refinement program? If the swap was part of the larger quid pro quo and wasn't unpalatable, so be it. And so what if one of the guys was procuring parts for IEDs? It's despicable, but given that the alternative was initiating yet another war in the Middle East with more American casualties, I think we could hold our nose. I think I'll give Obama a pass for spinning the moral culpability of the prisoners.

      A number of them were involved in helping Iran procure
      lethal technology for its military

_Lethal_ military technology? Is there any other kind? This author is really struggling to create controversy here.

How about all these pundits put their collective heads together and try to figure a way out of the North Korean situation. That's a real dilemma, with a high likelihood of hundreds of thousands of deaths, including many thousands of deaths of American soldiers. If only solving it were as easy as the Iranian situation.

</comment><comment><USER4> There's actually never been any proof provided that Iran had a nuclear weapons program. The evidence available says that Iran _might_ have had a weapons program before 2003. This is according to the IAEA.

The US National Intelligence Estimate concluded that the Iranian nuclear weapon's program ended in 2003:

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

So when the article says the prisoner was helping "Iran's nuclear weapon's program", that's a provocative and unsubstantiated allegation.</comment>


AppEngine is hiring - <AUTHOR> http://googleappengine.blogspot.com/2011/07/wanted-app-engineers.html

<comment><USER2> By using a totally in-house host of backend servers, db, mapr, language bindings, apis, and what not...

Q: Will it get increasingly harder to roll new technologies? (I point to how long it has taken and still on going to get Django, Python, and etc running).

Q: Is the Appengine platform being used for anything other than small internal products?

I feel like if Google/AppEngine gave us a more agnostic sandboxed (apis) VMs ala Heroku/DotCloud/BlahBlah/ or even raw (yet limited) boxes such as Ec2 or Joyent and just let us wire it up to 'BigTable' then it would be a win-win. Leveraging existing tech, with in-house DB (BigTable) instead of re-writing the __entire__ stack to the point where apps are not 'compatible'. Yet even then, I see that a full SQL implementation is in the works...

There just has to be a better way...

<comment><USER3> From what I've seen, they haven't been able to even manage the technologies that they've got now. Python on appengine is still at 2.5, something I voted to get updated (to at least 2.6) back in 2008.

[http://code.google.com/p/googleappengine/issues/detail?id=75...](http://code.google.com/p/googleappengine/issues/detail?id=757)

776 people have starred the issue (so far). It's now 3 years later (python 2.6 was released 10/1/2008) with no sign of upgrade.

Hopefully some of this new team will be used to support what they've already launched.

<comment><USER4> 2.7 is on the roadmap as well as SSL for custom domains.

<http://code.google.com/appengine/docs/roadmap.html>

</comment></comment></comment><comment><USER5> If every one on the app engine team is in the picture, it is actually a pretty small team, given the size of Google and the impact of the project.

</comment><comment><USER6> i wish google favored telecommuters more, i'd kill to work on this team!

</comment><comment><USER7> I'm worried with the emphasis on Java over Python (Java is mentioned a good couple times more than Python on the job posting).

OTOH, this could mean they acknowledge the Java version needs improvements.

<comment><USER8> Why worry about a specific language? Just learn both.

<comment><USER7> I already know Java. I just prefer Python ;-)</comment></comment></comment>


AP exams will be held online this year - <AUTHOR> https://www.campusreform.org/?ID=14582 <comment><USER2> College Board should have punted the tests back to the fall. The tests are missing quite a bit of content[0], for example, Calculus BC has little to no more required content than Calculus AB (no parametrics/polars, nothing much with series other than identification). Since the kids will most likely have to retake these classes once they get into college due to the content deficit, I don't really see the point of it this year.

If they moved them back to fall / late summer, kids would've had more time to prepare, and the full tests could've been administered so the credits would've been given fairly. I assume the reason they aren't doing this is because it would be impossible to schedule a traditional AP reading for the teachers to grade the tests, but they could do it remotely as they will be doing with this (schedule readings on the weekends to be done remotely? they are only a few days long anyway).

With that being said, if I was still in High School, i'd probably be pleading with my AP coordinator to let me take more tests because of the advantage... but I digress (and I doubt college board would have let me anyway). darn it. one year later and no physics in college.

0: [https://apcentral.collegeboard.org/about-ap/news- changes/cor...](https://apcentral.collegeboard.org/about-ap/news- changes/coronavirus-update)

<comment><USER3> We're going to have a full year of students who essentially get to take a mulligan, they're going to be able to cheat on every test, postpone tests, get extra study time etc.

It's about time we realize that education was never about merit in the first place.

<comment><USER4> While cheating may happen, it's not like this will result in a whole class of college graduates being unqualified. You aren't given an engineering degree just because you got a 5 on the BC calc exam. You still have pass your college classes.

The kids that couldn't pass without cheating will fail their coursework (some will cheat all the way through college, but that has always happened). The kids that could have passed without cheating will have the same outcome as if they didn't cheat, except they will have lost some integrity.

So there might be a few extra graduates that make it through because they were able to cheat an online exam in high school, but it's not going to be a huge change.

<comment><USER5> There are only so many seats though, so some kids will get cheated out of going to their school of choice (or going at all) because of some cheaters.

</comment></comment></comment></comment><comment><USER6> If there are no in-person classes in many places I can't imagine all of these courses are going to work in the first place. When I was in high school, I had the misfortune of taking AP Chemistry during a year when the building that had chemistry labs was damaged in a storm and closed. No one passed the test that year.

</comment><comment><USER7> A better source is the College Board's own announcement [0].

[0]: [https://apcentral.collegeboard.org/about-ap/news- changes/cor...](https://apcentral.collegeboard.org/about-ap/news- changes/coronavirus-update)

</comment><comment><USER8> How in the world do they plan to be able to stop a student taking the test on their PC from Googling the answers on their phone, or vice versa? Or asking a friend instead of Google?

<comment><USER9> I like how benign you think this is. This is roomy cheating. Advanced cheating is paying your AP tutor to be in the room with you.</comment></comment>


Lighthouse: Decentralized Kickstarter - <AUTHOR> http://blog.vinumeris.com/2014/05/17/lighthouse/

<comment><USER2> When you decentralise something, you tend to take away moderation and curation, which keep the general quality of offerings above a certain bar. I'd be curious what the author of this project suggests in this regard, or what measures he has put in place to mitigate the degradation of quality that can come from not having any kind of moderation or curation.

<comment><USER3> This is true to a certain extent... but those moderation and curation features can still be added on at a higher level. In fact, opening the storefront itself to competition could result in a better curation and moderation experience for the user.

<comment><USER4> So just like bittorrent, which is decentralized but has many (centralized) trackers of varying quality.

<comment><USER3> Yes, thank you for articulating that better than I could.

</comment></comment></comment></comment><comment><USER5> This is what I find interesting in bitcoin :)

It seems to me that instead of having to manually sync files or setup a server, Lighthouse itself could include a small BitTorrent library, and then you could just share a magnet link (with its own protocol handler, of course, e.g. "lighthouse:") and have the software fetch the contract and pledge files from other peers.

In fact, using the protocols which are behind Tribler[1], you could even browse and search for projects in a decentralized way, and probably even allow the project creator to automatically fetch the pledge files.

Fun stuff!

[1] [http://www.tribler.org/](http://www.tribler.org/)

<comment><USER6> I think "BitTorrent Sync" already provides a shared folder that works this way, does it not?

I guess it could be integrated into the app, but often if you can share a link you can also just share a file. For the serverless case I guess pledgers and project owners will often not be online at the same time anyway.</comment></comment>


Actors, Green Threads and CSP on the JVM - <AUTHOR> http://boundary.com/blog/2014/09/03/no-you-cant-have-a-pony/ <comment><USER2> The argument seems to be that the actor model implementations on the JVM aren't all that fast and the language can't stop you from shooting yourself in the foot.

That's not really the issue as far as I'm concerned. Message-passing concurrency actually allows people be productive writing concurrent code that has a hope of working -- that is the main advantage. Occasionally things go wrong. Occasionally you need more performance and have to drop down to a lower level. But I can _easily_ write a web service running on the JVM that gets 1000 requests/s per CPU with a bit of message passing concurrency. That's the point.

Heck, I don't even like the actor model -- I much prefer CSP -- but I'd attack it for other reasons (like lack of type safety).

<comment><USER3> Right, and when you "drop down to a lower level" to get more performance, the entire house of cards comes crashing down with bugs that are extremely difficult to debug.

The issue isn't actor model on a virtual machine-- erlang runs on a VM-- the issue is that the actor model is insufficient. You need pretty much most of OTP to build reliable, stable, concurrent systems.

This is why goroutines, everything on the JVM, etc are not going to work.

The sad thing is, I think the primary reason people are not using Erlang is they are afraid of the syntax, but even that reason is obliterated by the existence of Elixir (an even better language on the erlang VM)

<comment><USER4> What do you mean by:

"This is why goroutines, everything on the JVM, etc are not going to work."

I've used Akka very successfully on the JVM for non-trivial clustered applications where performance is important, and I'm pretty sure the existence of most of google's infrastructure says that goroutines work at least a little bit.

Do you mean not work well? They won't gain traction?

<comment><USER5> For example, Go has no means of monitoring or linking to it's goroutines; without supervision trees the Erlang model for resiliency cannot be implemented.

</comment></comment></comment></comment><comment> village-idiot Let's break this down a bit. It's pretty clear to me that there are 3 reasons why you'd want to use CSP channels or actors.

1) Reliability. This is mostly going to be of the subscribing to other actors to make decisions when they die type. This is a complete replacement for try/catch, and probably isn't possible or desirable on the JVM due to mutability concerns. If you need and want this, Erlang is your bet.

2) Performance. This is probably the most common reason, and a true fiber system can hit this just fine on the JVM. So what if touching old code might cause degraded performance due to blocks, it's not unreasonable at all to say that high performance code will require some care. And if the fiber system warns you, the more the better. Quasar is your bet here.

3) Architectural niceness. Callbacks suck, and we all know it. CSP channels can be seen as a nicer way to structure the flow of a large asynchronous system. In this context I think core.async tends to be the best, because of it's support for transducers and Javascript support. Although Quasar/Pulsar would not be a bad second choice for this because they work outside of a go macro, assuming you only need them on the backend.

</comment><comment><USER6> > The primary advantages center around the ergonomics of concurrency.

That is how most "frameworks" or those that try to copy this aspect from Erlang see it. But the trick is in Erlang this actor pattern is used for fault-tolerance just as much. That was the goal right alongside concurrency initially. (The third one was priority of low latency responses, I believe).

That fault tolerance is harder to copy and that is why most libraries and frameworks give up and copy the "class object+thread+queue" and call it "We have a fast Erlang now".

The closest to get to something like Erlang fault tolerance wise is to use OS processes and IPC (via ZMQ), with some serialization. But it would be hard to run 2M of those on a reasonable machine.

Plus Erlang is not just the language (which is rather small and simple) but the whole set of helper libraries and tools. Including a distributed database, distributed application controllers. Support for rpc and so on. Supervisor patterns you can use etc.

</comment><comment><USER7> I can't help but wonder if the article of the author has seen Quasar: [http://docs.paralleluniverse.co/quasar/](http://docs.paralleluniverse.co/quasar/) It seems to be a concrete refutation of his claims of impossibility. Quasar successfully brings green threads to the jvm. It includes both channels as are now popularized by golang, as well as higher level patterns like actors. Despite the young nature of the framework, benchmarks show it comparing reasonably well with both golang and erlang. Quasar also provides libraries that step all the way up into the OTP realms of supervision trees (though I haven't myself used this, yet).

The article mentions bytecode weaving, but dismisses it with very wavery justifications. Bytecode manipulation tools are a successful part of the jvm ecosystem. Frankly, they're part of _why_ I consider the jvm ecosystem so successful: bytecode manipulation has allowed things like:

\- third party tree-shakers/minifiers and obfuscators (i.e. proguard)

\- cross compilers (i.e. robovm)

\- concurrency libraries that DO have real green threads and continuations (i.e. Kilim, Quasar, and others)

\- code coverage and complexity analysis tooling (i.e. jacoco)

\- scala

\- clojure

\- groovy

\- kotlin

\- [... more languages ...]

There are two critical points about the above:

\- All of these tools were built without direct cooperation with the compiler and core tool chain. That means experimentation and growth were possible from the community.

\- Everyone's tools play nice with each other! You can use Quasar as a library in Clojure and then feed that bytecode into Proguard for minification, and then add code coverage instrumentation, and then feed it into Robovm!

Given the wild success of bytecode and bytecode manipulators, I have no idea how the article can so whimsically poo-poo the entire field.

(Yes, I'm well aware Erlang has a VM that allows alternate languages as well. And yes, Elixer is pretty. OT, no, I won't be making investments of my time into Elixer, because I like strong compile-time type systems, and Elixer doesn't have that.)

It is true that even in the presence of a full greenthreading tool like Quasar, code can call legacy APIs that still block a full thread, but this is not sufficient cause to dismiss the possibilities. To quote back part of the article, blocking will always be an issue in any cooperatively multitasked environment: "There's no real way to limit what that code can do, unless it is explicitly disallowed from [...] looping." And yet I wouldn't claim Erlang fails to give me concurrency just because it still allows loops! Part of the compromise of cooperative multitasking is the very premise that in exchange for the higher performance possible from cooperative code, yes, poorly written code can suck up arbitrary amounts of CPU before yielding. If this were a practical concern, it would also be entirely possible for a bytecode instrumenting library to inject cooperative rescheduling points even into loops; and yet I have no real desire to see this feature.

Furthermore, I strongly object to the claim ForkJoin is "notorious for its overhead". All thread synchronization is notorious for its overhead. That's completely known to any programmer with experience in this area, and in no way unique to ForkJoin.

For an excellent, in-depth coverage of what exactly ForkJoin is and the problems it solves for you, see [https://www.youtube.com/watch?v=sq0MX3fHkro](https://www.youtube.com/watch?v=sq0MX3fHkro) . I highly recommend watching the entire thing despite its length, and even if you are not a JVM programmer -- even if you've been doing concurrent programmer for years, you will almost certainly walk away knowing significantly more about concurrent scheduling from the (relatively) high levels of memory fencing all the way down to CPU architecture choices and their impacts.

I'm not going to claim there are no issues with something like Quasar. In particular, I find that it _is_ harder to operate in an ecosystem where very few existing libraries understand what your application is trying to do with green threads. Mostly, this doesn't phase me if my application is calling out to other libraries, because I control the scheduling one step above them (just like I would in a plainer actor framework without green threads like Akka). The problem is more with "hollywood" style frameworks -- the "don't call me, I'll call you" type -- so far it feels like these are very hard to use when your application is using green threading, but the calling framework has no clue about it. Some sort of interfacing code is required and usually has thread handoffs of its own, which can be moderately unpleasant, and limits your scalability at that juncture. But this is a present-tense bummer, and can be solved by patching (or outright replacing) these hollywood frameworks, or simply avoiding frameworks of that kind altogether.

But in short, I still think it's a bit unreasonable to dismiss the existence of ponies.

<comment><USER8> Author of Quasar here and apparently the target of the criticism in the article. It's kind of hard to make out the main claim the author has, but let me respond to the few more specific claims:

1\. ForkJoin is not "notorious for its overhead". In fact, it is among the best implemented, best performing work stealing schedulers out there. Scheduling a task with ForkJoin takes a few nanos, and is almost as cheap as a plain method call. Don't take my word for it: go ahead and benchmark it.

2\. Like Go, Quasar doesn't constrain the running code from mutating shared state -- if you're using Quasar from Java, that is. But it's still just as useful as Go, and when used from Clojure, it's even more flexible than Erlang, and actually quite safe.

3\. My macbook isn't cruddy.

4\. The stuff possible with Quasar, like running a plain Java RESTful service on fibers to gain a 4x increase in server capacity -- without changing the code and without even starting to parallelize the business logic with actor/CSP -- speaks for itself.

5\. I'm not spreading FUD on threads -- you can watch my talk at JVMLS (linked in the article) to see my precise point: kernel threads cannot be used to model, one-to-one, domain concurrency, because the concurrency requirements of modern application (and the capabilities of modern hardware) exceed by several orders of magnitude the number of threads supported by the kernels. Fibers keep the (excellent) abstraction provided by threads as the unit of software concurrency, while making the implementation more suitable for modern soft- realtime workloads. When your average programmer can spawn up a (lightweight) thread without thinking about it -- say one for each request, and even many more, concurrency becomes a lot easier.

6\. The linked Paul Tyma slide are completely irrelevant. I've got nothing against doing kernel-thread-blocking IO. The problem becomes writing simple, yet scalable code to process incoming requests. Modern hardware can support over a million open TCP sockets, but not nearly as many active kernel threads. Asynchronous libraries give you the scalability but fail on the simplicity requirement; fiber-blocking IO gives you both the performance and the simplicity of blocking code.

7\. As to the "strawman benchmark" with "too many threads", the author is welcome to repeat the experiment using a thread pool with as few or as many treads as he'd like -- the result would be the same: switching kernel threads costs about 10-20us, while task-switching fibers costs 0.5us (and can be improved).

> few existing libraries understand what your application is trying to do with > green threads

That's exactly the purpose of the Comsat project, which integrates existing third-party libraries with Quasar fibers. You're right, integrating "inverted" frameworks does require more work, but so far Comsat integrates, servlets, JAX-RS services and Dropwizard.

[1]: [http://blog.paralleluniverse.co/2014/05/29/cascading- failure...](http://blog.paralleluniverse.co/2014/05/29/cascading-failures/)

<comment><USER9> A tangential question:

Does any of this benefit a desktop app? I realize that most of the green- thread interest lies in asyc i/o and i/o bound workloads. But can a desktop app with a couple of dozen threads (i/o + cpu mix loads) gain something from Quasar?

<comment><USER7> I'd say Yes.

A) Frankly, channels result in prettier, more maintainable code. I've seen enough questionable uses of LinkedBlockingQueue to last me a lifetime. Inability to so much as "close" a BlockingQueue in the face of multiple concurrent consumers is an unbelievable cramp -- it won't bother you until it does, but when it does, it's just a bellyflop-onto-concrete sort of sensation.

B) I'm even more pessimistic than Pron's sibling response about scalability of threads. A minecraft server with a even a few dozen concurrent players is starting to feel the limitations of naively scheduled threads, as an anecdote. Part of this comes down to the choices of concurrent data structures, how interaction with shared data strucutures is batch and the resolution of locks, the devil is in the details etc etc etc, but I'd venture that the abstractions with green threads and channels make good code a heck of a lot easier.

Truly trivial apps with one "compute" thread and one "UI" thread are unlikely to see serious performance gains. Similarly applications that have workloads that are highly parallel (say, somewhere around $num_cpus threads which exchange information only once every few hundred millions of cycles -- spitballing a bit, but for context I think the Doug Lea talk I linked in earlier ([https://www.youtube.com/watch?v=sq0MX3fHkro](https://www.youtube.com/watch?v=sq0MX3fHkro)) mentions thread unpark can take up to a million cycles in a worst-case scenario) are unlikely to see serious performance gains. So there are situations where green threading can't help you from a purely performance perspective, yes. But in practice, it's my observation that it's startling how quickly "simple" apps end up doing enough concurrent UI or network operations that naive threading starts getting unpleasant.

</comment></comment></comment></comment><comment><USER10> I use Akka Scala/Java JVM actor framework daily, and it manages to get by without bytecode weaving. The lack of type safety is irritating, though.

<comment><USER5> It's very easy to mess this up though - either by blocking the thread or by capturing a reference to the mutable state of the actor in a closure.

<comment><USER11> how often does it happen in practice?

</comment></comment></comment><comment><USER12> Very interesting article and analysis, although it would be nice if it explained what exactly a "Green Thread" is. From the article, I am guessing that a "Green Thread" is related to the lightweight low-level concurrency mechanism that he is referring to as the alternative to normal threads, but it is not exactly clear what that really means.

<comment><USER2> A green thread is a "lightweight" thread, meaning a thread that is managed by a user level process, not by the OS. This main advantage is you avoid OS thread context switch time, which is comparatively very large. The disadvantages are:

\- you have to balance load across true OS threads to take advantage of multiple CPUs. (You often pin an OS thread per CPU.)

\- if you make a call to a blocking OS function you have no way to pre-empt your lightweight thread.

HTH.

Update: "you have to balance load" \--> I mean the green thread library implementer. Users of a lightweight threading library typically don't concern themselves with this, though they might if performance becomes an issue.

<comment><USER3> Neither of those disadvantages exist in the erlang system, as the scheduler spreads processes across OS processes. I can't speak for "Actor Model" libraries, though.

<comment><USER13> Sure they do.

Erlang spreads processes across OS threads, like most other green-threading impls, and its not always great at it. (I don't know what you mean by "across OS processes." Processes on different Erlang VMs can communicate but the scheduler isn't going to move processes between them)

Calling into native code isn't an easy problem in Erlang either. NIF calls will block a scheduler thread, but the scheduler knows nothing about how long a NIF call is expected to take and will happily queue up processes to be run on a thread that is blocked inside a NIF call.

"Regular" erlang I/O is done by queueing up requests to be fulfilled by .. you guessed it, a pool of threads that spend most of their time sleeping in blocking i/o calls.

</comment></comment></comment></comment><comment><USER14> Can anyone advise please books / blogs / videos to learn the theory behind concurrency, threading, Green Threads, how they are implemented?

<comment><USER15> To see the earlier work by Rob Pike on the ideas that would eventually turn into golang take a look at this paper:

[http://www.cs.bell- labs.com/who/rsc/thread/newsquimpl.pdf](http://www.cs.bell- labs.com/who/rsc/thread/newsquimpl.pdf)

A good overview (of CSP) document is written by Russ Cox:

[http://swtch.com/~rsc/thread/](http://swtch.com/~rsc/thread/)

Both the above articles are more focused on implementation as opposed to theory.

<comment><USER14> Thanks!

</comment></comment></comment><comment><USER16> Wonder what the original author thinks of [http://erjang.org/](http://erjang.org/) or erlang on the jvm.

<comment><USER17> Erlang on the JVM as anything more than a toy is fundamentally misunderstanding Erlang -- which basically reinforces the article's central thesis. The article mentions the need for lightweight concurrency support to be baked into the platform -- the Erlang VM is the epitome of this. Idiomatic Erlang spawns a large number of isolated, concurrent processes, and lets them crash when things go wrong, with supervision trees to recover and restart processing. If a single JVM thread crashes, the whole VM goes. Additionally, you also lose secondary benefits such as per-process heaps/GC, etc. These things are impossible to cleanly graft on to the JVM.

<comment><USER18> Er, you can easily write a Java thread that just terminates or restarts itself if it crashes ...

</comment></comment></comment><comment><USER19> Anyone using core.async knows how this article relates to it?

<comment><USER20> The points about the JVM not being able to guarantee that your code won't block the thread apply; it's left up to you to do it. This doesn't come as any surprise to me, nor I would guess to most users of the library, so I'm not sure this is really that damning. Core.async doesn't use bytecode weaving or fork/join, so those criticisms don't specifically apply.

<comment><USER3> It's damning because, rather than outsource the issue like the library makes you think you are doing (or like anyone writing erlang code actually is doing) you still have to deal with the hassle and the risk, so you're not really buying much.

<comment> village-idiot Except you're using it Clojure, which makes it easier to avoid that kind of stuff and easier to spot when you count on Java APIs directly.

</comment></comment></comment></comment><comment><USER21> So, CLR and Mono would be better?

PS: at least not the V8/Node.</comment>


Why English?? - <AUTHOR> http://berzniz.com/post/93309818446/why-english

<comment><USER2> A friend of mine works at a company in which the "company language" at a certain level is French. It really depends on the company and which direction it wants to go.

If the company wants to globally recognised, it might be useful to use a Global Language like English instead of a local one. Especially in a field like software development. Where all tools are English anyway.

So I think your point for using English are valid. (Especially since the plans for making Finnish the world language won't become reality anytime soon.)

P.S. I currently have a heated discussion with myself in what language I should use my computer. Mostly because I've seen so many badly translated UI elements, which also comes from the fact that my native language loves combined nouns which can be very long and usually destroy the layout of a webpage or app. But when I use English I think I often don't get the content I want or I'm looking for. Google Now uses e.g. Miles when locale is set to English (UK). On the other side, it can be vey frustrating to fix the translation of projects. I tried.</comment>