Tell HN: Meet CoffeeScript - <AUTHOR> http://jashkenas.github.com/coffee-script/#overview

<comment><USER2> Oops. I was hoping to post this to HN in a couple of days when it's finished, but the latest commits to CoffeeScript on Github include a compiler that's written entirely in CoffeeScript. It's been compiling itself since Friday.

This means that you can compile scripts in the browser, should you choose to, or within Node.js on the server, and greatly increases the speed of the interactive REPL. It's also a nice showcase for what's possible in CoffeeScript.

For example, take a peek at the Jison parser, using a little DSL function that makes for a nice style of grammar declaration:

[http://github.com/jashkenas/coffee- script/blob/master/src/gr...](http://github.com/jashkenas/coffee- script/blob/master/src/grammar.coffee)

If you'd like to play with the CoffeeScript-in-CoffeeScript implementation, use bin/node_coffee when you check out the source. bin/coffee remains the Ruby implementation until the CoffeeScript side is up to feature parity.

Here's the original post, things have come a long way since then:

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

<comment><AUTHOR> Sorry about posting it early :) I must have missed the original story and when I discovered it today I thought it merited sharing with HN.

</comment></comment><comment><USER3> Is there any reason the object comprehensions can't be rewritten from:

        ages = (function() {
          __a = []; __b = years_old;
          for (child in __b) {
            age = __b[child];
            if (__hasProp.call(__b, child)) {
              __a.push(child + " is " + age);
            }
          }
          return __a;
        }).call(this);

to:

        ages = (function() {
          __a = []; __b = years_old;
          for (child in __b) if (__hasProp.call(__b, child)) {
            age = __b[child];
            __a.push(child + " is " + age);
          }
          return __a;
        }).call(this);

It's fairly minor but saves a few assignments and generates slightly less noise.

<comment><USER2> Thanks, grayrest. That's a nice improvement that has the lovely side effect of simplifying the code generation needed to implement comprehensions.

I've pushed a patch that implements your suggestion, and all the tests are passing:

[http://github.com/jashkenas/coffee- script/commit/7667e167322...](http://github.com/jashkenas/coffee- script/commit/7667e16732268944232d31cea6a201698ce0661a#diff-5)

Thanks for that.

</comment></comment><comment><USER4> Beautiful to look at.

For anyone who uses this in an app, my guess is that it makes debugging (in firebug etc) kinda annoying? I mean, even though it maps directly to JavaScript, the mental context switch between what you see in firebug and the code you've written would take getting used to?

<comment><USER2> We're trying to be pretty careful about keeping the compiled JS debuggable. To that end:

* The compiled output is pretty-printed instead of minified.

* Comments are passed through in-place to JavaScript.

* All functions are named functions, so instead of a stacktrace full of "anonymous", you can situate yourself.

* There's a "no special functions" rule -- CoffeeScript translates directly into JS without a standard library, which means that theres a one-to-one correspondence between your source code and its JavaScript equivalent, so it's not too hard to untangle.

That said, the temporary variable that we need to generate for some features are a little ugly, and sometimes we need to generate extra safety checks because we don't know certain things at compile time (such as, for example if a range counts upwards or down). Any suggestions for how to make the compiled JS more easily readable would be warmly welcomed.

<comment><USER5> To make the line numbers in JS error messages more informative, you could make the line numbers coincide.

i.e. by minifying the JS where coffee:js lines are 1:m and adding blanks when m:1, instead of always pretty-printing.

It's a trade-off of js-readability for error-readability - a hard call, but very cool to be able to go directly to the line in question.

<comment><USER2> Ah yes, we have a ticket for this.

<http://github.com/jashkenas/coffee-script/issues/issue/132>

Now that there's the self-compiler that can be run without ever saving the compiled JavaScript as a file, this becomes far more important.

</comment></comment></comment></comment><comment><USER2> Alright, just pushed a quick update to the documentation page that includes the self-compiler. You can try compiling CoffeeScript expressions in the browser right here:

<http://jashkenas.github.com/coffee-script/#try_coffee>

</comment><comment><USER6> Excellent work Jashkenas! I think what would really let you achieve liftoff (and a book deal with a tech publisher) would be a Sinatra-like framework based on this. The Sinatra core is very small and has wowed a lot of people, replicating it so that people are using coffeescript serverside and also in the client would be amazing. I imagine a 300 page book equally divided between the language, server-side and client-side would sell really well with a 1.0 release. I can easily picture a rails-like ecosystem (with associated business and publishing opportunities) surrounding this in the future.

<comment><USER3> There's no real shortage of sinatra clones for js:

<http://www.fabjs.org/> <http://code.quirkey.com/sammy/> <http://github.com/visionmedia/express/>

and there's no real trick to using them:

        require 'express'
        require 'express/plugins'

        configure ->
            use MethodOverride
            use ContentLength
            set 'root', __dirname

        get '/hello', ->
            @contentType('html')
            '<h1>Hello World </h1>'

        get '/user/:id?', (id) ->
            @render 'user.haml.html', {
                locals: {
                    name: if id? then 'User '+id else 'You'
                }
            }

</comment></comment><comment><USER7> So far, one of my favorite features of CoffeeScript is how responsive you are to questions comments and concerns jashkenas.

</comment><comment><USER8> Is there a chance to add macros? Don't know enough about macros to know if it was doable for CoffeeScript, but only today I run into a situation where I thought it would be nice to have them in JS.

<comment><USER2> Mind explaining the situation that you encountered? Maybe we can come up with something.

<comment><USER8> I am afraid it already slipped my mind as it was several hours ago. But I am sure another situation will arise. Where would be a good place to discuss it, as this thread will long have been gone stale by then?

</comment></comment></comment><comment><USER9> Repost, but great job. I really like how crud-free it is compared to the javascript versions of the same scripts.

</comment><comment><USER2> If anyone wants to try tweaking the grammar and recompiling the language, you can run this:

        bin/node_coffee src/*.coffee --output lib/coffee_script

Just be careful, if you break it you'll have to check out the 'lib' directory again to get a working compiler back.

</comment><comment><USER10> Ah, the existential accessor operator is lovely. It really warms the heart to see variations on the Maybe monad sneaking into other languages--if there's one thing from Haskell I miss elsewhere, it's that.

</comment><comment><USER11> I love the syntax for lambdas and existence checking.

</comment><comment><USER12> So it's almost identical, but with worse (IMHO) syntax!

It's all a matter of taste, but I can't see this as being more tasteful than js.

Also it's comparing to crappy js.

For example

      // Splats:
      race = function race(winner) {
        var runners;
        runners = Array.prototype.slice.call(arguments, 1);
        return print(winner, runners);
      };

Could be rewritten

      race = function race(winner) {
        return print(winner, Array.prototype.slice.call(arguments, 1));
      }

<comment><USER13> You hate everything. Maybe you should just not read this type of article.

<comment><USER12> Yeah you're right. I'll try hard to ignore the "language syntax sucks/rocks/is _so_ important" articles.

</comment></comment></comment><comment><USER14> The script syntax is less intuitive than javascript and doesn't save that many lines, so I'm not sure it's something I'd ever use.

<comment><USER15> Not 'less intuitive', it is 'less familiar'. These sorts of comments are largely subjective. See also C family programmers looking at Lisp or ML family languages.

<comment><USER14> You are going to have a very hard time convincing me that anyone who doesn't know Coffeescript syntax is going to undertand what this means:

       number: -42 if opposite_day

however, almost anyone, even non-programmers can understand this:

      if (opposite_day) {
        number = -42;
      }

<comment><USER16> _even non-programmers can understand this_

Isn't that the Python fallacy? (Take away the curly braces, anyhow.)

Programming is a lot more than syntax. How many non-programmers do you know who understand the semantics of mutable assignment without having it explained?

<comment><USER2> I'm glad you brought up mutable assignment. The reason for allowing colons as an alternative to equals signs in CoffeeScript is two-fold, the lesser reason is to make regular assignment consistent with JSON assignment, eg, both of these are legal CoffeeScript:

        obj: {prop: val}
        obj.prop: val

        obj = {prop = val}
        obj.prop = val

But the main reason is to avoid the equals sign as a symbol for assignment, because it has such a different meaning that you would expect in its use in math (unless immutable), where it implies the equivalence of the expressions on the left and right side for the entire duration of your proof.

Using colons, like JSON does to great effect, looks more like tagging a value with a label, which is much closer to the meaning of what you're actually doing in JS.

</comment></comment></comment></comment></comment><comment><USER17> Why are braces needed in the Math declaration? Is this not Pythonlike enough to use the indentation, or is there something else?

<comment><USER2> The braces are there because JavaScript's object literals are already pretty nice. But it would certainly be an interesting feature, if assigning to a block implied an object literal.

        obj:
          prop: value
          prop2: value2

edit: I've opened a ticket for this, here:

<http://github.com/jashkenas/coffee-script/issues/issue/146>

</comment></comment><comment><USER18> In a word: cool.

</comment><comment><USER19> Okay, enough of these metalanguages. These languages might make it slightly easier to write your program, but the inability to use standard development tools with it results in you loosing more time in the end.</comment>


My brand new Python IPFS pastebin for the lazy at heart - <AUTHOR> https://github.com/drozdziak1/merkleshare <comment><AUTHOR> This is my first Python package - an IPFS pastebin similar to [http://sprunge.us](http://sprunge.us). Works wherever IPFS does and can output gateway links if your recipients don't have IPFS.

Note: For the sake of simplicity, merkleshare is not encrypted.</comment>


Amazon Retools with Unusual Goal: Get Shoppers to Buy Less - <AUTHOR> https://www.wsj.com/articles/amazon-retools-with-unusual-goal-get-shoppers-to-buy-less-amid-coronavirus-pandemic-11587034800 <comment><USER2> _To lessen the burden on warehouses, Amazon has been contacting its third- party sellers and encouraging them to ship items themselves rather than through its "Fulfilled By Amazon" program, said people familiar with the matter. Sellers pay a fee to Amazon to be part of the program, and Amazon has spent years trying to expand this service. But with its delivery network taxed, the company is opting to forgo the fee in the interim, one of the people said._

The fee to participate in FBA via Amazon Seller Central is $40 per month. Eliminating that fee is a drop in the bucket to most medium to large volume sellers, who now have to contend with extra shipping costs if they ship FBM (M = Merchant) or the even more expensive "Seller Fulfilled Prime" in which seller is responsible for getting the goods to customers in _two days_.

What Amazon should be doing to encourage more FBM sales is reducing the per- item fees associated with each order, or adding other incentives.

Another side effect of having sellers ship FBM are millions of orders are going through the US Post Office instead of Amazon's transport network or UPS. The USPS needs that package revenue, with junk mail down sharply and some in Washington calling for the service to be privatized ([https://www.vox.com/2020/4/12/21218151/usps-bailout- privatiz...](https://www.vox.com/2020/4/12/21218151/usps-bailout- privatization-amazon-trump)).

<comment><USER3> Wait, I don't understand. So sellers pay Amazon a fee to use FBA, Amazon wants to discourage FBA right now, so Amazon has _removed_ the fee... thereby eliminating that miniscule barrier to using FBA?

<comment><USER4> There is a small, nominal fee for FBM, Fulfilment by Merchant. This is distinct to FBA.

<comment><USER3> So they are dropping the FB _M_ fee, not the FB _A_ fee? That's not what the quoted text indicated. I can't read the article to see if the context changes the meaning.

<comment><USER5> (i think) when OP says "eliminating that fee is a drop in the bucket", they mean that sellers who switch from FBA to FBM would no longer need to pay (eliminate) the FBA fee... but saving $40/yr isn't much of an incentive when you suddenly have to deal with all your shipping yourself.

</comment></comment></comment></comment></comment><comment><USER6> I wonder if one of the ways they are trying to lessen demand is by showing over-estimated delays in shipping. I've gotten every recent order delivered much faster than estimated at the time of purchase. (Sample size about n=5)

<comment><USER7> Still waiting on my desk chair to ship after 10 days with an estimate of May 4-5. It was "out of stock" when I ordered, then immediately "in stock" after. That probably has something to do with the delay.

<comment><USER8> When that happens just cancel your previous order and start a new one. Have done that a few times

<comment><USER7> I don't order often enough to justify Prime, so the wait so far isn't much worse than normal. Not being able to sit at my computer has given me some much-needed perspective on how I use it, so it's not all bad.

</comment></comment></comment></comment><comment><USER9> I've made my contribution by not ordering anything from Amazon. Though pretty much every ecommerce site of any significance is stressed to the max right now. And B&H is, as usual, closed for Passover. Still trying to support local businesses as much as I practically can.

<comment><USER10> I'm crossing my fingers that the two SSDs I ordered in B&H's last order window ship today because their stores are closed and the warehouses are on reduced hours.

Always buy from _good_ small businesses first (vote with your wallet). Megacorps are unfortunately a practical, but depressing, evil last resort.

Btw, Instacart (YC S12) works here in Paradise, CA with a smaller chain discount grocery store! :) (Local CVS ((still listed on IC)) closed due to loss of customers, there is a Walgreens franchise in-town ((not on IC)) and CVS delivers medications by mail for free right now.) And our most recent shopper was lightning fast and a good shopper too.

<comment><USER11> > Always buy from good small businesses first (vote with your wallet). > Megacorps are unfortunately a practical, but depressing, evil last resort.

Not to be a downer, but if you're looking for _good_ businesses, B&H is likely to score no higher than Amazon by most criteria. They:

\- Don't pay appropriate sales tax: [https://www.theverge.com/2019/11/14/20964980/b-h-photo- taxes...](https://www.theverge.com/2019/11/14/20964980/b-h-photo-taxes- lawsuit-new-york-state)

\- Discriminate against Hispanic workers: [https://www.cnn.com/2016/02/29/us/bh-photo- lawsuit/index.htm...](https://www.cnn.com/2016/02/29/us/bh-photo- lawsuit/index.html)

\- Discriminate against non-Jewish employees: [https://www.jpost.com/diaspora/new-lawsuit-claims-b-and-h- di...](https://www.jpost.com/diaspora/new-lawsuit-claims-b-and-h- discriminates-against-non-jewish-employees-571983)

<comment><USER12> I noticed that all of your supporting evidence is articles talking about allegations made in lawsuits. What were the results of these suits? Were any of the claims substantiated?

<comment><USER11> I believe the tax lawsuit is still pending, the most recent documentation I can find from the NY AG is a summons from mid-November of last year: [https://ag.ny.gov/sites/default/files/2019.11.14_nyag_v._bh_...](https://ag.ny.gov/sites/default/files/2019.11.14_nyag_v._bh_- _summons_complaint.pdf). There is a corresponding press release from the NY AG office: [https://ag.ny.gov/press-release/2019/attorney-general- sues-b...](https://ag.ny.gov/press-release/2019/attorney-general-sues-bh-foto- electronics-defrauding-new-york-out-millions-sales)

The 2017 case was settled ([https://www.dol.gov/newsroom/releases/ofccp/ofccp20170814](https://www.dol.gov/newsroom/releases/ofccp/ofccp20170814)), with B&H agreeing to pay $3.2mm in back wages and "hire a workplace consultant to correct its employment practices and conduct"

They settled a similar 2007 case by distributing $4.3m in monetary relief: [https://compensation.blr.com/Compensation- news/Performance-T...](https://compensation.blr.com/Compensation- news/Performance-Termination/Performance-Employee-Appraisal/BH-to-Pay-4.3M-to- Settle-Suit-Alleging-Pay-Bias-Ag/)

My point is not that B&H is bad, but that "support small business" doesn't mean that you're supporting an ethical business.

</comment></comment></comment></comment></comment><comment><USER13> My new power tool arrived in just its own original mfg box. Instead of being reboxed by Amazon.

Maybe because of FBA? (Reviewing the order details, I can't figure it out.)

Whatever the reason, woot! Less is more.

<comment><USER14> We had something back-ordered on Amazon (from before all this crazyness happened) and it eventually arrived in a Sam's Club box

<comment><USER15> That's happened in the past with items I've ordered, as what appears to have been part of an arbitrage scheme - list items on Amazon that Walmart.com sells for less, and when you get an order, reorder it from Walmart.com with the Amazon buyer's shipping info. Every time it's happened and I've checked prices on Walmart.com, they've been ~20% lower than what I actually ended up paying. Seems like a cute little grift, all in all.

</comment></comment></comment><comment><USER16> I've started looking to ebay and Newegg a bit more.

However these days Newegg seems to be more a marketplace for Chinese sources and proxies of Chinese sources.

Ebay has been okay, though sometimes they don't even get the goods into the transport network until after it was promised to be delivered.

</comment><comment><USER17> Why not just raise prices on non-essential products? That will decrease sales and increase profits. Everyone wins that way: the folks who need essential products win, because the bandwidth available for their needs is increased; the sellers win; Amazon wins; and people who want non-essential products and are willing to pay for them win because they can still get them.

The people who want non-essential products but cannot or do not want to pay the current price do not win, but they are no worse off than being unable to buy at all.

<comment><USER18> While that would probably work, it may not be legal: [https://en.wikipedia.org/wiki/Price_gouging](https://en.wikipedia.org/wiki/Price_gouging)

<comment><USER4> Is Uber surge pricing price gouging?

<comment><USER18> Some people think so!

But price gouging is usually defined as being in response to emergencies, which a pandemic is and a sharp spike in Uber demand may (a tsunami) or may not (bars closing at 2am) be.

</comment></comment></comment></comment><comment><USER19> [https://archive.md/hbzHu](https://archive.md/hbzHu)

</comment><comment><USER20> IIRC paywalled sites without workaround are not allowed on HN. The link should be changed to an alternative source. Here is one:

[https://nypost.com/2020/04/16/amazon-wants-customers-to- buy-...](https://nypost.com/2020/04/16/amazon-wants-customers-to-buy-less-as- demand-skyrockets/)

Regarding the content: Wouldn't it make more sense for Amazon to simply show products that are fulfilled by the seller directly? This way they could still make their cut but do not have to do the delivery.

<comment><USER21> Here's the workaround for WSJ: [https://news.ycombinator.com/item?id=16906571](https://news.ycombinator.com/item?id=16906571)

<comment><USER22> Fyi... the above workaround with Google/Facebook acting as referrer/redirect for the url hasn't worked in years. And especially if the browser has already visited WSJ a few times and hasn't been restarted with a fresh session. Notice in the following video that browser status bar says _" Incognito"_ and yet the Facebook redirect still doesn't work:

[https://imgur.com/a/LKHW9OB](https://imgur.com/a/LKHW9OB)

The "?mod=rsswn" also doesn't work anymore. Disabling javascript doesn't work either. Popular sites like NYTimes and WSJ do more sophisticated things than just checking cookies. My memory fails but I think the last time I looked at this, the sites sniffed HTML5 local storage or something not obvious.

[I didn't downvote your comment.]

<comment><USER23> This adtech arms race is ridiculous.

The link shouldn't even resolve if they require paying customers, unless signed in.</comment></comment></comment></comment>


Building Apps for Linux Without Linux - <AUTHOR> https://popey.com/blog/posts/building-apps-for-linux-without-linux.html <comment><USER2> tldr; snap creation on Windows as well, WSL.</comment>


Why Facebook isn't Worth $50 Billion - <AUTHOR> http://brooksreview.net/2011/01/worth/ <comment><USER2> financially Facebook isn't $50 billion, that's probably justified, but intrinsically I personally think $50 billion undervalues Facebook. If it was a country, it's the third most populated one. Name me a country that has a GDP lower than $50 billion. @ $50 billion dollar evaluation and 600 million users, each user is valued at $83.33 which I think is undervaluing the lifetime value of a customer for Facebook. I'm pretty sure at sometime in the near future, a typical Facebook user would spend more than $83.33 on the Facebook website. You just have to wait for the innovational monetization model.

<comment><USER3> I may agree that Facebook is ultimately undervaluated, but : "If it was a country, it's the third most populated one. Name me a country that has a GDP lower than $50 billion" is the most non-sensical analogy I've seen in a long time.

<comment><USER2> haha, well to start off I feel a bit honored to allow you to see something you haven't seen for a long time. But maybe it wasn't the best way to illustrate a point, but it wasn't really meant to be an analogy. The goal was to emphasize the poplation of Facebook, how how valuable of an asset the user database is. I mean no one doubts that Facebook is a community, but when a community gets THIS big, it's somewhat justified to call it a country.

<comment><USER4> But it's not justified to call it a country if you are going to compare its valuation as a company providing a social network to GDP, which is the sum total of all economic activity of the entire population.

<comment><USER2> okay fine, i do agree to the fact that it's not the best comparison ever, but it gets the point across. The point wasn't to make the perfect analogy, but to get across the value of Facebook relative to countries. How do you value a country? Many ways, but one of the most popular one is GDP. How do you value a company? Its valuations. That was the thinking behind my statement. I mean if you don't see it, it's fine, disagreements are justified.</comment></comment></comment></comment></comment>


Ask HN: What do you think of my landing page? - <AUTHOR> http://knotist.com

<comment><USER2> One small thing - the words "wedding vendors" fade into the white part of the background.

Also, you might want to add a little more about what early registrants might get out of it. What geographical areas are you focusing on first? When do you expect to launch? I wouldn't register unless I knew your launch date would be well before my wedding.

<comment><AUTHOR> That's a good point. I need to spend some time putting info about the site in print. Thanks for the feedback!

</comment></comment><comment><USER3> Overall, it's very good. Your message is very clear. Agree with the other comments specially a coming on xx month.

I would probably add a little message on the top of your tagline for the people getting married. Something like:

Worry no more. We are creating a community for top wedding vendors.

</comment><comment><USER4> Yeah, japhyr is right. It may be a personal thing, but I think the left justified Register button is a little off. Maybe right justified, or centered (as I say this, I'm noticing that the add comment button below is left justified as well :)) Nicely done though.</comment>


Malcolm Gladwell: The strange tale of the Norden bombsight (2011) - <AUTHOR> https://www.ted.com/talks/malcolm_gladwell/transcript?language=en <comment><USER2> Good piece. I would take argument over his asserted correlation between the improved accuracy of drone strikes and the 10x increase in attacks on U.S. Forces.</comment>


Words I Would Love To See Banned From Press Releases - <AUTHOR> http://www.techcrunch.com/2009/08/01/10-words-i-would-love-to-see-banned-from-press-releases/

<comment><USER2> I'd like to see "leverage" added to the list. I cringe every time I hear it when the word "use" would suffice.

(I can accept its use as a noun in the financial context, because it means more than "use" in that sense. And although the situation hasn't come up yet, I wouldn't mind its use when talking about a physical lever.)

<comment><USER3> When I hear the word "leverage", i release the safety on my browning.

</comment></comment><comment><USER4> 1 blogger I would love to see banned from blogging -

Robin Wauters. For equating a Crunchie to both the Nobel and the Pulitzer.

<comment><USER5> You may need to have your sense of humour overhauled.

<comment><USER4> Oh believe me, I get that he was joking. My point was that that statement should never be made, _even_ in jest.

</comment></comment></comment><comment><USER6> On awards.

" _Basically it's like going around a party informing everyone that you've had sex with a human being last week: I'm sure it matters to you a great deal - and hopefully to the other person as well - but the rest of us likely don't give a hoot._ "

Nice line.

" _There are exceptions to this rule, but very few (they include ... a Crunchie ...)._ "

Um, I'm sure they matter a great deal to you, Mr. Wauters, but... Way to attack the symptoms of a disease you yourself have.

<comment><USER7> Yeah, I was confused by that -- was mentioning the Crunchie and the Europa Award in the same sentence as the Nobel and the Pulitzer a joke? If not, wow.

</comment></comment><comment><USER8> Modern day pretentious diction! Orwell would be rolling in his grave! [[http://www.george- orwell.org/Politics_and_the_English_Langua...](http://www.george- orwell.org/Politics_and_the_English_Language/0.html)]

</comment><comment><USER9> It's like with advertising. Press Releases themselves aren't a problem, only irrelevant, boring, poorly targeted ones.

</comment><comment><USER10> HN feature request: a domain ignore list on a per user basis.

</comment><comment><USER11> You know if we banned ALL words from press releases, we wouldn't have to suffer through press releases at all any more.

</comment><comment><USER3> So here is a challenge, TC, rewrite the press release for "Akamai and Delve" in a way that you find acceptable.

<comment><USER12> I have no association at all with TechCrunch, but how about this? It's basically the same content, without the TC-hated terms. (Of course, it now has a lower advertising:information ratio, and the real point of press releases is advertising rather than information. Which is why they're usually full of the sort of weaselly preening TC is complaining about.)

"Delve Networks, a provider of video platforms, announces a collaboration with Akamai Technologies, Inc. (Nasdaq: AKAM), whose services power rich media, dynamic transactions and enterprise applications online, that will enable Delve to offer customers a comprehensive video publishing solution that includes video management and delivery including support of modern variable bit rate streaming technologies."

The only difficult bit was getting rid of the "the leader in powering X" language, which was difficult because it doesn't really mean very much. (With a less PR-speak description of what Akamai does, I think it would be quite reasonable for them to call themselves "the leader".)</comment></comment>


Survival Tips for Women in Tech (2018) - <AUTHOR> https://patricia.no/2018/09/06/survival_tips_for_women_in_tech.html <comment><USER2> > Making your work public.

I cannot stress this enough. Regardless of who you are, holy hell some people WILL steal your work for their own.

My first internship manager in late 1980's took my work and patented it as his own! I found out about it years later when I was hired permanently. I confronted him and he told me interns weren't allowed to patent. I learned this was false years later, but he had already left the company.

In a second instance, that same internship, I also wrote some code that was published in a corporate whitepaper and the motherfucker replaced my name with his in the comments. Different guy, same company.

I don't think making it public would have mattered because I was just an intern and we were treated as shit, but thinking back on it now makes my blood boil because both the patent and the doc are public record (USPTO) to this day. Maybe today I would have a fighting chance as an intern.

If you have a good idea, make sure top brass know it came from you. There's no guarantee it won't be stolen, but it gives you a fighting chance the more people know that you did it.

Heh. 30+ years later and I'm grumbling about it again. lol.

Also, FTA:

> Avoid everyone who is really enthusiastic about you being a woman.

I always found it creepy how some guys fall all over themselves to remind the only woman on the team that she is the only woman on the team. It's like, 'yay, thanks for noticing...??' but ... hmmm...

I'm guessing it is just a guy new to workplace diversity, and give him some slack. In my experience, it is usually older men (50-60's) who are getting the swing of the new generation of "sexism is bad, mmm'kay" and really want to show they are trying but know they were inherently trained by society to think in 80's/90's way about diversity. I get it.

</comment><comment><USER3> I like the list, but don't like the adversarial tone. I don't think it's me vs. men all the time. Some men are jerks, most are not. More actionables:

* Remove "just" from your vocabulary, emails, talks, everything. "I just want you to be aware that ..." "I'm just doing this to..." "It's just that ..." "Just making sure ..." Trim 100%.

* Bake cakes, participate in office pot-lucks or whatever. Never be part of the setup/cleanup crew (have you noticed they are almost always women, admins type). This makes you a jerk, true, but disassociates you from the soft-skills crew. Until the cleanup crew becomes frequently and mostly men, stay away.

* You're eventually going to have to fight for something you care about. Pick battles 1) that you can win; 2) with someone above your weight. How do you become a blackbelt? By beating a blackbelt. It's no thing to gainsay some design decision made by the FNG, better to convert a decision made by someone seen as your technical equivalent or superior.

<comment><USER4> OP in the article is actually saying that you should NOT bake cakes. (Unless you're working for a baking company, I guess?) The cake is a lie.

</comment></comment><comment><USER5> There is always at least one guy in a team that makes life difficult for a woman in a dev team. I feel bad for the amount of shit women have to deal with to survive as a software dev.

<comment><USER2> Sad story.

About 10 years ago, I was brought in as a contractor to train a team with 5 junior women engineers, one other junior man, and an older woman manager.

The other guy would constantly shit on EVERY idea presented by a woman. Like, in the 4 months I worked there, he never once said anything positive in any of their presentations or our group exercises, and he was like 25 years old and just as experienced as they were.

One of the woman programmers was exceptionally good and he shat on her the hardest because her ideas were usually adopted, but she was meek and the manager faught him (her subordinate!) for said junior woman's ideas. It was so fucked up.

On my way out, I had a meeting with him and talked about how he was being very dismissive of perfectly reasonable solutions, and he flat-out told me "women aren't very good at engineering, I'm a better programmer (he wasn't) and need to clean up their ideas first, I'll eventually run this group." I was like, holy shit, there's no reaching you.

<comment><USER4> > The other guy would constantly shit on EVERY idea presented by a woman. ... > "women aren't very good at engineering, I'm a better programmer (he wasn't) > and need to clean up their ideas first"

Sounds like a toxic narcissist. And sadly, really common - it's the sort of attitude that's often hiding in these "Group X rules, Group Y are lame!" controversies.

Just push back calmly and confidently, and you'll find that it's quite possible to keep these people in check. Ultimately though, I don't think their attitude is compatible with an effectively-functioning workplace.

</comment></comment></comment><comment><USER6> Sadly required, but seems very honest and relatable. Would probably share with any woman in tech.

As a secondary point, I find several of these applicable to me as a guy too, although that's not the main point of this.

I also really like this formatting and list style - heading and brief to-the- point description.

</comment><comment><USER7> This is an amazing collection of advice and experience. I'm not a woman in tech but I have worked with and managed plenty. I really appreciate this list being shared and publicized. Hopefully it helps some people stay in the field longer than they otherwise would have!

</comment><comment><USER4> > "On Bad Days try to lose yourself in the work, try to remind yourself why > you're in this business"

Really? I'd say that the best "survival tip" in a challenging industry is to act professionally, and another way of saying this is that "losing yourself in the work" should not be reserved for bad times!

</comment><comment><USER8> "HR is not your friend" \- fuck off with this bullshit. If you're actually being harassed, say something. And your colleagues should be your team, not your enemies. This rivalry thing in companies is pissing me off.

<comment><USER5> HR is there to protect the company. It is probably tempting to just remove the disruptor instead of being fair. It is absolutely valid advice.

<comment><USER8> If that is the case in your company, leave. Don't take this as something you have to accept. There are a lot other fish in the sea.

If we make rivalry our norm, what could we ever archive together?

<comment><USER5> There is always rivalry. The problem for women is they bring it out more in men with ego problems.

<comment><USER4> There's a lot of rivalry amongst women too, it just plays out in different ways and different domains. You can even see this in OP's distrust of the "soft skills" 'team' \- that part of the enterprise is precisely where rivalry tends to matter the most.</comment></comment></comment></comment></comment>


Show HN: Goxygen: a CLI tool to generate Go+React based web projects - <AUTHOR> https://github.com/Shpota/goxygen <comment><USER2> Is this yours? How much time did you spend on it?

<comment><AUTHOR> Yes, it's mine. Hard to estimate in hours. But it is around 3 weekends plus time to time after work.

I have plans to develop it further so I expect much more time investments.</comment></comment>


Developing as a developer: a journey through learning - <AUTHOR> https://blog.ragnarson.com/2016/10/07/developing-as-a-developer.html <comment><USER2> As someone whose been on a programming adventure for over a year now, this article hit a lot of great points.

I started learning from only basic knowledge gained in engineering school. I started small, but always strove to maintain a consistent amount of effort. Gotta pick up that hammer and swing it, even if it just means making one little crack in the wall.

The most difficult thing by far is silencing your own self doubt. It's too easy to think of the massive amount of knowledge you're supposed to know and immediately tell yourself you'll never make it. It's a skill in itself to just ignore those thoughts and keep pushing. What other option is there besides walking the path or giving up?

One thing I've noticed from other self taught programmers is that many will eschew the fundamentals. I believe it's really important to understand why a certain tool or framework came about and what issue it's trying to solve. Don't be afraid to step away from the hottest frameworks and cut to the basics.

Don't mitigate your accomplishments. So much work going on now is so complex and impressive! That doesn't mean your small project isn't any less of a personal achievement.

Keep learning, keep building and immerse yourself in the community. Don't forget to pick your head up every once in a while to see how far you've come.

<comment><USER3> Good points! I agree that fundamentals are important and make many things easier in the end. I can see that it may be difficult for someone self taught to focus on those and be patient before jumping into that framework everyone is talking about. It is worth it though in the end.

I also like your note about accomplishments. This is really important to feel proud about things you've accomplished. Finding joy in these small completed projects may motivate you in going forward. There's no point in feeling worse.

Everyone started somewhere and it is very likely that most of the brilliant programmers also made simple things in the beginning (and most probably were very proud of them :)), but yes - fighting your doubts is very difficult.

I feel like we should try to find someone who will give us a positive feedback to soften the frustrations. This may not even be a specialist in the field - show what you've done to a friend or family - added bonus: they will be likely even more impressed. We tend to be overly critical about ourselves, so it is useful to search for feedback from others.

Thanks a lot for sharing your thoughts!

<comment><USER2> Definitely agree about talking to others. I'm really lucky that most of my closest friends are awesome developers.

I'm about to start applying for full time developer jobs and grad school so I've been reflecting a lot on my journey to get here. It's going to be a leap but I'm confident I'll make it!

Thanks!

</comment></comment></comment><comment><USER4> > Just keep on going. Lesson: Be persistent, don't give up.

All lessons are interesting and all ideas can be valuable, but in this kind of articles I always find that the most valuable advice is just this: be persistent, don't give up. I'd say this is usually the key for success in many areas of knowledge (and certainly in programming).

<comment><USER3> Thanks for your comment. Yes, I feel like this is the most important thing in learning new things (as you mentioned, not only programming). There always comes a time where we feel like we are not making any progress or get frustrated. This is where usually those that give up fail and those that keep on pushing ultimately succeed. This is not always easy, but I find that reading about other people stories (where we find out that others struggle as well) helps a lot.

</comment></comment><comment><USER5> This really made my day. As a programming adventurer I can totally relate with most of the points. Reading this post upped my motivation. I am going to take a print out and keep it on my desk, so that I can read it whenever I am feeling down.

<comment><USER3> Thanks a lot for such a positive comment :) I am happy that you found the article motivating and relatable. This also shows how true the lesson about sharing your story may be. It really can help others in ways you don't even expect. Good luck in your journey :)</comment></comment>


The reason my website generates SSL warnings, and why that's ok - mike-cardwell https://secure.grepular.com/Why_Does_this_Website_Generate_SSL_Warnings

<comment><AUTHOR> HTTPS using certificates signed by DNSSEC is coming. In fact, support for it is already in Chrome (although behind a command line flag).

If you want details, see: <http://www.imperialviolet.org/2010/08/16/dnssectls.html>

The current holdups are that .com does yet support DNSSEC (it should happen early next year), and that people are still figuring out what form the DNS records should have. At this point, it's likely to be a new (binary) RR type which doesn't have an RRTYPE code assigned yet. I just need to change Chrome to reflect this.

</comment><comment><USER2> I completely understand your plight. However, why don't you offer an HTTP option?

Very little of your site transmits sensitive information. Its actually a little disconcerting to be forced to use HTTPS to see a simple blog post.

<comment> mike-cardwell For idealist reasons really. I believe all communications over the Internet should be encrypted by default. It would solve a lot of problems to do with security, privacy and network neutrality.

</comment></comment><comment> mike-cardwell This is partially a response to some of the comments on my "Kik Messenger Insecure" post discussed here:

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


AMD Announcing Ryzen 4000 Series [video] - <AUTHOR> https://www.youtube.com/watch?v=zUeo7kUzn_8 <comment><USER2> AMD is on a tear, now only if they could translate this to their GPUs.

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

</comment><comment><USER4> What's the point of sharing a link to a "Private video" that no one can watch?</comment>


Ask HN: If you have any Dreamhost hosted sites do they 503 under load? - <AUTHOR> TL;DR: Have a Dreamhost'd site? Please load test it with a simple GET for 50 concurrent users. Does it start off well and then spew 503 errors?
===
We've got a client hosting a fairly basic web application on a respectably spec'd managed dedicated server at Dreamhost (12 cores, 260GB SSD, 16GB RAM). On any given week day, during school hours, there are 1.5-2k concurrent users using his product.
His customers (schools) depend on his web application (an educational product) being available every school day.
Recently teachers started reporting 503 Service Unavailable errors when multiple classes were using the web app, and they've been "forced" to have the students start using another product. This is of course very bad for business.
We've had some good conversations with Dreamhost Support, and they've dug into it a little, but they don't think it's an issue on their server or network, and we can't find any reason for our web application to be throwing the errors either.
We've done some simple, 50 concurrent user, load testing with a tool called Throng, and on loadimpact.com and we can easily reproduce the 503 issue in both tools. We also discovered that in addition to our site, we can reproduce it just as easily on another domain on a completely separated (shared) server.
With that last point in mind, it sure seems like a potentially Dreamhost-global (network?) issue. Maybe some kind of DDOS protection? You'd think that Support would know about something like that though.
So I was hoping you could please try and stress test your own Dreamhost'd domain(s), and let me know the result(s). I'm desperate to help our client, and an emergency Sunday night move to another company is starting to feel like our only option.
Thank you. <comment><USER2> It sounds like you don't have any other option than moving to somewhere else, but how long would it take to set up a staging server somewhere else? In today's docker world, that should not take that much effort and then it is just Dreamhost's loss.

</comment><comment><USER3> If the app is as basic as you said then you shouldn't have issues on a well tuned server

However it's hard to know without knowing what language the app is in and seeing server logs.

</comment><comment><AUTHOR> And no, Dreamhost.com doesn't fail the load test like the other domains.</comment>


Google Engineer: Google+ Is a Knee-Jerk Reaction - <AUTHOR> http://siliconfilter.com/google-engineer-google-is-a-prime-example-of-our-complete-failure-to-understand-platforms/

<comment><USER2> I love this quote:

"The Golden Rule of Platforms, "Eat Your Own Dogfood", can be rephrased as "Start with a Platform, and Then Use it for Everything."</comment>


Google Play Services 5.0 has a new Networking API - <AUTHOR> http://www.quillandcode.com/2014/06/25/google-play-services-5-0/

<comment><USER2> It seems premature to be "freaking out a little bit" before knowing the details. This specific component might be open source and/or the same API with a different package name.

<comment><AUTHOR> It could be, or they could push back every change into AOSP. It just seems like a very odd move to shift their networking API away from the open-source Android, even if it is for security. They probably didn't really have any other choice.</comment></comment>


No More Callbacks: 10,000 Actors, 10,000 Threads, 10,000 Spaceships - <AUTHOR> http://blog.paralleluniverse.co/post/64210769930/spaceships2 <comment><USER2> Nice exemplar. Back when Java was being created, James Gosling was pretty insistent that concurrency be lightweight and scalable. When I ported it from SunOS 4 so Solaris 2.0 I had to move from the really light weight setjump()/longjmp() threads that he had implemented, into the thread system that Solaris had defined. There was a huge negative impact on performance (as I recall about 15x slower). That sucked because one of the coolest demos at the time had a little world in it where 'Fang' (the Java mascot) lived and a bunch of things in that world were all animated with threads. Looking at the 'fiber' model for threads I think they are much closer to what we should have done in the first place.

The thought was to have a billion threads on a SPARCStation 10 (that is like an old Pentium machine now). We never got close but it was a great goal. Definitely going to have to go back and revisit this topic now. Thanks for the excellent demo to play with!

<comment><USER3> I got to about 500K processes on Erlang's VM on an i7 with lots of memory.

These people people got up to 2M concurrent TCP connections

[http://blog.whatsapp.com/index.php/2012/01/1-million-is- so-2...](http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/)

And on top of it, it is using isolated heaps. That is beautiful I think. Completely concurrent GC is beautiful.

I know Erlang syntax is not to for everyone's taste (I do like it though). There is also Elixir ([http://elixir-lang.org/](http://elixir-lang.org/)). But the underlying BEAM VM is an awesome piece of technology.

> The thought was to have a billion threads on a SPARCStation 10

There are some green-thread C libraries I've been playing with, like Protothreads ( [http://dunkels.com/adam/pt/index.html](http://dunkels.com/adam/pt/index.html) ) and libconcurrency ( [https://code.google.com/p/libconcurrency/](https://code.google.com/p/libconcurrency/) ) I think they use setjump/longjump trick. Some use setcontext()/getcontext() POSIX call.

I still like Erlang VM best.

<comment><USER4> Erlang is really good, especially for engineers with hardware background, who may find FP & Message Passing are more intuitive than OOP & Context Switching.

But it's quite difficult to hire.

<comment><USER5> Difficult as in you are looking for Erlangers but cannot find them? I haven't seen many postings looking for Erlang programmers.

<comment><USER6> Seems to be the same thing with Haskell and other languages, including Golang, that many groups on HN are passionate about. There aren't many people hiring for skills in these languages. Some start-up founders I know who have built their company on Python and Javascript, when I ask them if they have looked at Golang, they reply 'What's that?'.

<comment><USER7> I'd be happy if someone would hire Python. Most of it is Java, PHP and C# around here. So sad.

<comment><USER8> Where's "here"? I constantly get emails from recruiters looking for Python devs.

(I'm in the SF area, but a lot of the ads I see are for New York and parts of the Midwest.)

<comment><USER9> Quite frankly, "here" could be anywhere that's not near the Bay Area.

<comment><USER7> I think so too. I'm located in Germany, but I think this situation applies to most all of the word except the west coast of the U.S.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Well written, good description and nice demo.

Would love to see more on how this is different to (or better than) Akka. The programming model is actually close to Akka (with actor systems, supervision, receive method, message passing, etc).

The article states that Akka has no true lightweight threads. The guys behind Akka have put it running with 50M messages/second[1] and perfomance vs erlang seems to be good as well [2][3].

Perhaps a benchmark would be great.

Thanks for sharing.

[1] [http://letitcrash.com/post/20397701710/50-million- messages-p...](http://letitcrash.com/post/20397701710/50-million-messages-per- second-on-a-single-machine)

[2] [http://uberblo.gs/2011/12/scala-akka-and-erlang-actor- benchm...](http://uberblo.gs/2011/12/scala-akka-and-erlang-actor-benchmarks)

[3] [http://musings-of-an-erlang- priest.blogspot.pt/2012/07/i-onl...](http://musings-of-an-erlang- priest.blogspot.pt/2012/07/i-only-trust-benchmarks-i-have-rigged.html) (discussing millions of messages is a good signal IMHO).

<comment><AUTHOR> The main capability provided by Quasar is the fiber, or the lightweight thread. It is the same as a normal Java thread in the sense that it can block – on IO, on a DB call, or on a synchronization mechanism. This makes the programming experience very natural. The actor and the channel abstractions build upon fibers.

Akka doesn't have lightweight threads at all. You implement a message-handling method, but it must not block on, say, a DB call, lest it block the entire thread it runs in. An Akka actor simply must not issue a DB call: it's as simple as that.

With Quasar things are different: you pull messages rather than implement a callback; you can block: on IO, DB, lock or anything else. The programming then is not only simpler, but also more powerful. For example, Quasar supports selective receive - just like Erlang.

<comment><USER11> _An Akka actor simply must not issue a DB call_

That's untrue. With Akka's pipe pattern, you can take the results of any future and pipe it back to the sender, including using a map on the future if you like. This is how we do reactive database calls in Akka. For example:

      def receive = {
        case msg => {
          val f = future { myDatabaseResult(msg) }
          f map { result => myTransformResult(result) } pipeTo sender
        }
      }

At no point does this actor block. Assuming you even have something like Play calling this actor, you wouldn't be blocking there, either, you'd take the result from the actor, likely map it to a result, and Play would asynchronously return that. My basic rule is that if you're typing Await.result anywhere in your Play/Akka code, you're doing it wrong.

<comment><AUTHOR> There are many ways to do asynchronous programming employing functional approaches. The difference is that with Quasar you can use them if you like but you don't have to. You can issue a plain-old JDBC call, and at no point will the thread block, either, but the actor will: because it's simple, familiar and intuitive. You don't need to learn so many unfamiliar patterns. You program as you normally would a single thread.

<comment><USER12> Ok, so issuing a blocking call is "simple, familiar and intuitive". Invoking a Future or a Promise is "so many unfamiliar patterns".

Yes Sir, with this attitude I hope to make a remarkable progress in my tech career :) Seriously, there is nothing mysterious or magical about shoving a "plain-old JDBC call" into a Future.

[http://en.wikipedia.org/wiki/Future_(programming)](http://en.wikipedia.org/wiki/Future_\(programming\))

Remarkable demo, btw. But lets not run down other approaches simply because one might, god forbid, have to "learn so many unfamiliar patterns".

<comment><USER13> Well he is kind of right. I'm familiar with enterprise IT, and there are very mediocre programmers at work. I'll bet you most of them have never heard of "futures". Sad, but thats how I experienced it.

<comment><USER3> > I'm familiar with enterprise IT

I am also familiar with snobby wannabees functional programmers who instead of opening the goddam file and reading it are creating homomorphic endofunctors wrapped in futures with double memoization and distributed locks, so that nobody on the fucking team knows what's going on.

These people are 10x more dangerous than mediocre programmers who just find the simplest way to get the work done and ship the product.

Eventually 1% of the wannabes might get enlightened and realize that simple basic code is usually better than using every single programming concept wrapped in 100 lines of code that nobody (including themselves 2 weeks later) can understand.

<comment><USER14> That's quite a feat of mind-reading you performed there. The fascination with technology rather than just to solve the problem at hand via the shortest critical path is a thing that has been puzzling me for a long time. At some level technology is so fascinating in its own right that the temptation to lose sight of the goal is ever present and many people succumb to that temptation.

Imo it's just another variation on the Yak Shaving theme with a dose of procrastination thrown in for good measure.

<comment><USER15> "Well, Mr. Frankel, who started this program, began to suffer from the computer disease that anybody who works with computers now knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is you _play_ with them. They are so wonderful. You have these switches - if it's an even number you do this, if it's an odd number you do that - and pretty soon you can do more and more elaborate things if you are clever enough, on one machine.

After a while the whole system broke down. Frankel wasn't paying any attention; he wasn't supervising anybody. The system was going very, very slowly - while he was sitting in a room figuring out how to make one tabulator automatically print arc-tangent X, and then it would start and it would print columns and then bitsi, bitsi, bitsi, and calculate the arc-tangent automatically by integrating as it went along and make a whole table in one operation.

Absolutely useless. We _had_ tables of arc-tangents. But if you've ever worked with computers, you understand the disease - the _delight_ in being able to see how much you can do. But he got the disease for the first time, the poor fellow who invented the thing."

― Richard P. Feynman, Surely You're Joking, Mr. Feynman!

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> My first thought was "why don't they use Akka"?

> Akka has no true lightweight threads (the actors are actually callbacks)

Would you care to elaborate? I'm not too familiar with the internals of Akka, but they definitely don't use "heavyweight" threads (which I assume are threads that are 1:1 mapped to OS threads).

Also, I didn't get "the actors are actually callbacks". Yes, there may be callbacks involved internally (why not?), but there is a big difference whether I am sending a message to an actor (which may be processed at any time) vs. calling a callback (which is immediately executed on the very same thread that I'm running on).

Sorry if this sounds dismissive, but I'd really like to learn why you choose to implement your own solution, because you've obviously put some time into evaluating what is out there.

<comment><USER17> [https://github.com/scala/async](https://github.com/scala/async) is the syntactic sugar to write sequential nonblocking code in Scala (no callbacks). Though functional-style code works well also if you know it.

<comment><AUTHOR> [cloned comment]

Essentially, Quasar provides async and await for all JVM languages. async is called `Fiber.start()`, and await is called `Fiber.park`. Other than working for all JVM languages, Quasar fibers are more general in that they can spawn many functions (they have a stack), while async is limited to a single expression block. Because of this, we can hide the "await" deep inside the JDBC call stack.

Under the hood, they are similar: both instrument your code. Only async does this at the language level (it's a Scala macro), while fibers do it at the bytecode level.

</comment></comment></comment><comment><USER18> I'm going to be "that" guy and ask... why actors? Why not agents?

The concept of agents (as defined by Rich Hickey in a lot of his Clojure talks) is all about a globally shared, immutable and persistent state on which you can act upon.

With actors you still need to have the actor handle its own mailbox of requests and then handle them, the actor has to define its behavior.

With agents you don't have to ask for the world to stop to communicate, you can read the current snapshot of the world (aka no request to view the state, no database queries) and send transformation functions on the data of that specific agent, which will be then processed by the agent's thread in an ordered way.

I'd love to see more insight on the choice for this, it's interesting as I am currently working on a similar project.

<comment><USER3> > I'm going to be "that" guy and ask... why actors? Why not agents?

Because actor is an establish paradigm and that has been around for a while. I haven't heard Hickey's talk on "agents" but based on your description, how are agents radically different?

What stops actors from reading the snapshots of the world? They can 1) subscribe to "world" actor and get publication when it changes or 2) if database is immutable (I guess you are hinting at Datomic or Clojure's datastructures here?) an actor can also call a function. Remember actors in practice are there to help isolate concurrency contexts. Reading truly immutable data is safe so actors could just periodically read this immutable data (just think of the database a function). It would be awkward having to process messages from mailbox, timing out, then reading world state, process world state, going back to processing messages. Etc. I like 1) better.

> the actor has to define its behavior.

How does an agent bypass defining its behavior? Doesn't an agent have a piece of code that specifies what that agent does.

> and send transformation functions on the data of that specific agent, which > will be then processed by the agent's thread in an ordered way.

So this basically centralizes the state of all the agents in one central location that is an immutable database? Hmm interesting. It is a different way of looking it at it I guess. Each actor usually handles its own internal state privately. I guess we also assume that there is something underneath that constantly distributes all these incrementing tree of states across a whole system. I don't know I would rather think of actors explicitly choosing to send their state to a system half way across the world rather than rely on another layer of distributing state. Maybe it is just a matter of a mental model here...

<comment><USER19> The best summary of actors vs. agents I've heard is Jonas Bonér's, one of the head Akka engineers:

"With actors you send state to the behavior, with agents you send behavior to the state"

</comment></comment></comment><comment><USER20> > Writing correct and efficient multi-threaded code is at once necessary and > extremely difficult.

I do not agree with this. The original statement he is quoting says "can be very challenging". Yes, if you are designing something very state heavy and your design is somehow flawed or too complex then you can run into issues. However, in most cases threads are no more complex than callbacks, actors, etc. In fact, from what I've seen, concurrent code eventually all converges to some semblance of the actor model anyways.

Where the actors/green threads/etc. really shine is having huge numbers of them. OS threads still have very large overhead compared to lighter weight green threads, so you can spin up many magnitudes more of them than you have CPU cores.

Also, in lots of languages multi-core != concurrent. You can have 10,000 actors using a single core. In fact writing a scheduler that can efficiently distribute actors between different cores is probably where the complexity Doron Rajwan refers to lies.

<comment><USER21> > However, in most cases threads are no more complex than callbacks, actors, > etc. In fact, from what I've seen, concurrent code eventually all converges > to some semblance of the actor model anyways.

Threads are the WorseIsBetter approach to concurrency; they're incredibly simple to implement, but that just means that the difficulties are pushed on to the users (ie. developers using the framework/library).

Threads may be a good idea for code which has no 'design flaws' and is not 'too complex', but as we all know everything has bugs and everything is more complex than it seems. The arguments in favour of higher-level concurrency models are basically the same as for tests and version control: if you don't use them, you're making a dangerous gamble which may cause a large price down the road.

Concurrency models like callbacks and actors can make dangerous things more difficult; if we use the callback examples from the article:

> It's hard for a programmer to reason about which line of code executes on > which thread, and passing information from one callback to another is > cumbersome as well.

Of course, this is the point of callbacks. The callback model tells us to reason using function arguments and function calls, so of course we can't map lines of code to threads, since neither lines of code or thread have any place in a callback model. Likewise for passing data between callbacks; the problem with threads is that everything is shared all of the time, which makes it incredibly difficult to enforce invariants. When using callbacks, everything is local by default and transfering data between threads requires explicit channels, eg. free variables.

In the actor model the safety comes from messages having no ordering or latency guarantees, so we can't assume that our data is always up to date.

With higher-level concurrency models we end up screaming at our IDEs as we try to contort our code to fit the paradigm. This is how it should be, since this means nothing's gone wrong.

With low-level concurrency models, the machine gladly accepts our dangerously broken code, the number of interleavings is so huge that our tests never hit an error case (or more likely, some of the bugs are so obscure that it never occurred to us to test them). Six months later the application explodes and as we sift through the pieces we find the true extent of the problem, and discover that subtley corrupt output has permeated through every aspect of the business and we can't anything that's been done since that code went live.

<comment><USER20> > the problem with threads is that everything is shared all of the time, which > makes it incredibly difficult to enforce invariants.

Your entire commet comes down to this, and my point is that this is not a problem. Design your threaded code around a simple principle: one thread's code must never touch another thread's data. Now you have safe threaded code. If you want to add some limited well-documented cases where you break that golden rule, go for it and reap the performance benefits.

There are some things that some threading models can be criticized for. For example, POSIX threads cannot be killed if they get stuck. However, threads are a powerful tool. The idea that you can share the in-memory code between all your threads is great. Additionally, you can share state and _you_ control how and when it is shared. Want complete isolation? Communicate via queues! Want some shared state for performance reasons? Go for it! Want complete and utter chaos that will blow up as soon as you look at it funny? Let threads access other thread's data at will.

Your argument is similar to one that table saws are terrible because one cannot guarantee that they will never cut off your fingers.

Edit: one other problem with callbacks. AFAIK, no implementation of callback- based concurrency is able to take advantage of multiple hardware cores for true parallelism. In the meantime OS schedulers already take care of distributing OS threads between CPU cores, and some green thread implementations do this as well.

<comment><USER22> So, you're not wrong ... but the table-saw argument is a straw-man.

There's a company that sells a revolutionary table saw with intelligent saw stop precisely because experienced, skilled practitioners regularly cut off their fingers.

In general "be smarter / do better" is not a reasonable prescription for large numbers of people. Empirically, if people are fucking up, it makes sense to analyze why and to give them automatic solutions to their fuck-ups.

<comment><USER20> I don't see it as a straw-man as I see threads as a tool. Existence of the actor model does not detract from the value that OS threads provide, the same way that existence of Common Lisp does not detract from the value that C provides. They are both tools. It's just that some tools are more dangerous than others. In other words, I don't believe that threads are a "worse is better" approach. There are things that can be improved about the specific implementations of threading, but on the whole, the paradigm is far from broken.

> Empirically, if people are fucking up, it makes sense to analyze why and to > give them automatic solutions to their fuck-ups.

The problem is that other implementations of concurrency are not as widely adopted and people tend to fall back on threads (especially OS threads) when they really don't need them. But when you really do need threads, very few things are a good substitute.

P.S.: I am aware of the table saw you refer to, and this is the kind of improvement that tooling around threads could use. Note that this new table saw does not completely re-design how you interact with the blade in order to provide the safety.

</comment></comment></comment></comment></comment><comment><USER23> Interesting. I'm attempting to do pretty much the same thing in C: [http://github.com/reginaldl/librinoo](http://github.com/reginaldl/librinoo)

<comment><USER24> Well done, man. Seriously. Every time someone starts talking about how x language makes it "easy" to do some kind of backflip, I start peering over the fence. Then someone almost immediately implements it in a C library -- or indeed, gets there first.

But have you given any thought to the critical and urgent problem of running 10,000 Actors, 10,000 Threads, and 10,000 Spaceships?

<comment><USER23> We often forget that even though this common problem of replacing callbacks is getting more critical and urgent, people already thought about it and gave some solutions. Maybe not in higher level languages (although I think Go does a great job there). In C, I have in mind glibc's ucontext for example. I'm trying to improve that through rinoo. So to answer your question, if you look at the wiki section you'll see test results I've done running 20,000 Actors. Of course, once you handle "actors" correctly (which should definitely be called fiber) you shouldn't use that many Threads (if too many you'll end up spending most CPU cycles scheduling your threads). However, rinoo handles multi-threading as well. I'm currently writing doc about it.

</comment></comment></comment><comment><USER25> concurrency --- albeit not at this scale --- is something that that you sometimes have to deal at a low level with when writing android apps. animating custom views, for example, often winds up involving direct use of Runnable s rather than (what i assume are) system-level AsyncTask s. a lot of the die-callbacks-die neatness on the java side of this relies on a coroutine library, but that library doesn't run on android. there is a continuation library that does > [http://commons.apache.org/sandbox/commons- javaflow/](http://commons.apache.org/sandbox/commons-javaflow/) which could be used to create coroutines and from there user-level threads

... but if we just want some generic kind of concurrency-niceness on a java virtual machine, might it make more sense to use scala rather than write your own lightweight thread library? is the user-space thread implementation really necessary or even helpful if you're abstracting toward actors anyway? do these questions even make sense to anyone?

<comment><AUTHOR> Quasar gives you fibers. On top of them you can build actors, Go-channels, or data flow variables.

Scala gives you no advantage here. None of its concurrency constructs really require Scala. There is no reason not to implement them in Java and use them in any JVM language. More specifically, Quasar actors are more general and powerful than Scala actors because they run in true lightweight threads and can block. Also, a lot of people don't like Scala.

</comment></comment><comment><USER26> Title: "...10,000 Threads..."

Post: "...10,000 Fibers..."

sigh

<comment><USER3> Edit "...10,000 Actors..."

Comments "...10,000 Co-routines ... "

;-)

</comment></comment><comment><USER27> We are working on a fully composable frame and concurrency is done as follows (upper-case = Object, lower-case = property):

AsyncRun ( part SomeObject )

multiple items can run in parallel like this:

AsyncRun ( part SomeObjectA SomeObjectB .. )

synchronization:

AsyncSync ( part AsyncRun ( part SomeObjectA SomeObjectB .. ))

locking a property:

AsyncRun ( part AsyncLock ( lockName = "someName", part = SaveUser ( ... ) ) )

On main thread (for UI/UX):

MainThreadRun ( part SomeObject )

</comment><comment><USER28> Looks very nice!

Does this play well with existing JVM threading support? More specifically, if there is a call to a synchronized method inside of a fiber and another JVM thread has entered the monitor, will this block the entire fiber scheduling thread?

The reason I ask is I'd like something that plays well with legacy code.

<comment><AUTHOR> A synchronized method would block the entire thread, but calls to ReentrantLock.lock, or any other java.util.concurrent class, can be turned from thread-blocking to fiber blocking.

</comment></comment><comment><USER29> Is this similar to green threads / "greenlets" in Python? They look to be the same concept.

<comment><USER30> One thing required for an Actor model that is missing from greenlets and Python in general is the ability to have isolated contexts. Basically, each Actor should have its own global state and shouldn't be able to share state with any mechanism other than message passing.

In Python with greenlets, state can leak between green threads through module globals and other module state.

<comment><USER29> Well, greenlets can and do have their own isolated contexts, but you're right, they can indeed leak state. Thanks for the clarification.

</comment></comment></comment><comment><USER31> And we nowadays have the hardware resources to run this on one CPU per spaceship, at least theoretically:

[http://blog.metaobject.com/2007/09/or- transistor.html](http://blog.metaobject.com/2007/09/or-transistor.html)

Needs some interconnect, of course...

</comment><comment><USER32> I think I'm being dense... can someone explain the difference between a 'blocking' fiber and Ada's task/rendezvous constructs? Both seem like synchronous message passing mechanisms?

</comment><comment><USER33> How does this compare with Grand Central Dispatch on the Mac?

<comment><USER34> I can't compare the principles by which they work, but in terms of which to choose, I think you will never have to make that decision, since GCD is only for (Objective-)C programs, while Quasar is only for the JVM.

</comment></comment><comment><USER35> I'm not a fan of this approach. I like what Go does with channels and I like what D does with synchronized functions. Its simple and powerful and no magic. Fuck magic.

<comment><AUTHOR> Quasar gives you channels just like Go: you can have primitive channels, you can select from several channels at once, or anything else you'd do with Go. As a bonus, it performs better than Go.

<comment><USER36> Have you published the benchmark source codes used for the comparison, anywhere? I am interested in figuring out the bottlenecks that make go perform worse.

</comment></comment></comment><comment><USER37> The other day some guys proudly re-implemented jemalloc in pure Java - [https://blog.twitter.com/2013/netty-4-at-twitter-reduced- gc-...](https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead) now these guys re-implemented a half of Erlang.)

Isn't it better (and bitter) to face the reality and just use Erlang or Go or at least to ask oneself why should everything be stuffed into JVM in 2013?)

<comment><AUTHOR> Go has nothing to do with it. The JVM is a superset of Go, and Go's strengths lie mostly in a short startup time.

Erlang is a different matter. We love Erlang. But the JVM ecosystem is not only two or three orders of magnitude bigger, but the JVM serves other requirements as well like excellent performance (performance is not Erlang's strongest suit, and more than a few Erlang projects require C code to meet performance requirements).

Some projects will be best served by Erlang, but many will benefit from Erlang's capabilities on the JVM.

In short – Erlang is awesome, the JVM is awesome, _extremely_ popular and very successful. Why not combine their strengths? We already have a full Erlang implementation for the JVM, and we think that Pulsar (Quasar's Clojure API) really brings together the best of both Erlang and Clojure.

There are many technical advantages to using the JVM, too. Because it has really good low-level concurrency constructs, you can implement state-of-the- art concurrent data structures in Java. This is downright impossible in Erlang, as in all pure functional languages. This is as it should be, because these languages work at a higher level. The problem is that BEAM, Erlang's VM, operates at the same level, too, so if you want to write a concurrent DS for Erlang you'll need to do that in C. It's a lot harder than it may seem, because many of these data structures require a good GC, and the BEAM the GC can't help because it only manages process-private heaps.

<comment><USER37> I am really appreciate your drive and effort, thank you for the reply.

In my opinion, however, as I could gather from the writings of mr. Armstrong, (one of) the fundamental problem with JVM is that it lacks a process isolation, and when it crashes, everything crashes completely. He explicitly pointed out this in his thesis - JVM cannot provide fault-tolerance due to being a mere user-level multi-thread process.

As a person who had experience of running huge Java crapware like Business Objects I could tell that yes, it crashes and it crashes often, and when it crashes there are situations in which there is no way to preserve data integrity and plain re-installation is required.

I am also not quite sure about any superior concurrency constructs which aren't based on OS primitives, but I am not Java guy.

Go is a way of doing things without a VM.)

<comment><AUTHOR> > In my opinion, however, as I could gather from the writings of mr. > Armstrong, (one of) the fundamental problem with JVM is that it lacks a > process isolation, and when it crashes, everything crashes completely. He > explicitly pointed out this in his thesis - JVM cannot provide fault- > tolerance due to being a mere user-level multi-thread process.

This is true in general, but not entirely accurate. When a Java thread crashes it doesn't bring down the whole JVM any more than when an Erlang process does. Just the one thread dies. With Quasar you get the same isolation for fibers.

It is true, however, that one thread in Java could negatively impact the performance of another by triggering a GC, while in Erlang each process has its own private heap. The Erlang approach (or the BEAM approach, rather, as its a feature of the VM - not the language) provides this isolation because Erlang was designed for systems where fault-tolerance is the number one concern. But it has its cost, too. The lack of a global heap makes it impossible to implement useful shared data structures, so Erlang provides some simple shared data-structures (like ETS) implemented in C, but those aren't garbage collected.

Also, the JVM has a big performance advantage over BEAM. That's why quite a few Erlang projects need to code some performance critical functions in C. But once you do that, you lose Erlang's isolation guarantees: a failed C function could bring down the entire application, and one that's stuck in an infinite loop _will affect_ the performance of other processes.

> I am also not quite sure about any superior concurrency constructs which > aren't based on OS primitives, but I am not Java guy.

You can start by looking here: [http://docs.oracle.com/javase/7/docs/api/java/util/concurren...](http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/package- summary.html)

None of these classes uses kernel mutexes or other synchronization mechanisms.

<comment><USER37> > When a Java thread crashes it doesn't bring down the whole JVM any more than > when an Erlang process does. Just the one thread dies.

I think this is inaccurate also.) Technically there is no memory protection from one pthread to another, so "crashed" pthread could damage shared data or the common stack. It is, however, not JVM's problem but of the pthreads as a concept, and Armstrong argued that only share-nothing architecture (process- based) could be fault-tolerant, and pthreads are just "broken by design".

<comment><AUTHOR> True, but this is not black-and-white, but a matter of degree. Erlang processes also share memory: ETS. A crashed process could well leave an ETS table in an applicatively illegal state. So isolation is a scale. With Quasar we try to tip the scale closer to Erlang's isolation levels, but, as I've said, shared data structures could be extremely useful, too.

If fault-tolerance is your most important requirement, that far exceeds in its importance any other requirement, then by all means use BEAM. It was designed for precisely that kind of application.

If, however, fault-tolerance is just one of several important requirements, then the JVM will be the better choice in many circumstances.

</comment></comment></comment></comment></comment></comment><comment><USER38> I think the approach is interesting but I don't understand how this considered theoretical. 10,000 elements for an N-Body problem is expected.

What I am more confused about is how this considered peak optimization.

Assuming they are utilizing doubles and doing both read and write I get the following computation:

(10000x10x8x2 bytes per second) or 12 Megabits per second vs the theoretical bandwidth of a PCIe of 40 Gbs?

Are they computationally limited and what is their memory access pattern?

<comment><AUTHOR> This is far from an optimal simulation, because the framework is so general. The spatial database gives you true isolated transactions that require (fiber- blocking) locks.

In fact, the code is very naive, and that's our main point. Even naive code can scale well with this approach. We care more about scaling than sheer performance.

So your calculation is wrong, as we're not trying to approach a theoretical limit (which would require optimizing the algorithm) but to demonstrate scaling of a naive algorithm. For example, instead of a single spatial join, each spaceship queries its surroundings: this is asymptotically (n^2 vs n) worse than a single join.

</comment></comment><comment><USER39> >On my 4-core (8 virtual cores) i7 MacBook, with 10,000 spaceships, I get close to 10 simulation cycles per second. [...]

> When running the simulation synchronously, i.e. with a phaser, performance > drops to about 8 cycles per second on my development machine.

> Performance – we are able to fully exploit the computing power of modern > multi-core hardware.

So, 25% faster with 8 cores is "fully exploit the computing power of modern multi-core hardware". WTF?

<comment><USER40> When he says he's using a phaser, he means that updates happen in lockstep. Each update still happens on multiple cores, but each fiber will not move on to the next update until all of the other fibers have finished the current update.

So it's not synchronous in the sense that it's running everything sequentially.

<comment><AUTHOR> Exactly. Still parallel, but don't start the next cycle until the previous one has completed.</comment></comment></comment>


It was raining in the data center - <AUTHOR> https://medium.com/s/story/it-was-raining-in-the-data-center-9e1525c37cc3 <comment><USER2> And the article went on, and on, and on...

As for their humidity problem, the article says little about how their badly designed chiller-less system got into a condensing situation. The original article in the Register does.[1]

This was an HVAC configuration error. The facility used evaporative cooling, which dumps heat into water by running air through a water spray or some wet surface. This raises the humidity. They somehow got the system configured so that it was recirculating air through the evaporative cooler, increasing the humidity on each pass until it hit saturation. The problem only lasted for a few hours until somebody figured out what was wrong.

They probably didn't have a union-trained stationary engineer on site. This sort of thing is covered in the apprenticeship training for a stationary engineer. Fans, dampers, and controls can all fail, which can create situations like this. Stationary engineers deal with those problems. At large data center scale, you may need one.

[1] [http://www.theregister.co.uk/2013/06/08/facebook_cloud_versu...](http://www.theregister.co.uk/2013/06/08/facebook_cloud_versus_cloud/)

<comment><USER3> it went on and on and on because the article isn't actually about the cloud in the data center.

<comment><USER4> It's not really clear what this article is about

<comment><USER5> It's a poem.

Edit: It's a mediocre poem.

</comment></comment></comment></comment><comment><USER6> > like a thunderstorm formed from two opposing weather fronts, the physicality > of outside Prineville air met the everywhere-ness of inside space in an > impossible, non-Euclidean intersection

Not every word is a pretty one you can throw around, you know: what exactly about this metaphorical meeting was "non-Euclidean"?

<comment><USER7> The metric that connects data centers is not Euclidean. There are some names of that metric but for that story the name "railroad metric" might fit best.

</comment></comment><comment><USER8> Of course the article isn't about the actual cloud in the actual data center.

Pipkin is a code artist, this is essentially a philosophical musing, but of the continental kind, with importance given to phenomenology, with thought on metaphilosophy and suchlike, with philosophy given as first science.

This kind of author specializes in deeper critique in that continental style. Most such works are technically worthless, but that is not the point.

<comment><USER9> It isn't just technically worthless, it is technically wrong. I know that none of it is even the point, but that's where the article loses itself: there is no point but to make an appealing critique of nothing in particular.

It isn't even wrong.

</comment></comment><comment><USER10> This seems like an egregious oversight to me, no one thought about controlling the humidity levels in this carefully climate controlled server farm beforehand? They used evaporation cooling to lower energy costs which ideally would saturate the air up to near 100% humidity in order to work best, how would you not know taking that air directly would result in water and humidity problems? They likely had multiple engineers working on climate control by itself, someone should have foreseen it.

</comment><comment><USER11> The article reads as if it was as procedurally generated as the bizarre graphics included.

</comment><comment><USER12> The much better (and probably worthy of a modern spiritual successor, which this article is not) version of this theme is Neal Stephenson's excellent "Mother Earth Mother Board" from a 1996 issue of /Wired/:

[https://www.wired.com/1996/12/ffglass/](https://www.wired.com/1996/12/ffglass/)

</comment><comment><USER13> Shitty title for what I felt was a really great read.

Actually, it honestly reads like a prequel to Asimov's short story, "The Last Question". [1]

[1] [http://www.multivax.com/last_question.html](http://www.multivax.com/last_question.html)

</comment><comment><USER14> This article was a bit frustrating. It has a bunch of interesting threads it never follows to the end or ties together.

</comment><comment><USER15> I'm always amazed when I think of a big data center in Prineville. I'm currently reading a book on the history of the area: [https://amzn.to/2KLxqyM](https://amzn.to/2KLxqyM) , since I live down the road in Bend. Pretty much your basic small western town, with native americans, range wars, and a murderous group of vigilantes in its past and a popular rodeo in this day and age.

Nice place to visit if you ever get the chance, on the way to the Painted Hills for instance.

</comment><comment><USER16> Speechless (occurrence year 2011). Was it really just lack of appropriate personnel or design flaw. I just can't get that information out of the article. Someone cut corners.

Now, the article lacks focus. It expands unecessarily on every tangent (it reached ARPANET -- drops mic). 2 or 3 pages could have been 2-3 paragraphs or references. This article lacks an editor. (Or they are payed per page -- I think it is word count actually.)

The author could state: they pick remote locations, because it is cheap and away from publicity (power hungry) and less likely to become a target. Then argue and clarify with some details. Then go to the destructive events perhaps.

Like many others, I am not sure of the goal of the article to be honest.

</comment><comment><USER17> This reminds me of something that happened in our on-site datacenter at a former employer of mine. It wasn't raining inside, they were just doing routine maintenance on the cooling system. Somehow, they managed to dump all of the cooling water into the offices (which were not ours) in the 2-3 immediate floors below. Needless to say, there was an emergency shutdown as the datacenter overheated. It was definitely an all-hands scenario as we got ready for market open the next day. I think I crashed around 4am-5am after my servers were back up and checked out.

<comment><USER18> I had my small basement (shared with the print department) computer room flooded in London - this was the second room the one before was flooded and was repurposed as a printer room - it still had the flood marks on the wall.

</comment></comment><comment><USER19> Just noticed on the fiber map contained in the article that there isn't any fiber in Michigan's upper peninsula.

How is that even remotely possible? It appears that it runs up to to Mackinac City and then stops short of the bridge. The map doesn't even show the U.P.

I was at a tech conference once that had attendees states on their badges. A lady came up to me and said how cute you've got a deer jumping over the state of Michigan on your badge. Told her that's not a deer, it's part of the state ;<).

</comment><comment><USER20> This article is very strange, and lacks a cohesive narrative. It meanders willy-nilly. I stopped about half way through.

Also, the graphics are really bad, and completely distract from the already questionable piece.

<comment><USER21> It is classic postmodern text: it is supposed to look well informed, intelligent, but it lacks any coherent meaning. Simply fashionable nonsense.

</comment></comment><comment><USER22> They have a link to a study of the major internet routes in the US and the name of the PDF is 'tubes_final.pdf'

That made me laugh.

"Long-haul fiber-optic cabling. Red squares mark where cables connect in nodes, many in major population centers. University of Wisconsin and ACM SIGCOMM, 2015. [http://pages.cs.wisc.edu/~pb/tubes_final.pdf](http://pages.cs.wisc.edu/~pb/tubes_final.pdf) "

<comment><USER23> Link is dead

<comment><USER24> It's because of the quotation mark. If you remove it, the link works as normal.

[http://pages.cs.wisc.edu/~pb/tubes_final.pdf](http://pages.cs.wisc.edu/~pb/tubes_final.pdf)

<comment><USER22> Fixed, thanks for catching that

</comment></comment></comment></comment><comment><USER25> TL;Dr version - author takes an article on data centers, an article on long haul fiber, and an article on the structure of the Internet and puts it into a blender.

It is kind of too bad since two of the three articles haven't had a lot of good coverage. One being alternate cooling strategies for data centers, and the other being disrupting the moats that long haul fiber imposes.

</comment><comment><USER26> I didn't understand the graphics

</comment><comment><USER27> IIRC: to meet the "redundant fiber" requirement, one of the backbone carriers needed some incentives to build out into the middle of a desert.

</comment><comment><USER18> Not sure the fact that cable runs next to train tracks - railway tracks are built on the easiest routes.

In the UK there are canals trains tracks and motorway running next door as the geography suits.

<comment><USER28> It definitely follows the tracks. Using existing tracks provided to major advantages: the railroads already had the right-of-way, and it was relatively affordable to lay the fiber by equipping a locomotive with a special trenching attachment. (A fiber optic rail plow).

</comment></comment><comment><USER29> That's the longest article ever. What's TLDR? Facebook data center produced a cloud within it?

</comment><comment><USER21> > Furthermore, much of this energy consumption is generated by coal — even > 'green companies' will often buy carbon offset credits rather than invest in > the energy storage required for 24/7 solar or wind power.

Plain bullshit. One of the reasons Facebook and Google have datacenters in Oregon (FB at Prineville and Google at The Dalles) is the availability of cheap renewable energy from the Columbia River.

And the companies don't buy carbon offset. The author has no idea how electricity markets work. They buy renewable electricity contracts, for example:

[http://www.datacenterdynamics.com/content-tracks/power- cooli...](http://www.datacenterdynamics.com/content-tracks/power- cooling/google-buys-up-62mw-of-dutch-wind-power/91896.article)

The author seems more preoccupied with the sesquipedalian loquaciousness than with actual facts.

<comment><USER30> I was at Google and they did buy offsets from 2007 until after I left. Not for Oregon, sure, but definitely for places like the Carolinas (our good old friends at Duke Energy...). It was only in 2017 that they covered 100% of corporate/datacenter electricity with actual contracts.

</comment></comment><comment><USER31> Those graphics were...interesting.

<comment><USER32> Are they from some sort of scientific simulation? As graphics, they look terrible. I hope they have some sort of value outside aesthetics.

<comment><USER33> They reminded me very much of the artwork that accompanied 17776: [https://www.sbnation.com/a/17776-football](https://www.sbnation.com/a/17776-football)

<comment><AUTHOR> that was strange

<comment><USER34> .awesome you mean

</comment></comment></comment></comment></comment><comment><USER35> Is there some astroturfing happening with this link? It's at the top of HN with 60 points, only two actual comments about the content, and I personally couldn't find the point of the article.

Was is just a survey of interesting datacenter phenomena? I'm still not sure.

Edit: Amusingly this post had a bunch of points and now they're gone. Maybe people don't find this comment interesting, or maybe the people who were manipulating the vote didn't like getting called out. One shall never know I suppose.

<comment><USER36> Yeah this post reeks of vote manipulation. The article was strange and droned on and on.

</comment></comment><comment><USER37> > You've reached the end of your free member preview for this month. Become a > member now for $5/month to read this story and get unlimited access to all > of the best stories on Medium.

Ugh. I didn't realise that Medium had become another paywall.

<comment><USER38> Not surprising. It became useless a while ago. It will be a shame the content will be lost when they go under which probably won't be very long.</comment></comment>


Always Be Closing: The Tale of a Go Resource Leak - <AUTHOR> https://medium.com/square-corner-blog/always-be-closing-3d5fda0e00da <comment><AUTHOR> > One is that Go's conventions around not ignoring returned errors and cleanup > functions exist for good reason and should not be casually ignored.

Murhpy's law. People are generally unreliable to ensure and maintain this kind of consistency. If every call to "A" requires a call to "B", try to offer an abstraction (sorry, bad choice of words)... a _pragmatic way_ to deal with the whole "AB" thing as a single step, especially if you can do it in the same lexical scope (RAII, try-with, etc.).</comment>