How to Control Microservices Costs - <AUTHOR> https://www.parkmycloud.com/blog/monolith-to-microservices/ <comment><USER2> Microservices? Turn and walk away if you still can. The real costs will come from developer time spent doing pointless, pointless chores.

<comment><USER3> How so? This hasn't been my experience.

</comment></comment><comment><USER4> Quick summary for those who read the comments first:

1) If you have an existing monolith that you want to convert to microservices, don't rm -rf your project in order to start from scratch.

2) Keep each microservice extremely limited in scope.

3) Try to avoid paying for resources that you are not using.

4) Have certain users and departments be responsible for specific parts of the system.

In other words, two simple steps:

1) Don't be a complete moron.

2) Avoid accidently getting your genitals stuck in a fan while implementing standard microservice practices.

This article is nothing but dot points of what defines microservices with loads of advertising thrown in.

You're welcome.

</comment><comment><USER5> I would recommend the author remove the automated live chat on this website trying to sell me their services. There's nothing I hate more than trying to read an article and getting a fake chat notification.</comment>


Adding Up the Cost of Tax Breaks for Big Tech's Data Centers (2016) - <AUTHOR> https://nextcity.org/daily/entry/report-tech-data-center-subsidies <comment><USER2> This is similar to the criticism of a pipeline that's been planned for many years in America called Keystone XL. It's proponents claim it will create thousands of jobs. It's detractors say that most of the jobs will be temporary and once the pipeline is built, only 50 employees will be required to run it.

But this ignores one important fact. For plumbers, welders, electricians, bricklayers and crane operators, _every_ job is a temporary job. Building that pipeline or datacenter employs them only for a couple of years, but pays them good money for work that is satisfying to them. When these reports choose to look only at permanent jobs, it explicitly ignores blue collar workers in favour of white collar ones.

The calculus for politicians is different from those who write white papers for think tanks. The blue collar workers vote. Simple as that.

<comment><USER3> One way or another, that landlocked oil in Alberta will make its way to market.

If the US doesn't want it, it will get pipelined to the Pacific coast and tankered to Asia or sent by rail within North America or to the Pacific.

I think Keystone XL's real detractors are US oil producers. It's real proponents are oil consumers that (clearly!) could not care less about where the oil comes from.

<comment><USER4> > One way or another, that landlocked oil in Alberta will make its way to > market.

That's not necessarily true. The point of the capital investment in the pipeline is that the overall cost will be lower than shipping it from the pacific. If the pipeline doesn't exist, it may not be economic to mine the tar sands (this is especially true for tar sands oil which is very expensive (== itself consumes a lot of energy) to extract, so is only viable when oil prices are quite high.

> I think Keystone XL's real detractors are US oil producers.

Some of them, but the majors are integrated and having an alternative supplier to feed their refineries is good for them.

The other source of opposition is people who don't want to deal with the externalities: the pipleline itself, of course but more importantly leaks. Keystone's other pipelines leak and there's no reason to believe this one should be any different.

<comment><USER3> > The point of the capital investment in the pipeline is that the overall cost > will be lower than shipping it from the pacific.

Lower, maybe. But transoceanic shipping is cheap and gives you far more flexibility in sending to whichever customer will pay the most.

> If the pipeline doesn't exist, it may not be economic to mine the tar sands

The current problem is that the capital investments in the extraction infrastructure have already been made. It's cheaper to continue operating them at a loss than to shutdown entirely. If the operations go bankrupt, they'll continue operating when a buyer can take over without any of the previous debts.

It's at the point where it's taking government intervention to get the extractors to reduce production. The most economical decision for them is still to flood the market with production.

It's like the Worldcom fibre infrastructure constructed in the 1990s. It was a terrible investment, but once it's built, it's not worth turning off.

> the majors are integrated and having an alternative supplier to feed their > refineries is good for them.

If they're integrated and have a balanced production and consumption, a pipeline from somewhere else throws a wrench into that.

> externalities: the pipleline itself, of course but more importantly leaks. > Keystone's other pipelines leak and there's no reason to believe this one > should be any different.

Pipelines will always be the best way to move bulk liquids from A to B. There are also externalities to oil-trains and more expensive oil.

</comment></comment></comment></comment><comment><USER5> How come this is legal in the US? It's extremely unfair toward other businesses that are too small to coerce the government to make a tax exemption for their individual business. To me, it seems to create inequality before the law.

I don't think the officials handing out the tax breaks have bad intentions, but the system itself seems corrupt.

<comment><USER6> It keeps amazing me too. A state (or any other local government) shouldn't be allowed to subsidize individual businesses, nor whole industries. Allowing it just means businesses can play states out against each other and it becomes a race to the bottom. The EU solved it. The US could too.

Sometimes in the discussion about this I get counterarguments about how it's a "win win" (company gets subsidy, area gets jobs) or how it's a net gain for the area (without the subsidy you get nothing, and with the tax break you get the jobs so at least it's something).

<comment><USER7> Yeah I agree. This seems to be a corruption that's been with the US since our inception tbh. There's been this generalized idea that "government = bad, business = good" and to that end we've relied heavily in our development on companies to build the country. One can take railroads in their early days as a prominent example or frontier settlers who were literally paid to go build cities out west.

It seems part of the problem is we're in a new world where such subsidies are counter productive because too many people rely on them. In this case, it shouldn't even be legal to use taxes to subsidize any singular private businesses -- and those that require subsidy to function should be nationalized (they're not functioning on the market system).

<comment><USER6> It's probably illegal to subsidize directly (?), but by using a negative subsidy through "tax breaks" or other incentives it's circumvented I assume.

<comment><USER8> The legality possibly derives from it not being directed to a specific company directly, but by offering a tax break to _any company_ who satisfies the criteria that has been tailored to fit only one or a few companies.

</comment></comment></comment></comment></comment><comment><USER9> Examples like this make me appreciate the European Union's strict rules around state aid - which do a lot to eliminate beggar-thy-neighbour competition between countries, preserve tax bases to actually provide services and infrastructure to citizens, and hinder companies from playing off country against and city against city.

(That said, they're not perfect - witness Irish tax law as a prominent example)

<comment><USER10> Worst than the Irish tax system is Luxembourg's and that one has been around since the 70s. Plenty of US corporations- like Wall-mart, Amazon- have subsidiaries in Luxembourg

</comment></comment><comment><USER11> If I give a company $100M in tax breaks to come to my city, and they end up paying $50M in tax (instead of $150M), the outcome was financially positive as the alternative was that they don't come and my tax revenue is $0.

<comment><USER12> Okay.

But why just Amazon?

What about hundred Joe's Car Shops and and a hundred Betty's Diners and a hundred Sue's Tech Startups?

Does not the same calculus apply to them?

What about an up and coming competitor to Amazon that would have provided even more jobs, had the government treated them fairly?

Should we not be equals under the law, having the same requirements, receiving the same punishments, paying according to the same tax code?

If Amazon can negotiate different tax laws, should it be able to negotiate more lax employment requirements, or lower speeding tickets, or more voting rights?

I'm as staunch a low-tax and pro-business libertarian as they come, but for everyone, not just for the government favorites.

Equality under the law.

<comment><USER13> It's not just Amazon. Tax incentives are very common and lots of companies get them. It's very, very uncommon for a tax break to apply only to one specific company.

<comment><USER12> Alright. Then (1) write that rule down and (2) call those writings "the tax code".

Then everyone knows the rules and the outcomes.

This onsies twosies business of choosing who pays one on a case-by-case basis is ripe for bribery and inequity.

</comment></comment></comment></comment><comment><USER14> Government policies related to job creation don't help workers.

They could have used the money to help bootstrap small entrepreneurs but instead, most of that money ends up directly in the pockets of large shareholders and executives. Those few workers who do get some of that money are basically enslaved to these corporations. If a company pays you so little and there are almost no other employment options available for you and you can't afford to lose your job with that company; that's basically slavery.

</comment><comment><USER15> The local government seems to disagree: [https://www.newsobserver.com/news/business/article214062219....](https://www.newsobserver.com/news/business/article214062219.html)

</comment><comment><USER16> Are municipalities really this stupid, or are these articles missing part of the picture?

<comment><USER17> Yeah, not a great article and doesn't seem concerned with the "why."

A couple of possible explanations:

1\. There are beneficial effects other than tax revenue - maybe these municipalities are hoping the new data centers will help turn them into hubs - draw other businesses, talented workers, etc.

2\. The decision-makers' incentives aren't well-aligned with those of the municipality. Maybe the local business owners who fund their campaigns benefit disproportionately from these big projects. Maybe the headline of "brought Apple to North Carolina" outweighs the actual, harmful effects of the deal they signed when the next election comes around, etc.

<comment><USER18> I knew people at Google that travelled to data centers very frequently. There are all sorts of indirect extra business and tax revenues from these operations that aren't tied to local employees alone. Mine is just a small example, but there are more. Even with good baseline data, it might not be trivial to assess the full economic impact of one of these sites.</comment></comment></comment>


Ask HN: How would you spend $1-2K a month in marketing/ads for a web app?  - <AUTHOR> We have a web app/service (http://nextproof.com) that is about 18 months old. It has a solid user base, a steady number of signups, and is profitable. However, most of the signups are coming from existing customers of our other services (we offer it when they signup).
I'd like to start bringing in new customers directly. I've set aside $1-2k per month for marketing, ad campaigns, etc. Anyone have creative suggestions on how to spend this money?
Ideas so far include:
- AdWords
- Facebook ads
- Niche ads on industry-related sites, blogs, and forums
- Paying someone to blog steadily
I also don't mind spending on related tools and apps. I'm looking into things like Kissmetrics, AdGrok, etc. <comment><USER2> I would look into a referral program. Offer your existing clients $50 - $100 for every new member they refer.

To take it one step further approach popular photography blogs and offer them the referral deal. Most of the large camera / photography blogs are already making their money through affiliate programs so there is a good chance they will be interested.

<comment><AUTHOR> Good idea, I forgot about that.

</comment></comment><comment><USER3> Look up the demographics of your users that bring in the most money. Are they professionals? Are they students? How did they find you? See if you can tell how most of your purchasers are coming to the site. Facebook? Google? Direct links?

Use this to get some idea of where to start. Might be smart to invest some money in increased ad spend where your high volume sellers are coming from.

Alternatively, cut directly to the people you're interested in. Virtually every university sustains some kind of picture taking business, at OU it was <http://partypics.com> \- they go to all the parties and events and then sell their pictures online and do well enough at it to stay in business. Target these companies to become their exclusive ecommerce provider. A single one may seem small, but there are thousands of universities just in the US.

Draft a nice sales letter and send it to every college photography business you can find.

Seach google for wedding photographer + area and harvest addresses or phone numbers. Assault them all with sales letters and calls. Start actively reaching out, don't just place an ad and sit back.

After you've started making calls and sending letters, start split testing headlines and opening paragraphs. Always ask yourself "How high is high?" Don't settle for a 10% ROI even if it pays your bills.

</comment><comment><USER4> In my opinion, you have the ideal product for advertising on photography websites and blogs. Your ad dollars will go _much_ further than with AdWords in my experience, with a much lower CPC. I am a big, big fan of being able to reach pre-qualified buyers like that with direct ad placements.

<comment><AUTHOR> Yes, I agree and we have done that in the past. Our app is mainly gear towards wedding and portrait photographers.

The main problem I run into is that people with popular blogs in our industry (a) charge a lot for ads and (b) are likely to use a competing product. Should I be worried that they aren't dogfooding what they're peddling?

Should I try to negotiate some type "Pay Per Signup"/affiliate program with sites?

<comment><USER4> I'm not being snarky but if A and B are your experience, you're doing it wrong.

Let's say Popular Website A can give you 100,000 views and charges I dunno $35 CPM. Less Popular Sites B, C and D may only be charging $10 CPM, and you can get the same number of ad views in aggregate by placing ads across all of them. You'll have to work harder to _find_ them, but I generally assume people who have no money have a lot of time when it comes to marketing.

As an example, I know of a site for wedding photographers with good numbers that will give you an entire _year_ of sidebar ad placement for $275. (Drop me a mail on my contact form, I'll send you a link.)

To answer your other questions, don't worry about the dogfood at all. And no, affiliate prgrams are really hard to sell to individual site owners; they're generally not setup for it, don't understand it, and don't think it will work. The sales cycle on your part is way too long.

</comment></comment></comment><comment><USER5> Hey Callmeed, I'm a huge fan of not paying for advertising. Use that money to reinvest into your product, make it something people want to blog about, or advertise.

Here's what I'd do

1\. Create a product that is brilliant to use, and something that professionals on Flickr, or other stock photography sites use. I know this is obvious, but it's crucial to the plan I'm laying out.

2\. Contact professional photographers, or photographers with large social media followings. See if they use any existing services similar to yours, see why they use them, work with them to get them users of yours.

3\. If they're currently not using any, or if their using one and you've successfully integrated what makes them use it, proceed!

4\. Partner with them! Partnerships = way better than spending money on advertising, in my opinion! Offer them 100% profits for x months, or waiver fees, that sorta stuff. Feature them, make them feel special. In return, they should promote their photos to their fan base, blog, twitter, facebook, whatever.

I'd also do what SHOwnsYou said, and pitch to all local businesses, and photographers. But most of all, I'd find blogs and sites with the your TARGET AUDIENCE and get them to do the advertising for you. This could be a giveaway (which is basically free advertising / awareness), or convince them to post about you because it benefits their readers.

</comment><comment><USER6> I've used <http://buysellads.com> with mixed results. Lots of sites on there, but mostly with a tech focus. The CPM's and effectiveness of the ads vary quite a bit (from crap to very good), so it's worth digging around to find some good cheap ones. And as always, track everything.

</comment><comment><USER7> I am not a Marketing Guru but, I would suggest you to have referral system and Free plan and restrict usage of your core service. In your case, I would restrict the number of photos user can upload every month.

This way users will get change to use all the features of your app and if it works for him, he can upgrade his account.

Word of mouth is another best marketing channel.

Also, you can sponsor bloggers and in return they will advertise your product. Eg. TutsPlus.

</comment><comment><USER8> Check out <http://www.ProjectWonderful.com> It's an auction-style online advertising site, used heavily in webcomics (but you can find ads on all kinds of sites).

</comment><comment><USER9> None of above. Marketing is about reflecting your USP and solving your problem effectively (and communicating it. I'd rather spend that money improving the app and providing good support.

Word of mouth generated that way (slow but most powerful) will be AWESOME!

<comment><AUTHOR> I understand what you're saying but I should be clear that this money is not taking away from our development budget. We have an ongoing list of new features based on user feedback and we're putting development efforts towards it.

As for support (and not to brag) but our main company has one of the best customer service reputations in the photo software/online tools arena.

<comment><USER9> That should be enf in itself then. Now you can go social (fb, twitter) and do some give-aways etc. Let your users have fun with you. Best marketing ever.</comment></comment></comment>


Postgres, NoSQL, or other... - <AUTHOR>

I am writing an application which stores content (usually text, images, links, etc) and is highly relational (content can be associated with other content and queried as such).
An example would be fetching the 10 most recent submissions by a specific user, sorted by "rating" number which is also associated with a piece of content, as well as all content which has been related to each returned piece of content.
IE Bob requests the 5 most popular data points he's published and all the associated images/links/etc.
I am currently using MongoDB, and have had no issues, but after doing some research, I'm considering switching to an amorphous Postgres implementation where there are only 2 tables, a data table and a relationships table, with Memcached keeping some of the higher level requests precached for quick fetching.  This should keep my schema from the application's perspective highly flexible.
I know it's apples and oranges, but would anyone be willing to offer maybe some of their own experiences with similar setups that might help me determine if this is a good decision?  My main reason for looking into migrating away from MongoDB is write speed and data volatility.  I don't want to ever lose data if possible, and I understand that Mongo has table level locking when writing (is this true still?)
If anyone has any advice on the performance/reliability implications of either or both options, or if anyone thinks there's an even better 3rd option I haven't considered, I would be very interested to hear!
Thanks so much! <comment><USER2> If you're using that kind of schema you won't be getting any of Postgres' advantages. Obviously it has a pretty good reliability reputation, but I'd be very cautious about switching to Postgres because you're going to be making a lot of work for yourself.

If you're worried about performance, benchmark it (or find someone who has). On the reliability side there are plenty of NoSQL options with better reputations than MongoDB. My first thought is neo4j, but I don't really know enough about your particular problem.

<comment><AUTHOR> Thanks for the reply. From what I understand, the schema I described is similar to what Reddit uses in their Postgres setup. You mentioned that I "won't be getting any of Postgres' advantages", what are some of the most important considerations that play into Postgres strengths? What are the primary advantages you for Postgres your referring to?

Thanks!

<comment><USER2> I meant just in terms of Postgres expecting a "standard" relational schema; the interface and query planner and the like are designed around that. It's not a _bad_ schemaless data store per se, but it's not really designed for that use case, so I would expect rough edges when using it that way.

The modern selection of schemaless data stores weren't as mature (if they even existed) when Reddit was getting started, so don't assume that they would choose that architecture if they were starting today. I suspect that if you build on postgres in this way you'll have to write significant pieces of functionality by hand that you get for free with mongodb/couchdb/redis/neo4j/etc.

That said I'll emphasise again that I don't know too much about your system; at some point, prototyping and measuring will be the only way to see what works best for you.

</comment></comment></comment><comment><USER3> you should start from giving some numbers i.e. you want it to work for 10mil documents, how ofter they will be updated etc.

if it's less than 1mil and they are not updated frequently, you should go for postgres and have some fun with SQL,

more data and increased concurrency means problems also in postgres, a lot of optimizing, materializing views and other fun problems to solve.</comment>


Tesla dropped by Mobileye for "pushing the envelope in terms of safety" - <AUTHOR> http://arstechnica.com/cars/2016/09/tesla-dropped-by-mobileye-for-pushing-the-envelope-in-terms-of-safety <comment><USER2> Most of Tesla's issues are with the name. Drivers assume this is a fully autonomous driving system. This leads to big problems. I have seen videos of drivers sleeping while the car drives itself down the highway.

A more appropriate name would be co-pilot.

<comment><USER3> I never understood how the public decided that "autopilot" means a fully autonomous system. I grudgingly admit that some people think this way, but how did it happen?

<comment><USER4> To me it clearly means that the system is autonomous while the autopilot is on. What else should it mean?

<comment><USER3> Real-world autopilots cover a wide range of pilot aids, down to something as simple as a gyroscope mechanically connected to the rudder in order to automatically hold heading. Most are more capable than that, but typical autopilot features would involve holding heading, altitude (or rate of climb/descent), and speed, or navigating towards a particular point. Fully autonomous autopilots are extremely rare, and I'm not aware of any commercial system where the pilot is allowed to ignore the airplane while the system is engaged.

So, again, how did you get this idea?

<comment><USER5> _> So, again, how did you get this idea?_

Because, as JonnieCache pointed out, the colloquial definition of Auto Pilot is more informed by entertainment than by the aerospace industry.

What's more baffling is why anyone would assume that the average person knows what "auto pilot" means in an aerospace setting. I mean, why in the world would that be common knowledge? In fact, I've seen enough bone-headed assertions about collision avoidance capabilities of modern aircraft that I'm pretty certain even people who think they know what auto pilot means, actually don't.

FWIW you can test this by finding people outside of the tech echo chamber who don't know what a Tesla is and asking them to describe the capabilities of a car with an Auto Pilot.

<comment><USER3> You're not answering the question, you're just repeating the basis of it.

 _I accept that people think it means it 's autonomous._ Stop repeating that as if it were new to me. What I want to know is _why_ people think that. "Because everybody thinks that, if you'd bother to ask them" is not an answer to that question.

<comment><USER6> "Because entertainment commonly portrays it as such, and few people are familiar with the workings of pilot aids installed aboard commercial aircraft" _is_ an answer to that question. Perhaps it is not one you like.

Perhaps also it is not one which is accurate. I'm not really familiar with a lot of entertainment that includes this trope, which is not necessarily a surprise; what _is_ a surprise is that TV Tropes, which is generally very detailed on such matters, doesn't seem to have anything covering it, either. That certainly suffices to inspire some doubt in my mind as to whether "oh, it's just entertainment" is an accurate answer, or a just-so story.

<comment><USER3> When I asked for examples in another comment, the replies (so far) have been sci-fi movies. I'd hope that people aren't inferring real-world capabilities from sci-fi movies, but they very well could be.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> I mean, this doesn't really seem like the grandest news. It could've been safely inferred based on the releases at the time: [http://www.wsj.com/articles/mobileye-ends-partnership- with-t...](http://www.wsj.com/articles/mobileye-ends-partnership-with- tesla-1469544028)

> Mobileye said it would no longer provide its computer chips and algorithms > to Tesla after a current contract ends due to disagreements about how the > technology was deployed.

But it's good to have the exact reason Mobileye decided against renewing the contract in writing. I'm still keen to see how Volvo's system ends up since they (if I recall correctly) are the only car company which has so far indicated they would accept responsibility for incidents caused by their driverless system: [http://www.bbc.com/news/technology-34475031](http://www.bbc.com/news/technology-34475031) \-- hopefully this'll compel their engineering teams to focus more on safety rather than MVP.

I do wonder whether both Tesla and SpaceX are seeing the issues they're seeing because of the abysmal work-life balance at both companies. Great successes on both sides, but there are increases in risks of catastrophic failure in products from both companies which have already been realized. I'm sure work life balance isn't the only reason, but it wouldn't surprise me if Musk's inability to personally burn out isn't actually shared by the vast majority of his engineers.

<comment><USER8> Volvo's stated goal is improved safety on the road, both for the car's occupants and for other road users. Volvo are not adding sensors to make driving more convenient, they are adding sensors to make driving safer. The whole Volvo brand is built around feeling safe.

</comment></comment><comment> the-dude See also the fatal crash in China just popped up today ( crash is from january ) : [https://news.ycombinator.com/item?id=12504888](https://news.ycombinator.com/item?id=12504888)

<comment><USER9> Wow is it me, or is that cleaning-car on the far-left lane of the highway not being very dangerous by cleaning there with such a slow speed? In the Netherlands the whole lane would be dis-allowed to drive on if there was work going on there.

<comment><USER10> Any slow moving vehicle on a high way is a hazard to other vehicles. Maybe that's a normal thing in China, but definitely not in Toronto. Judging from the video, the warning light from the cleaning truck was not sufficient even for human driver.

</comment></comment></comment><comment><USER11> What will happen when "autopilot" turns off because the driver ignores notifications? Could that cause more issues? It's good that the cars will use sensors around them better, but turning off the assist function may have some fatal bugs.

<comment><USER12> A vehicle without driver aids and with sudden loss of driver inputs would tend to idle down the road until it hit an object sufficient to stop movement, or ran out of fuel, or the engine stalled for some reason.

A better response to lack of driver input would be to come to a controlled stop, preferably out of the traffic lanes (since other Tesla vehicles have driver assistance technology which may not respond to a stationary vehicle in the lanes)

</comment></comment><comment><USER13> In an interview George Hotz said he told Elon to drop Mobileye. George is repeating how bad that company is.

So it seems not only Tesla thinks Mobileye can't keep up with safety. Others noticed this too.

<comment><USER14> "No matter how you spin it, (Autopilot) is not designed for that. It is a driver assistance system and not a driverless system," Shashua said. This implies that Tesla's customers were not using the system as designer and possibly didn't want negative publicly of such affecting its business

The article never stated anything about Tesla dropping Mobileye either but implied the opposite.

<comment><USER15> "According to a Tesla spokesperson in a statement sent to Electrek today, Mobileye tried to convince Tesla to keep using its system for future generations of the Autopilot, but when it became apparent that Tesla was sticking to its new in-house system, which the company confirmed today is called 'Tesla Vision', they threaten to discontinue supply of the EyeQ3 chip to cripple the current version of the Autopilot."

The unreasonable demands Mobileye made are listed in the below article I lifted the above quote from.

[https://electrek.co/2016/09/15/tesla-vision-mobileye- tesla-a...](https://electrek.co/2016/09/15/tesla-vision-mobileye-tesla- autopilot/)

</comment></comment></comment><comment><USER16> Noted caption on photo "A hirsute Sebastian using autopilot in a Tesla Model S." If this was said about a woman it would be sexist. Imagine if it said "Good looking Mary ... etc." outrage would be reasonable and forthcoming.

I believe if we're going to be alert to sexism towards women we need to tune up our antennae to all sexism and have simple and clear standards that have a hope of applying cross-culturally.

I welcome your alternate views below. I am genuinely interested in learning why you think I'm out of line here. :-)

<comment><USER3> That's just because "hirsute" is considered to be an undesirable trait in women, but desirable in men. Pick an adjective that's flattering to Mary and I don't think anyone would care.

Considering that Sebastian is also credited for taking the photo, I'd speculate he approved of the caption, or even came up with it.

<comment><USER16> Thank you for your reply. I think any body-reference to Mary where that wasn't relevant (is hirsute relevant?) would be sexist and should be called out.

<comment><USER3> I imagine that Sebastian is proud of his beard, or embarrassed, or both, and wanted to call attention to it.</comment></comment></comment></comment>


Maximum Bandwidth via FedEx - <AUTHOR> http://alexjerez.net/maximum-bandwidth-via-fedex/

<comment><USER2> Ugh, is there any way to only get the HN FrontPage via Feedly? Tired of this shit clogging my feed

</comment><comment><USER3> the word analog does not mean "not on a computer". It is also not the opposite of digital.

<comment><USER4> A truck full of MicroSD card is still considered carrying digital data. Additionally the context of this sentence (which if I recall correctly is from the first chapter of Computer Networks books) is understanding the concept of bandwidth for a beginner in internetworks.</comment></comment>


Elliptic curve calculator - <AUTHOR> https://cp4space.wordpress.com/2012/08/29/elliptic-curve-calculator/

<comment><USER2> Doesn't work for 8 x 8.

<comment><AUTHOR> I don't see any issue with calculating 8x8. Putting a tangent on the blue 8 results in an intersection at the red "6.4".

Probably you are alluding to the fact that numbers are treated equal if they are only different by a factor 10^x (such as ..., 0.064, 0.64, 6.4, 64, 640, 6400, ...). In that case, see the comment by David Stay and the reply he got:

[https://cp4space.wordpress.com/2012/08/29/elliptic-curve- cal...](https://cp4space.wordpress.com/2012/08/29/elliptic-curve- calculator/comment-page-1/#comment-3)</comment></comment>


BitTorrent Sync comes to Android - <AUTHOR> https://play.google.com/store/apps/details?id=com.bittorrent.sync <comment><USER2> I understand the main complaint against BT Sync is that it's not open source. That said, is it possible for anyone speak to its security? I've been testing the desktop client for some time and it seems one of the most promising applications I've used in awhile - even at alpha status.

Would like to recommend this to peers I work with as a potential collaboration tool for projects that require security.

Next up, BT Mail? Would love to see that.

<comment><USER3> I started using BTSync a few days ago and I must admit it is a very interesting and useful software. However there are a few things that bug me:

[1] It uses a public tracker to transfer your files, which mean anyone with your secret phrase can download your files from the other end of the world. You can't assign a private tracker or change the current one. (The use of trackers can be turned off but when I did, it failed to sync, even within a LAN)

[2] If a direct connection cannot be made, a relay will be used to transfer your files. (This is turned on by default but you can turn it off in the settings)

[3] .SyncIgnore which is supposed to be similar to .gitignore does not work as expected.

[4] "Anonymous" statistics are collected and cannot be opted out or turned off.

[5] The claim for privacy, security and encryption cannot be easily audited since it is closed source.

BTSync definitely fills the void what Dropbox leaves behind but I wouldn't recommend using it for anything secure.

<comment><USER4> It looks like 1-4 are flaws that can be mostly attributed to this being alpha/beta software and not fundamental flaws in the product.

I do wonder how they will monetize their final release. Perhaps a monthly backup plan on their own servers.

</comment></comment></comment><comment><USER5> Sigh. There's a saying about closed-source crypto...

<comment><USER6> I tried it for a few days to sync my main laptop with my netbook. Could not find any info on how it works and stopped using it. How does it generate keys? How does it sync? How can i be sure nobody is reading my files somewhere else? Back to rsync I guess, though the two way sync with syncapp was rly nice.

</comment></comment><comment><USER7> Would love to get HN's thoughts on this idea ... if BTSync were to release (or have developed if it goes open source) a mobile SDK for ios and android, what if an app that used this would just give the user a folder secret. This secret could then be used to set up a folder on their PC to automatically get access to and backup data from their mobile devices.

I for one would love this, because then I can choose how much infrastructure to devote to backing up and sharing (between my own applications) my mobile data.

</comment><comment><USER8> Too bad that besides BTSync every Bittorrent Labs product runs exclusively on Windows.

</comment><comment><USER9> I really do hope a BTSync protocol spec is released.

Not sure if there are any efforts being made at reverse engineering. Maybe it would make a good project =)

<comment><USER10> It seems that somebody already started this [https://github.com/picosync/workingDraft](https://github.com/picosync/workingDraft)</comment></comment>


The speed, size and dependability of programming languages - <AUTHOR> http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html <comment><USER3> The benchmarks used for the article was from 2005. Make sure to check out the 2009 versions:

[http://gmarceau.qc.ca/blog/uploaded_images/size-vs-speed- vs-...](http://gmarceau.qc.ca/blog/uploaded_images/size-vs-speed-vs- depandability-paradim-2009.png)

V8 has propelled JavaScript into the coveted bottom-left corner, which is awesome. SquirrelFish Extreme should be right up there with it, if it were included.

<comment><USER4> More reason to believe JavaScript is going to be huge on the server-side. As concise and (nearly as) powerful as Python, Perl, and Ruby, but getting faster at a much more rapid clip...and already required for the front-end, so everybody on the team is already familiar with it. Library coverage will take another couple of years to reach a reasonable level, but I'd bet on it happening.

<comment><USER5> I agree. Once I learned how truly powerful Javascript really is, once you get past the horrible DOM, I knew it could one day become a general-purpose scripting language and not just a web one. As soon as someone makes a good command-line Javascript interpreter, web apps will come as soon as someone creates a CGI extension to that interpreter.

<comment><USER3> I'm working on it:

<http://jackjs.org/>

<http://narwhaljs.org/>

<https://wiki.mozilla.org/ServerJS>

</comment></comment></comment></comment><comment><USER6> Very good graphs. Aside from X (time) and Y (code size), the center of the star implies "typical" performance, and the relative spread of the star shows specific data points. Ruby, for example, shoots out from the bottom right - <USER2> me, this says, "This is quite expressive, and if you know what you're doing, you can get reasonably good performance". It doesn't show memory usage or sample size, however - Rebol probably has significantly fewer samples than Python, for example, but it only looks like half as many.

It's also interesting how the LuaJIT star has about the same shape as the Lua star, but with 1/3 the width (which is consistent with my experience); Psyco relates similarly to Python. Surprisingly, the Lua star's center appears to be at the same X as GHC's, but lower down, and LuaJIT's overlaps OCaml's. While I can accept well-written Lua being approximately as expressive as Haskell (depending on the problem), I don't think it's in quiiiite the same ballpark as OCaml, speed-wise.

The most interesting shape, to me, is Io's: While the default performance seems pretty poor (the right edge meaning 8x as slow as the left edge), there are bands shooting _all the way to the left_ , without adding any real height. I don't have any experience with Io (I'm curious, but have never had success porting it to OpenBSD/amd64); can anybody here comment on this?

<comment><USER7> "Ruby, for example, shoots out from the bottom right - to me, this says, ... if you know what you're doing, you can get reasonably good performance" Sorry, but it does not say you can get reasonably good performance, it says this version of Ruby is slow, one of the slowest languages in the Shootout. And the graph itself says nothing about the skill level required to obtain the exhibited performance.

<comment><USER6> > And the graph itself says nothing about the skill level required to obtain > the exhibited performance.

In all fairness, neither do most people promoting C++'s performance-at-any- cost design.

I think a large spread in the performance correlates with requiring skill level, though -- it means that some people using the language get good results, but that many also get very bad ones. Ruby is a really slow language ("reasonably good" < great), but it's _still good enough for many purposes_ , provided your algorithms are reasonable.

<comment><USER8> Ruby is not a really slow _language_. It's got some really slow _implementations_. Ruby has a high cost to entry for a VM/tool developer because it has a relatively byzantine syntax which has been hard to standardize. You can write code that has the same tokens yield entirely different syntactic elements, based on something random, like, say, what day of the week it is, which you can do in Python or Smalltalk, but in Ruby you can do this by accident with statements that look very innocent. (This is covered right in the Practical Programmer's Ruby book.)

If dealing with Ruby's syntax were easier, Ruby implementations would progress faster.

<comment><USER6> That sounds more like, "its design interferes with fast implementation" to me. If there's a major difference between that and "it's slow language", I'm really curious what it is.

<comment><USER8> You missed a meta-level. The design doesn't interfere with having a fast implementation. It interferes with implementing a fast implementation.

"It's a slow language," implies that there's something special about Ruby that precludes (relatively) fast implementation. There's nothing special about Ruby like this. Ruby is a very nice remix of language features that existed before. Getting a language to be fast can require many iterations. Ruby's syntax is a high barrier to entry to implementers, so fewer eyeballs have been looking at the problem.

Contrast this with Smalltalk. <http://news.ycombinator.com/item?id=619398>

Smalltalk was designed to be quickly implemented by a single programmer. Implementing a "Bluebook VM" was treated as a rite of passage for support engineers for at least one of the vendors. As a result, people have implemented many, many variations on Smalltalk. (Including an VM with built-in OODB, another that can compile down to a C++ compatible DLL indistinguishable from one written in C++, another that ran on the _old_ Palms, one with optional typing, and many others.)

I think it's fair to say that writing a Ruby VM is probably an order of magnitude harder.

<comment><USER6> Got it. FWIW, I don't particularly care for Ruby; for that style of programming I usually use Lua, whose syntax and semantics are quite simple.

The existence of LuaJIT (<http://luajit.org/luajit.html>) supports your argument, I think.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> It would be a useful to include the language name where it is not obvious. For example, he mentions Haskel, but I cant tell which one it is.

<comment><USER6> It's "ghc", in the chart.

</comment></comment><comment><USER10> Shows and compares graphs plotting performance vs. code size, based on the programming language benchmarks at <http://shootout.alioth.debian.org/>. Note that 'dependability' here means 'the consistency of the performance or code size'.

Few solid conclusions can be drawn: small performance benchmarks are hardly indicative for both the code size and the performance of most actual projects in a language.

</comment><comment><USER11> _Languages which include functional features such as lambda, map, and tail call optimization are highlighted in green._

I found one minor inconsistency: Lua has all these but is still colored blueish.

<comment><USER6> Lua isn't usually associated with the functional languages. Besides mainly being promoted for embedded / extension use, I think the single biggest reason for this is that, while it has tail-call elimination, closures, first class functions, etc., you still have to say "return x" at the end of functions. I do a lot of FP-style stuff in Lua, and while the language doesn't actively resist it the way Python does, it's not the main direction its design flows.

It seems like a small thing syntactically, but languages that return the result of their last expression _by default_ (I think of them as "expression" languages), and that require an explicit block for side-effects (begin in Scheme and OCaml, progn in Common Lisp, etc.), tend to get idiomatically used in a functional manner, while languages that default to a series of statements with side-effects and require an explicit return at the end ("statement" languages) typically do not. While you can use several of the latter languages for functional programming, only the former are functional "by default".

Saying "function(x) return x + 1 end" is a tiny bit more trouble than "fun x -> x + 1" or "(lambda (x) (+ x 1))", so while lambdas still get used where they're the best fit (as arguments for map or filter, for example), they're less common overall. Defaults influence a language's overall style at least as much as what's theoretically possible. Python's concept of what's "pythonic" seems to be the most explicit acknowledgement of this.

Incidentally, I would _love_ to see a language that crossed Lua with the ML family: a small, portable, clean implementation that interfaces easily with C, but with type inference, ML's top-notch module system, and (ideally) Haskell- style type-classes. OCaml is such a good language that I'm willing to tolerate its warts, but I'd strongly prefer a minimal ML-like language. (FWIW, I haven't used SML, though that's just because I do most of my programming on OpenBSD/amd64 and the smlnj port is i386 only.) When standalone, Lua is best suited to small/medium projects. Its historical emphasis on embedding in an existing project has made a module system for standalone use a bit of an afterthought.* As a project gets larger, static checking and stabilizing the module interfaces becomes far more important, and this is one area the ML languages really excel.

* For a good summary, see "Almost Good Enough to Scale: A Lua Mail Handler and Spam Filter" (<http://www.lua.org/wshop08.html#ramsey>)

<comment><USER12> _you still have to say "return (val)" at the end of functions_

We have a bunch of code that compiles to both Common Lisp and Javascript, and those nasty "return" statements are one of the two biggest mismatches between the two languages (the other being Javascript's weird semantics around null, false, 0, and ""). One of these days I intend to try inserting them all automatically.

<comment><USER6> Indeed. It's surprising how deeply eliminating return changes the language semantics.

I've postponed learning Javascript until recently, because my work hasn't usually been web-oriented, but it's interesting how similar Javascript and Lua are. They seem to have been aimed at the same target, but for historical reasons Javascript's development got frozen early, while Lua had time to iron out many similar design flaws.

(In Lua, undefined and null are both nil, nil and false are "false-y", and everything else, including 0 and "", are truthy.)

<comment><USER12> I think you hit the nail on the head earlier. It isn't "return" as such, it's expressions vs. statements. Backus got it right. What's surprising is that the superior way gets the tiny minority of usage. (Not so surprising if you know the historical reasons.)

JS is not so bad. We're lucky that what we're doing (writing high-level FP code that compiles to JS and runs in pretty much every web browser in the world) is doable at all.

JS even has its own version of progn: "(a,b,c)" evaluates to c (after evaluating a and b). We use that pretty heavily. Alas, it has two problems: there are some things you can't do inside the block (like declare new variables or have for loops), and it makes the JS harder to read and debug. Otherwise we'd probably just compile everything that way.

<comment><USER13> Can you get around (at least some of) those restrictions by wrapping things in function expressions? Here's a for loop: ((function(){ for(x in [1,2,3]){print(x)} })(), 42)

<comment><USER12> Yes, and we have some macros that do just that (a Greenspunned version of half of CL's LOOP comes to mind). But it's not great as a general solution because of what it makes you give up in performance and readability. Also, it doesn't solve the problem of declaring new variables.

Every now and then we hit upon a new abstraction that lets us remove another chunk of ugliness from our code (while still generating acceptable JS) and I'm hoping that the trend will continue, especially if we can get rid of all those "return"s.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> I thought this was the most telling line of the article: "Ultimately the first factor of performance is the maturity of the implementation."

That supports a common conviction held by fans of functional programming: if all of the years of arduous optimization that have been poured into GCC had instead been poured into (say) GHC, then Haskell would be even faster today than C is.

That is, to many people functional programming languages seem to have more _potential_ for performance than lower-level procedural languages, since they give the compiler so much more to work with, and in the long run a compiler can optimize much better than a programmer. But so much more work has been put into the C-style compilers that it's hard to make a fair comparison. It's still hard, but this experiment seems to give some solace to the FP camp.

<comment><USER15> Haskell may potentially be compiled to within epsilon of C when using strict evaluation + mutable state + unboxed types (look at the shootout implementations; the majority are in this style), but lazy evaluation and functional data structures have a real cost.

It's not merely that the ghc developers have been insufficiently clever and diligent.

</comment></comment><comment><USER16> This is great.

If you've looked at Peter Norvig's spell checker shootout you won't be surprised much. Ex., the story on Common Lisp and Scheme implementations is the same here: MzScheme is the mediocre best of an unimpressive lot. (I want to see Clojure and Arc on this.) Python looks great again. F# looks weak here but wins big in the spell checker with reasonable-looking code. Sounds interesting.

What's the deal with Squeak? I had thought that it very concise.

The meta-message here is best of all: people are measuring language conciseness.

<comment><USER6> Well, arc's running _on top of_ MzScheme, so it's likely to be a bit slower. Also, Stalin in the left column is a Scheme implementation, albeit one that is very restrictive for sake of raw speed.

Also, it's worth noting that the features in a language that make _large_ systems' codebases manageable (such as good module systems) are different from the features that allow you to pare down small scripts further. It's hard to show features supporting conciseness-in-the-large in a one page benchmark, so IMHO the latter is often greatly overemphasized. Being able to knock 2 lines off 20 is often just a parlor trick, though, while 50kloc off of 200kloc can mean life or death for a project. The programming world would be a happier place if the size of every legacy C++ / Java codebase were cut by a double- digit percentage.

<comment><USER17> > > (I want to see Clojure and Arc on this.)

> Well, arc's running on top of MzScheme, so it's likely to be a bit slower.

I'd be interested to see how Arc fares on the _code-size_ axis.

<comment><USER6> Are there any large projects using it?

<comment><USER17> I don't know much about the Shootout, but my guess is that, if someone wants Arc there, they need to go and write whatever programs the Shootout requires you to write in order to participate in the Shootout.

I'd try it, but I don't know Arc (or Lisp yet, for that matter). If someone here knows Arc and wants to see it in the Shootout, I suggest they look into the faq: <http://shootout.alioth.debian.org/u32q/faq.php>

</comment></comment></comment></comment></comment><comment><USER18> The references to Ruby aren't entirely what they seem in here. They seem to be relating to Ruby on the older shootouts, rather than the recent ones. That is, the uber-slow Ruby 1.8, rather than the Perl-beating and PHP-matching Ruby 1.9 which is more closely related to "yarv" on this list.

<comment><USER19> Its great to see Ruby so much faster with 1.9 because 1.8 speed was such a stumbling block in data intensive stuff that I pushed towards it.

However don't count your chickens just yet with regards to Ruby 1.9 being "Perl-beating" ;-) Don't you think its odd that Perl 5.10.0 sits only just above Ruby 1.8.7 in the current alioth shootout? Quick look at the tests and I can see a problem with a known 5.10.0 speed issue bug. Fixing this in a quick local test here makes all the difference ;-)

<comment><USER20> > Fixing this in a quick local test here makes all the difference ;-)

It makes all the difference to that one benchmark - not to the overall situation.

</comment></comment></comment><comment><USER21> Interesting. Looks like Yegge was right in falling in love with ocaml awhile back.

</comment><comment><USER22> I wonder why mlton doesn't have a higher profile. Is it hard to use, or something?

<comment><USER15> I looked at SML and there seemed to be a few warts compared to Ocaml: <http://www.mpi-sws.org/~rossberg/sml-vs-ocaml.html>

mlton may not allow separate compilation (it does whole-program optimization at least), and it's pretty slow even on small stuff, but if you were really using just the Standard ML language, you could use a faster compiler for development. I'd probably want to use some extensions, and I wasn't sure if the intersection of mlton's extensions with some other implementation could satisfy me.

<comment><USER6> mlton seems to be used for optimized compilation for releases, while general development is typically done in another SML environment, such as smlnj.

I don't have really concrete experience with SML, just OCaml, which also has its share of warts. It's a fantastic language in certain niches, though; generally, the sort of niches for which dynamic / "scripting" languages are usually a poor fit. (I wouldn't write a serious compiler in Python, for example.) They're very complementary.

I think the ML family has a lot of advantages, but the community is pretty closely tied to academia (much like Haskell, but without the buzz). While that in itself is probably neither good nor bad, in this case a lot of the terminology used is especially math-y; There are many features ML has that programmers would find tremendously useful, except they're usually discussed using Greek letters, which is insular. I got a copy of The Definition of Standard ML from Amazon, hoping to get further insight into the language's design, and found it completely impenetrable. (Then again, I'm not a grad student.)

Newer languages seem to be using type inference (finally!), but as far as I know, nobody has really ran with the design of its module system.

</comment></comment></comment><comment><USER23> This is one of the best things I've seen on the Internet in a while. :-) Definitely worth taking a look.

</comment><comment><USER24> dependability mostly is a stand in for a program making more assumptions for you no? In a language that makes a lot of assumptions its easier to create something where assumptions conflict somewhat invisibly.

</comment><comment><USER25> For this sort of comparison, mostly-functional multi-paradigm languages like SBCL and Ocaml should be run through the benchmarks twice; once with imperative code, once in the functional idiom. The often-repeated complaint (of which I'm skeptical) about functional languages is that they're only efficient when ugly imperative features are used, and it would be good to confirm or dispel that suspicion.

<comment><USER6> It's more complicated than "functional is slower than imperative". Functional data structures are sometimes less immediately efficient, _but add persistence_ (since they're immutable, they share subsections of the data structure, and/or have access to snapshots of past versions of the structure being modified). Whether this gives you needed features or just means extra work and cache misses depends on what you're doing. If you have a functional data structure and you want to add "undo" or backtracking, you're already most of the way there, while adding this to an imperative data structure means extra work to keep track of state changes.

_Purely Functional Data Structures_ by Chris Okasaki is, by far, the best collected resource, if you want to read further. (His thesis (<http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf>) is the kernel of the book.) Also, the fourth chapter of _Developing Applications with Objective Caml_ (English translation: <http://caml.inria.fr/pub/docs/oreilly-book/>) discusses functional and imperative styles' strengths and weaknesses.

Reducing everything to runtime benchmarks obscures how, in practice, the trade-off is often more like "it was a huge pain in the ass to get working without bugs, but it's 2% faster" versus "it took twenty minutes and was correct on the first try". (Also, whether or not you use it in production, OCaml _rules_ for prototyping complex data structures, in the same way Erlang does concurrency and C++ does linking errors.)</comment></comment>