An acquisition is always a failure - <AUTHOR> http://pandodaily.com/2013/04/02/an-acquisition-is-always-a-failure/ <comment><USER2> No, no, a thousand times no. This is complete bullshit. I'm sorry, but you lost me at:

 _The proper ambition for a tech entrepreneur should be to join the ranks of the great tech companies, or, at least, to create a profitable, independent company beloved by employees, customers, and shareholders._

Nobody, not you, not my mom or dad, not "God", not Linus Torvalds, not Bill Gates, not the Queen of England, not the Dali Lama, not Zoroaster or the Easter Bunny or President Obama or the sterno bum at the corner of 3rd and Main, not Sergey Brin, not Kevin Rose, but NOBODY has any standing to tell _me_ what _my_ "proper ambition is." Why? Because "fuck you", that's why. You don't know me, my life, my past, my future, my dreams, my fears, my hopes, my goals or a goddamned other thing about me. Don't f%!#ng try to tell me what I ought to aspire to.

Say I build a company to a point where I could sell for enough that I could walk away with, I don't know, let's call it $10,000,000 USD. The other option is to stay independent and maybe, _maybe_ eventually IPO. It's easy to sit on the sidelines and say "Go for the IPO, don't sell, selling is a failure". But you know what... maybe I need the money _right now_ to do some things I always wanted to do. Maybe I want to buy my aging mother a new house, and I don't want to wait for a bloody IPO, I want to do it _now_. Maybe I have a family member who needs special medical care, or - fuck it - maybe I just want to cash out, fly to Scotland, and spend the rest of my life looking for a 6' tall, redheaded supermodel with a Scottish accent to marry.

In any case, no, you don't get to tell me that I failed, if I choose to pursue what matters to _me_.

Look, I get the point... I agree that - _in general_ \- entrepreneurs _would_ want to stay independent, and _would_ prefer to wait. I don't relish the idea of building a company and then selling it... but life is more complicated than that. And life is a series of tradeoffs and a constant balancing act between doing what is best for us _right now_ versus what is best for the future. One is not a failure for making a rational, reasoned decision to favor one set of priorities over another.

<comment><USER3> _Say I build a company to a point where I could sell for enough that I could walk away with, I don't know, let's call it $10,000,000 USD. The other option is to stay independent and maybe, maybe eventually IPO._

This is the part that rankles with me. Why is, "stay privately held and continue to turn a profit year over year" never considered an option? Why is it only "sell" or "IPO"?

<comment><USER4> It depends on your goal. Even companies that stay privately held and turn a profit year over year end up in many ways being a lifestyle company; Often resulting in stagnation and then slowly erode from the inside. It can work, you can avoid stagnation, but only for a few types of companies / founders.

For example Valve can pull this off, they are a game company, always building the next great game, they always have something new to work on and have gone to great lengths to keep their employees involved and attract top talent. They have avoided stagnation.

On the other hand, many of the companies you see get acquired built one or two focused products, they don't have 'the next big game' to work on, that is boring for many people, particularly the 'founder type'. Boredom -> stagnation -> erosion.

You could say that company X could just define themselves as e.g. a 'mobile app' company the way that Valve is a 'game company', but in reality, 'mobile app' is way too broad. How is a 'mobile app' company any different than startup? The difference is that instead of investors taking the risk on the new product, the company takes the risk, which doesn't bode well for the constant year over year profit ideal.

The 'company taking the risk' model can work, e.g. Google, but you have to be wildly profitable to pull it off, that is hard, really hard, so hard that only a hand full of companies have ever pulled it off.

tl;dr Privately held long term companies can get boring quickly. It takes a very particular type of market, a founder who really wants a lifestyle company, or a company that is wildly profitable to avoid stagnation. All three options are relatively rare.

<comment><USER5> > Valve can pull this off, they are a game company, always building the next > great game

Ironically enough, Valve hasn't created a game for years. These days they are mosty a platform (Steam) company rather than a game studio.

<comment><USER4> Many modern games take a long time to produce, 3-5 years is not uncommon for AAA titles. I also wouldn't say they haven't released a game 'for years', there has been at least 1 title a year, a ton of DLC for older games, porting games to linux, etc.

</comment></comment></comment></comment></comment><comment><USER6> There is absolutely nothing wrong with getting into business to make money. Nothing.

There is nothing wrong with discovering a problem you don't have or care about that people are willing to pay to have fixed, slugging through building something to solve that problem, and trying to maximise your profit and minimize your time. There is nothing wrong with working hard in a field you are not passionate about to make money.

How passionate do you think the guy soldering your alarm clock battery to the circuit board in Guangdong China is about his job? He does it to make money for himself and/or his family. Is there something wrong with choosing entrepreneurship with the hope of making a fuck ton more money than that, or are you required to take the job you can get unless you want to build a billion dollar business for shareholders?

Only working on something you are fully passionate about and getting paid well is a luxury not everyone can afford.

There is also nothing wrong with creating a non-profit to help limbless children in Cambodia, taking no salary, and spending all your time in service of others.

In fact, the former can allow you to do the latter, still support your family, and live well yourself.

I agree with mindcrime. And I wonder why so many PandoDaily writers are so full of pomp. And fuck that guy.

</comment><comment><USER7> Pretty easy position to take once you've already earned your own "fuck you" money.

I do sometimes wonder why these sorts of acquisitions remain so prevalent though when minus a few notable exceptions the life cycle tends to consist of a company paying many millions or even a cool billion for some tech in a stack they don't even use (only to kill it soon after) plus a handful of employees that tend to stick around barely engaged until just long enough to unlock whatever golden handcuffs they have on.

Seems like way more often than not they are failures more on the side of the acquiring party though I guess there may be some valid (though ultimately unfortunate and cynical) reasons for participating like nipping a potential future competitor in the bud.

<comment><USER8> Almost all popular Google products (other than search and Gmail) have come from acquisition: Maps, Analytics, Google Apps, Android, Blogger, Picasa, YouTube, Postini, reCAPTCHA, etc.

My good friends Robby & Wayne's company, Zenter, was acquired by Google in 2007. While Robby has since left, Wayne is now a very respected eng manager in charge of a very important project, so I would argue that acquisition was successful for them.

So while many acquisitions do not work out well (and usually loudly), it would be a big mistake to pretend that applies to all acquisitions.

<comment><USER9> You're right; some acquisitions survive as real products and it would be a mistake to call them "failures".

I guess what the OP means is that price alone is not a sufficient criteria to judge whether an acquisition was a success. If you sell your company for a large amount of money, but it gets shut down, that's not "success" (although it's certainly much better for you than closing down without any money).

</comment></comment></comment><comment><USER10> I recently sold my company and I agree with Jake.

What most commenters don't understand, in my opinion, is that real entrepreneurs don't start their company to get rich. If getting rich is your priority, become an investment banker (If you really want to code, make some automatic trading algorithms and financial models for investment bankers.)

In that regard, selling your company is, very often, a failure.

In my experience, the worst is to have to give up your values. As a young entrepreneurs, I started my first company 10 years ago with not only a strong vision for my product, but also an quite idealistic goal for the values of my company and my team. We wanted to be different. We wanted to do things as we thought it was right to do. And nobody could tell us what we had to do. It was such a strong feeling. It drove the success of the company. Ten years later, we got acquired by a large corporation that is not better or worse than you normal large corporation. And we had to give up all that. That's failure.

<comment><USER11> You didn't describe failure, you described Regret. As a young entrepreneur trying to do the same thing you did in the past (establish a company that is strong, independent, has great values) I can see how "abandoning" those values _feels_ like failure. But it really depends on your definition of success and also what you do _after_. An acquisition could provide someone with the financial freedom, knowledge, and business network to execute an idea with even greater ambitions, values and impact on the world. That's why I don't think it's always a failure. It's only a failure if it was the best thing you could ever do. But to me, the best entrepreneurs are incapable of thinking like that. You can always do better, be better, make something better.

</comment></comment><comment><USER12> > _With a fat bank account, I was pretty set to do whatever I wanted for a > long time._ ... _But it didn't take long to realize that my new life was a > hell of a lot less exciting than running an independent company had been._

Sorry, but this is completely self-contradictory. With your fat bank account, you can start a new, independent company. If what he wants is:

> _our way of thinking of a better approach to consumer tech, with less > structure and more play, an exploratory mindset that, through trial-and- > error, produces very tangible real-world value_

Then nothing is stopping him from doing that again. In fact, he's in an incredibly privileged position.

Indeed, being acquired and then let go lets you focus your energies on new things, rather than being stuck maintaining old things you created in the past -- "maintaining" things being something that established companies might very well be more skilled at.

So, besides being needlessly inflammatory, this post doesn't even make sense inside of its own logic.

<comment><USER13> > With your fat bank account, you can start a new, independent company.

It takes years to build a great company. Running a great company was better than having the potential to start a new one.

<comment><USER14> > Running a great company was better than having the potential to start a new > one.

For you, in your specific context.

</comment></comment></comment><comment><USER15> I used to think about startups in bovine terms.

Some startups are beef type. These are made to grow as fast as possible, increase the user base by whatever means, without care about long-term health. They hunt for investments, especially big ones. Then, the sooner the better, such a company is sold to a large company and butchered, either to be digested and feed the corporate muscle, or just to remove competition with the big company's product line.

Other startups are milk type. These are grown steadily and sustainably, if slowly, with great care about long-term health. They are usually become profitable early on, at least ramen-profitable. Owners usually reject several acquisition proposals, and are careful with 3rd-party investments so as not to lose control of the company.

I think that a milk-type company has a far better chance to be a long-term success and transform the industry. It may grow huge, like Google, or stay small, like Github or Craiglist.

In rare cases beef-type companies do not die within a large corporation but become an important organ (e.g. Android inside Google), or enjoy a benign neglect (e.g. Instagram inside Facebook). But usually they just die, the way the post explains, or even worse.

</comment><comment><USER16> I'm going to guess that Jake will take a lot of flak here for this article, but the truth is: I agree with him, for a certain version of "success".

There are folks who will pursue money, and then an acquisition looks like a nice validation and exit. Great. No prob there.

But there are a bunch of folks who are satisfied when they are _building_ , and any other mode feels like something is missing in life. My advice to this (my) cohort: Don't fight it, just accept that you're always going to need a project to obsess over. Odds are that project will be a _failure_ but not as much as anything else that is not so much a "project" as "going to work in the morning."

<comment><USER17> You can keep building when you have $10M in the bank. You can build a lot of things, not just websites. You can build a hotel. There's so much out there to do. Working on the same thing my whole life sounds miserable.

</comment></comment><comment><USER18> Jake is brilliant, but this isn't always the case: What about Google's acquisition of Android? What about Apple's acquisition of NeXT? What about Microsoft buying 86-DOS from Seattle Computer Products? What about Lenovo's acquisition of the ThinkPad?

<comment><USER19> These are wins for the buyer, not as clearly for the seller. Of course, if the seller sold voluntarily then it seems silly to argue that it wasn't what they wanted.

<comment><USER20> Seller has a product, buyer has distribution. For each Android, NeXT and QDOS there's a bunch of similar companies that went nowhere.

</comment></comment></comment><comment><USER21> The "older doofuses who didn't understand the Web" seemed to have done pretty well with CollegeHumor and Vimeo without Jake. If they had run them into the ground, I imagine he'd write an article about how being acquired is always success.

<comment><USER13> The existing businesses were nurtured and optimized reasonably well. I was lamenting the loss of the creative spirit that generated those two businesses in the first place -- the larger, more valuable core of the company.

<comment><USER21> I kid because the title seems designed to be provocative. It's not always failure to sell out. Quite the opposite in my case, but I hear you. You "sold out" and lost something in the process. They have been good stewards of Vimeo. It's one of the quality sites on the web, so I wouldn't fret too much. You created something wonderful. That's more than most people.

</comment></comment></comment><comment><USER11> The title is too strong and this post is too black and white. Succeed forever and become a giant or fail? Not very inspiring. I like his views on visionaries and how an acquisition _usually_ removes the real vision from the company but other than that, this is just a very subjective piece.

</comment><comment><USER22> Choices you have with what to do when your startup gets successful enough to consider your "exit"

A) sell B) IPO C) stay the course

If you've taken investment at any point, especially VC, you are pretty bound to do A or B. Your investors want to see the company succeed in many ways, but they are also looking for returns at the end of the day. Large ones. So if the opportunity comes along, your board will probably make you take it.

So C is really only an option if you're 100% bootstrapped. That's pretty rare these days. Even if you are, the excitement, challenge, and general "buzz" you get from being a startup founder is going to pass at some point. Either the company stagnates or you get too big to be nimble.

The author seems to be just lamenting the passing of time, that he's not as excited and hungry as when he first started. In most cases, nothing you do is going to bring that innocence back.

</comment><comment><USER23> I don't begrudge this author his wealth or his page views. But this piece isn't the least bit serious. Ten times out of ten, he'd take his buyout over again. The only thing that concerns me is that somebody might actually take this post to heart and destroy his or her chances of joining the ranks of the author should the right opportunity present itself.

<comment><USER13> > Ten times out of ten, he'd take his buyout over again.

How do you know that?

<comment><USER24> ...and how did the OP know what our proper ambitions are? Read it all as an estimation of human nature, not a deconstruction of the author.

</comment></comment></comment><comment><USER25> This article couldn't be any further from the truth. How is selling a failure? What if you're selling because your marriage is falling apart or family is suffering because you're never home? What if you want to persue other ventures? What if you're sick and tired of being responsible for a business?

Sometimes selling is the only option for some and I can sympathise with that. Or if you invested a whole heap of effort, time and money and want to cash out purely for the money, what is so wrong about that?

</comment><comment><USER26> Screw all y'all, I _love_ this article. It's a sequence of true statements with a hard to swallow and idealistic conclusion, but it's _absolutely right._

The only upside to an acquisition is money. Does that often make it the right, logical choice? Of course. Put that aside.

Once you're acquired by a larger more beaurocratic organization, your company dies (perhaps quickly, perhaps slowly), your projects flounder or become administratively managed, your ability to innovate quickly goes away. In short, your dream dies.

His personal accounts of this happening are _on the money_ and are not uncommon effects.

Facebook is a grand counterexample. Zuckerberg didn't sell out when the company was young and he was offered ridiculous buyouts because _facebook wouldn't exist today_ in the same way if he had. The dream would have been killed. Far-fetched example, but maybe true.

Of course it's important to think about reality, of course you have to look at the real world too; of course of course of course. No one can deny you that perspective.

But just maybe, let all that go for one second, and think from an idealistic perspective. Be a dreamer. Don't go after the most logical realistic thing right away. Or at least consider it.

Because we need those companies too. We need companies that can dream, and innovate, and remain independently fueled with a common goal and a vibrant workforce. We need companies that aren't acquired because we need dreamers to think big, so the world can go somewhere better—rather than just somewhere with bigger bank accounts.

</comment><comment><USER27> Not every business is as free-form as ones where you luck into a $100k/month business when you're just two college kids. In that scenario of course you can throw as much spaghetti against the wall as you want with total creative freedom. But most startups do not happen to be at exactly the right place at the right time like this, and it's a multi-year slog to creak into profitability, and then several more years of intense focus to actually achieve real success. If you want to cash out early to buy yourself the freedom to work on whatever you want, and you end up getting paid more than 99.999% of the world for your months of hard work, I don't see any way you can call that a failure. Even assuming no element of luck and that Jake is just one of the most naturally talented entrepreneurs alive, I still think expectations need to be re-calibrated here.

</comment><comment><USER28> And now for a counterpoint, we turn to our next guest, Andrew Mason.

</comment><comment><USER29> A sweeping generalisation in the title made by a tech blog is always a success.

<comment><USER13> Yeah. My suggested title was "A Critique of Popular Ambition". In future articles I might ask for more input on the title.

<comment><USER29> You probably won't get it. Subeditors guard their privileges jealously.

</comment></comment></comment><comment><USER30> even neglecting the money aspect entirely, this is bullshit. as a hacker, i want to build things. not "implement a vision", just build something that is useful to someone. if some larger company sees the thing i built and says "wow, this is exactly what we need to fill this gap in our product/service/lineup" and acquires my creation (with or without including me to continue developing it), i would consider that a resounding success.

as a real world example, does anyone think the keyhole vision was somehow killed by becoming google earth?

<comment><USER13> Maybe it wasn't clear from the article, but I was talking about the acquisition of a company, not a product. Hackers, and SV people in general, tend not to distinguish between the two, as many "startup companies" are actually just attempts to commercialize a single product idea. The potential for a company is orders of magnitude greater, because a company can create endless products. If you're talented enough to build things that are useful to people, why not found a single legal entity that creates _many_ things, mitigating per-thing risk and exploiting countless economies of scale?

<comment><USER2> _The potential for a company is orders of magnitude greater, because a company can create endless products. If you're talented enough to build things that are useful to people, why not found a single legal entity that creates many things, mitigating per-thing risk and exploiting countless economies of scale?_

Now that I totally agree with. And that's one of our goals at Fogbeam Labs. I'm absolutely down with the idea of building a large, sustainable, profitable company that branches out into many fields. I've joked with people that our goal is to be "the next Red Hat", but in a lot of ways, I could say that we want to be "the next IBM" or "the next GE" and it would be more on point.

The big part of TFA that I disagree with is the part where you presume to tell entrepreneurs what their ambition _ought_ to be. That and what came off to me as a judgemental tone, but that probably had a lot to do with the title.

</comment></comment></comment><comment><USER31> I didn't get farther than the headline.

Such a blatantly false sweeping generalization...obvious troll is obvious.

Why exactly is this on the front page with 115 upvotes?

</comment><comment><USER32> This is a great article! I would say that first-time entrepreneurs should try to get a success even if it means they have to give away equity / get acquired. You can own 100% of your next business if you like, after you have millions in the bank and a track record with investors.

</comment><comment><USER33> Of course it depends on your own goals, motivation, and the thing that gets you out of bed. If you care about your product and your audience then I think whilst it might sound promising to sell to a bigger company, there are chances your product and audience will be both gone. There are also chances of being able to reach even wider audience with an even better product.

I can think of a couple of examples like Picnik and Posterous. I'm not sure what those guys wanted out of it, and I hope they are happy with the decision. For me personally they were both two great products that dissolved into nothing... I'm sure there are plenty of examples to the contrary (some people mentioned other successful google product that really became huge).

</comment><comment><USER6> > my new life was a hell of a lot less exciting than running an independent > company had been

That may partially be because he was too busy to learn what makes him happy other than work.

</comment><comment><USER34> So, that would make Viaweb a failure?

I think the world is a much better place with PG & Company running Y Combinator than if they had slogged on and on with Viaweb.

</comment><comment><USER35> observation: companies get big and successful if the founder is not driven by money, but by the desire to be right (and prove it to others).

however, this does not mean that every companies main goal needs to be to get big. if you're driven by other desires, your style of business will follow. be aware of what you want, visualize it, this makes it far less frustrating.

</comment><comment><USER36> Many have problems with the title. It may be interesting to note that Jake Lodwick @jakelodwick stated:

"I wrote an article for Pando. My suggested title, "A Critique of Popular Ambition", didn't make it."

ref: <https://twitter.com/jakelodwick/status/319330932945469440>

</comment><comment><USER37> From not seeing a headline from them in a long time, I had hoped PandoDaily was banned from HN for being so terrible.

</comment><comment><USER38> Wish I fail every week. I dislike this rant a lot. It doesn't fit any pattern because everyone has different goals in life.

</comment><comment><USER39> >I uploaded them to blumpy.org, my crudely named personal website

Oddly they link to the url when it is now some Japanese site.

</comment><comment> Al-Khwarizmi I'd like to fail like that too.

</comment><comment><USER40> First of all, let me say that I hate "acqui-hires" with a passion that could summon Cthulhu. I've taken to calling them "welfare checks" because that's what they are: a socially-closed, elitist private welfare system to keep rich kids (born into the necessary investor and acquirer connections) from actually _failing_ no matter how dogshit-awful their ideas are. Acqui-hires usually benefit founders but screw employees, and should thus be thought of as a "gentleman's C" for shiftless, incompetent, useless rich fucks Playing Startup.

Thaaaaat said, I disagree with "always a failure", at least in the pejorative sense. Let's be realistic, here. Let's first take a page from Eastern religions. Impermanence. Go here: <http://en.wikipedia.org/wiki/Impermanence>

All things change. And die. That doesn't mean they were without value. They contributed, and left a trace. Something that is a ghost or a fragment of a god or a cloud of electricity (depending on whom you ask) carries around a decaying corpse for 100 years. It's absurd! Everything is constantly falling apart, but the universe seems to be get slightly better each day in spite of it. Nothing in the physical world is built to be eternal. That's especially true of businesses, which are generally built to effect one economic change that is initially radical but, once proven, is taken for granted, at which point it's commodity work that will be done better when a more innovative competitor comes along. Circle of life...

I try to live life by the Boy Scout's rule: I win if I leave the place better than I found it. Even though my effects will live on in subtle, chaotic ways, no one's going to remember my name in 500 years. If reincarnation is true, _I_ won't recognize my current name in 500 years. So...

Yes, if you're building a business for "Teh Exit" with the intention of making millions while leaving your colleagues stranded in brain-dead corporate subordinate roles that they'll hate, then you are, in fact, a fucking loser wankbasket and I hope you fail. Build-to-flip scene kids can choke on a taint. But this doesn't describe everyone who starts a business and ends up selling it. Sometimes, the thing generates legitimate value but proves not to have enough upside to justify the entrepreneur's continued full-time commitment... or it just gets into a state where she's no longer the right person to manage it. There are good reasons for good entrepreneurs to sell their businesses.

We shouldn't be looking at the mode of Teh Exit for moral guidance. That's what created this fucked-up, worthless VC-istan so-called "tech" ecosystem in the first place. Sometimes good businesses are acquired and bad ones IPO (which is just another form of acquisition). Instead of boasting or griping about ExitzLulz!!!111!!(10^large-1)/9!!, we should be focusing a return to _genuine value creation_ , no matter what form it takes (and it won't always be a private-sector business). We should get back to Real Technology: solving problems that people actually care about that make peoples' lives better. And we should get back to ridiculing these well-connected (not "empty suit", perhaps "empty hoodie"?) scene kids and their marketing-experiments-called- technology, no matter how they "exit". We should drive those fuckers out of town.

I _do_ think it is fascinating that acq-hires tend to be priced at 40-50 years of salary, given that an employment relationship only lasts 4 years on average. What does it tell us? It tells us that we, as engineers, suck so bad at marketing ourselves and negotiations that an often inconsequential third party (stone soup?) can sell us for a 10x markup. Also, it shows that large companies are ridiculously bad at discovering internal talent. The fact that Yahoo bought 17-year-olds at a panic price just indicates that their middle management filter is so bugfucked that they've given up on discovering talent, internally, at the bottom. If you have to buy a new winter coat for $800 every November, it means you need to get some order in your fucking house so you stop losing track of shit.

By the way, most of "social media" is not that innovative. It's just a wave of marketing experiments that uses technology because _almost everything_ new is technological. Social media are the reality shows of technology. Reality shows aren't prolific because they're good, but because they're _cheap_ (no actor's salaries, no writer fees). Social media startups are so common because they don't require a deep technological understanding, and because well-connected morons can CxO them, so long as they can buy a "scaling expert" at a panic price post-Series-B.

Let's get back to the issues that actually matter. Bashing people just because they get acquired as bad as the tyranny of Those Who Have Completed An Exit (celebrity founders) in fundraising. So let's just stop the nonsense and talk about how to direct ourselves to real work.

And... In-dig-nay-shun! <http://www.youtube.com/watch?v=EtCiP8B2xpc#t=7s></comment>


Django hosting roundup: who wins? - <AUTHOR> http://kencochrane.net/blog/2011/06/django-hosting-roundup-who-wins/

<comment><USER2> It might be worth noting that this is a roundup focusing very specifically on a subset of PaaS offerings. No Google App Engine, no Amazon EC2, and only a passing reference to Webfaction. :)

<comment><USER3> Google app engine is listed in the comparison chart (scroll to the right if your screen is too narrow). Amazon EC2 isn't a PaaS it is an IaaS and that is why it isn't covered in the roundup.

</comment></comment><comment><USER4> Large lists like this should be taken with a grain of salt, especially in such a rapidly evolving space. The date of the original post June 6, 2011 and the fact that there were no updates until 6 months later is a red flag that the author is not detailed about keeping it accurate or up-to-date.

There are probably plenty other inaccuracies by now, and other metrics worth taking into account when choosing between providers.

<comment><USER3> I actually keep it up to date, if you look at the top of the page I have a list of updates and when they were made. Everything is up to date. When something changes, I make sure to go back and update the chart. Sometimes things don't change for a while and hence the long pause in between updates.

</comment></comment><comment><USER5> Apparently, nobody! Thanks for the insightful title!

<comment><USER6> Heroku seems to be the only one with a "yes" in every feature checkbox.

<comment><USER3> You are correct, if you include addon's. If you don't include addons it is tied with dotCloud.</comment></comment></comment>


Chinese spy app allows officials to harvest personal data - <AUTHOR> https://www.theguardian.com/world/2019/jul/02/how-chinese-spy-app-allows-officials-to-harvest-personal-data <comment><USER2> Any progress on spying on the spies? I'm waiting for data leaks on Chinese politicians, and citizens tracking abusive police.</comment>


Ask HN: Affordable K8s for individuals? - <AUTHOR> Hey guys,
I currently have a single node root server which runs via Docker several applications (Nextcloud, Synapse, VPN, ...). If I need to apply security patches/updates I need to reboot this machine which takes all my services down. Due to my work as an IT Architect I am familiar with Kubernetes. I kinda like the idea to have a Kubernetes which runs the applications in a HA cluster. The last couple days I tried to create with three root servers and a private empty vlan a cluster myself (based on Microk8s or LXD/Juju). But due to a missing vswitch in this vlan it was for me at least kinda impossible to create a HA Cluster.
So my question basically is, do you guys run your own Kubernetes cluster? And if yes how do you achieve it? Is it affordable? Because buying Azure, AWS and co doesn't seem like to be affordable for private persons
BR <comment><USER2> > But due to a missing vswitch in this vlan it was for me at least kinda > impossible to create a HA Cluster.

I coudn't understand this part as total noob, but k3s was most fast and light resoure usage than microk8s, kind, minikube.

</comment><comment><USER3> you can run your own. get one computer, run multiple VMs and run the cluster on them. Or buy multiple computers and run your own cluster. unless you're dealing at scale, the overhead of running and upgrading your own k8s is usually not worth it.

</comment><comment><USER4> How would one implement this kind of thing? Grow a 1-VM cluster to a 2-VM one and migrate pods over, update dns etc, and then downscale back to 1 vm? Does k8s handle this use case well?

<comment><AUTHOR> Sorry, I don't get your question. Which 1 VM cluster? Growing 1 VM into 2 VM?

</comment></comment><comment><USER5> Digital ocean

<comment><AUTHOR> Doesn't seem affordable.

E.g. in Germany it costs 8GB DDR4 RAM (ECC), 2 dedicated cores, 40GB SSD / 320GB SAS 9€/month

</comment></comment><comment><USER6> have a look at linode.com

<comment><AUTHOR> Thank you. I will have a look</comment></comment>


Mic has laid off the majority of its staff - <AUTHOR> https://www.recode.net/2018/11/29/18117787/mic-layoffs-staff-bustle-facebook <comment><USER2> Another example of the dangers of putting all/most your revenue-making eggs in Facebook's basket:

> _Facebook recently cancelled a deal with Mic to publish a news video series. > People familiar with the company say that move removed a crucial source of > revenue and scared away potential acquirers and investors._

</comment><comment><USER3> Ok, they couldn't find a model to make a profit.

Their office was a whole floor in the World Trade Center.

I'm going to go out on a limb and say that there may have been cheaper places to lease...

</comment><comment><USER4> Amazing time capsule piece from the NY Times in 2016:

"What Happens When Millennials Run the Workplace? " [https://news.ycombinator.com/item?id=18564383](https://news.ycombinator.com/item?id=18564383)</comment>


HP's WebOS TouchPad reveals iPad's multitasking weaknesses - <AUTHOR> http://venturebeat.com/2011/02/09/touchpad-multitasking/ <comment><USER2> The real questions are: will users respond to technical superiority or are we looking at another NeXTStep/BeOS? will it undercut the iPad price (necessary to entice users to the unproven)?

(I say this as a Palm/WebOS fan hoping that the TouchPad, despite its uninspiring name, can survive in the market)

</comment><comment><USER3> Of course that is true if they don't take in consideration the 4 finger swipes currently available for developers but more likely to land in the next major upgrade.

<comment><USER4> It's not about the multitouch swiping. Multitouch wasn't even demonstrated. WebOS is very intuitive, and doesn't require one of 16 different swiping commands. ( for x in {1,2,3,4}; for y in {up,down,left,right} swipe $x finger(s) $y; )

Swiping aside, webOS kicks trash at multitasking because it was designed that way from the beginning. No new commands spliced into the next update. It's what it was designed to do.</comment></comment>


Ask HN: Took over an abandoned library. How do I get people to use the new pkg? - <AUTHOR> I was able to track down the original developer of a .NET icalendar library that had been abandoned. (It wasn't easy.) It had ambiguous licensing and copyright associated with it, which made me leery of using it for production tasks. He gave me explicit written permission to rename, open source[0], and relicense under a permissive license[1]. He also relinquished the copyright. I've also published a nuget package under the new name, Ical.Net[2]. The trouble is that if you look at the download stats, the older, buggy, under-performing library has many tens of thousands of downloads. It has a gravity to it that my library doesn't. How do I close the gap, and give people confidence that it's safe (and preferable) to use my library instead?
* It's unencumbered by licensing and copyright issues.
* It performs significantly better. The test suite completed in 17 sec; the current nuget package completes in 4.5, and I have an unpublished version that brings it down to 3.6. Performance was my original motivator for working on the library.
* I fixed about a half-dozen bugs while working on the performance
My plan of attack is as follows:
1) See if I can get the person who imported the original sourceforge history to commit a deletion of the code, and redirect people to ical.net via the readme.
2) Contact the original publisher of the unofficial nuget package, and ask them to unpublish it.
3) Have better API documentation. That's one thing the old package clearly does NOT have.
4) Maybe do a "Tell HN: dday.ical is now ical.net"(?)
What else should I consider? What else would you do? What would you NOT do? It seems to me that so long as the old code is floating around, and has a significant following, people are going to use that one instead. (I know I would as a naive outsider.)
[0] https://github.com/rianjs/ical.net
[1] https://github.com/rianjs/ical.net/blob/master/license.md
[2] https://www.nuget.org/packages/Ical.Net/ <comment><USER2> Looks like you have done a lot of good work!

I don't know about .Net, but in python-land there were three or four different oauth libraries floating around in various state of abandonedness. I guess they started out in the same way as you, by someone forking a project, working on it for a bit and then losing interest, whereby someone else comes along and creates yet another fork of the same project. For users (like me) that situation is very frustrating because there is no way you can choose the right oath project to use.

If I where you and I where _serious_ about maintaining the project I would eradicate all impostors like a jealous God. Ensure that there are no download links to the old project, that it can't be NuGet:ed and that no other pages points to it. If people on Stack Overflow asks about .Net iCalendar, answer and recommend them your library. Add comments to answers pointing to the old library saying that it is abandoned and yours should be used instead.

It's a huge amount of work (see f.e [https://github.com/search?utf8=%E2%9C%93&q=dday.ical](https://github.com/search?utf8=%E2%9C%93&q=dday.ical)) which is one of the reasons I don't like maintaining packages.

</comment><comment><USER3> For some reason I assumed physical library. This makes more sense, but I am a little disappointed.

<comment><USER4> yeah, me too.

</comment></comment><comment><USER5> Good documentation is key. It will be your main marketing vehicle. Study good online docs and copy their formats. You will start seeing patterns. They help with navigating and answering questions quickly. Leverage that. You could also have a workshop recorded and play it as a webinar. Good luck! :)

PS. Email me if you want feedback once you get going.</comment>


Is JavaScript becoming a Ruby killer? - <AUTHOR> http://blog.jaoo.dk/2008/09/11/is-javascript-a-ruby-killer/ <comment><USER2> No. I won't attempt to refute claims that Ruby is a temporary hype language (though I don't personally agree), but to suggest that Javascript will be the language to dethrone it is ludicrous. What he essentially suggests is that Javascript is becoming powerful enough to eliminate the current need for server side languages. This, simply, is not the case.

<comment><USER3> _What he essentially suggests is that Javascript is becoming powerful enough to eliminate the current need for server side languages._

I think it's obvious that JavaScript is as powerful a language as Ruby, on the "blub" spectrum, anyway. Where it fails is on connecting to the underlying OS --breaking out of the VM and doing something with the system, which is something that Ruby (and Perl, from which Ruby inherited most of this stuff) has in spades.

That said, when (not if) JavaScript gets a reasonable FFI and good ties to the underlying OS, on the order of Ruby, Python, and Perl, it will be the obvious choice for implementing just about everything. Faster implementations (V8 and Tracemonkey are faster for many classes of problem than any of the current dynamic language kings, and on par with Smalltalk) mean that once the "plays well with others" problem is solved sufficiently, there will be little reason to choose Ruby/Python/Perl except "I like it better"...and, though I do happen to like Ruby, Perl, and Python a lot, I also find JavaScript a very pretty language with a lot of power.

If it gets block scope (which Ruby also doesn't really have, I think?), and the previously mentioned FFI and OS integration, I will have nothing else to complain about (except the DOM).

<comment><USER4> What is preventing JS from running at the OS level? Couldn't it just borrow the engine of another language?

<comment><USER3> _Couldn't it just borrow the engine of another language?_

What "engine" do you mean? I'm not sure one can point to a single chunk of code in any mainstream dynamic language and say, "There! JavaScript needs that!"

libc is probably the place to start (it's where Perl started, anyway), though learning from the mistakes of prior languages that have solved these sorts of problems is also wise...while making it work the way a JavaScript programmer would expect. You couldn't simply take Perl's implementation and cram it into something else (though maybe you could on a Parrot-based JavaScript engine, or you could steal from JRuby on a JVM-based engine--I guess the Rhino folks have "solved" this by allowing access to the Java libs, but I'm not sure, as I've not yet used Rhino). It needs to work like JavaScript to be a "native" feature of the language, rather than consigned to the ghetto the way it has historically been under Lisp and Smalltalk.

In Perl, for example, one can open a filehandle, similar to opening a file handle in C minus all of the icky stuff, and then work on every line in a "while" loop very concisely ( while <> ... ). So, the underlying code is talking to libc (or the Windows API, whatever it's called), but the user sees Perl. So, just connecting JavaScript to libc isn't going to solve this problem...someone has to decide what "JavaScript file I/O" ought to look like, and build it on top of libc (and whatever the Windows API is), preferably with a reasonable standard being defined sometime soon after.

And that's just the beginning (though it's such an important, and challenging, beginning I'm having trouble thinking of what the other pieces are). In the end, before we can say "JavaScript is a Ruby/Perl/Python killer", it'll probably take a few smart people sitting down with Stevens' UNIX programming books and pretty much deal with all of the various things people do when programming on a UNIX (and whatever the Windows API bible(s) is/are) system. Signals and IPC, sockets, etc. Though the more I think about it, the more I realize that on UNIX, anyway, many of the "hard" things are just special cases of file I/O since most everything is a file anyway. So, really solving file I/O and providing a good FFI is probably a good 80% solution, and a CPAN-like library of code (JSAN, perhaps) could be developed by the community to fill the gaps.

So, best case unless the JavaScript standards folks start thinking about these problems...one or more engines will start with a decent FFI, and someone will design clever OS wrappings for the most important bits and people will begin building ad hoc solutions to the various OS interaction problems via libraries. It'll take several years, perhaps, after server-side adoption begins to grow before a clear consensus on best practices appears. This, of course, means we'll have a lot of incompatible and ornery JavaScript OS interaction libs for a while...which is a big problem, similar to C on Windows before a standard API emerged (and even UNIX if you count the networking API schism and the BSD vs. SysV split), for many years.

Looking a bit further into this, Mozilla has/had io.js (which talks to XPCOM), but I can't find it anywhere as all the links on Google are dead or outdated stubs that refer to the dead links, and Opera has file-io.js. Jaxer has some file methods, which seems to be a reasonable server-side implementation. All the APIs I could find seem somewhat ugly and lacking in the fun of working with files in Perl (which eats files like candy), though. Just not very "native" feeling. But, I guess it's a start...and given all of the other factors making JavaScript seem like a great idea on the server, it may be enough for many people.

I know I'm leaning more and more towards JavaScript for my next server-side project.

</comment></comment></comment></comment><comment><USER5> There's two possiblities here:

\- Will JavaScript displace Ruby as a server-side language?

\- Will developers push more and more of their application logic to the client, relegating the server to be a simple storage layer (with authentication, etc, thereby reducing the usefulness of server side frameworks like Rails.

I could see both happening. JavaScript is _the_ most widely deployed language to clients, and you can control what you deploy on servers, so it seems like the ideal language if you want the same across both clients and servers.

</comment><comment><USER6> No. Lots of people don't actually like JavaScript much, especially its inheritance model, which is why you get obscene over-the-top technical solutions to stop people from writing it. The language has also been slow to evolve to fix core problems with it due to the fact that any changes need to be agreed with by the major browser vendors. It's likely the language wouldn't be popular if it wasn't for the fact it is the de facto in-browser programming language.

FWIW, I actually /do/ like JavaScript.

</comment><comment><USER7> Do people actually like javascript, or just like the fact that it is de-facto always present in browsers due to its prevalence on the web (I could ask the same question about flash). The vast majority of client-side js I look at is spaghetti. To be fair, I'm looking at random webpages, not jQuery tutorial websites.

<comment><USER8> I like Javascript, and given the choice I'd use it server-side as well. It's an excellent language; very minimal, lends itself well to concise but powerful code, and can be made to do pretty much anything given a decent API.

Most of the Javascript you look at is terrible because most of it is copypasted from tutorials dating back many years, when Javascript was, at best, not very well understood or known, and not the domain of serious applications. The modern libraries like jQuery and Prototype definitely exemplify how Javascript could be though.

<comment><USER9> Actually, most JavaScript looks bad because of people cargo-culting bad DOM code.

I don't really like Javascript, but I do agree that the core language is minimal but complete. I will stick with Lisp when I want that, though, because Lisp is nicer looking and has macros.

<comment><USER10> Javascript is a nice language, but that won't decide much. I mean, look at Lisp.

(Speaking of Lisp, I recently discovered reader macros. I mean, damn, but they're awesome.)

</comment></comment></comment></comment><comment><USER11> Microsoft's had JScript and JScript.NET for server programming for a while and recently added Managed JScript: <http://en.wikipedia.org/wiki/JScript>

It's never really taken off, though Microsoft always pushed VBScript over JScript and C#/VB.NET over the managed JScripts. I used server-side JScript a little back in the old school ASP days and actually found it pretty confusing having both server and client code in the same language, though it sounded appealing in theory. More to wrap your head around.

I do admit a second love with client-side JavaScript after the recent resurgence, but I definitely don't see it displacing Python, Ruby, or even Perl anytime soon. The core language is nice, but it's got a long ways to go.

</comment><comment><USER12> The promise JavaScript holds for server side web apps is that a programmer is far more productive with a tool he knows exceptionally well than with several tools he knows just enough. In this way, JavaScript can be used on both client and server and the programmer gets to be a real pro at just one language instead of two or more. This is real value. But...sea changes in IT happen for lots of unpredictable reasons. Just because you have nice rational for why it makes sense does not mean it will happen.

</comment><comment><USER13> No discussion of meta-programming? Can you duplicate the Ruby tricks in JavaScript?

<comment><USER9> _the_ Ruby tricks?

Why couldn't you? You have anonymous functions in JavaScript, that's as much metaprogramming capability as you get in Ruby. (Notably absent from both are macros.)

<comment><USER14> Well, you are obviously right about JS having anonymous functions. In addition to anonymous functions, Ruby also has a very late-binding object and class system borrowed from SmallTalk that also--to the Java or C# programmer--looks like trickery.

This can be built on top of JS, of course, but I also recall Object Assembler ;-)

</comment></comment></comment><comment><USER15> To his Ruby 1.8 vs. 1.9 question: the difference isn't huge, and I don't think we'll see a split. You get fibers (coroutines); new hash syntax, like User.create(name: "David", address: "123 Fake St."), Enumerators, and lots of little changes. Ruby 1.9 programs should look pretty much like Ruby 1.8 programs for the most part.

The more likely split would be on the implementation level: MRI/YARV vs. Rubinius vs. JRuby vs. Gemstone. The camps are working together pretty well right now and aren't looking to divide the community, but I would hate to see it turn into a Lisp-like situation. No offense to Lisp - I love it from the outside, and would enjoy using it professionally - but the fragmentation is definitely a barrier to entry.

</comment><comment><USER16> uhhh, what? how does having faster, fatter client side effect the server side at all (in the m and the c.. the v may be data transforms from objects->html to objects->json.. meh)

he isnt even proposing JS on the server side.

</comment><comment><USER17> The browser is not the world.

</comment><comment><USER18> Client != Server.

<comment><USER19> I don't understand. I was actually writing server-side javascript before taking a break to read this site

<comment><USER20> [http://almaer.com/blog/rotating-java-and-javascript-on- the-s...](http://almaer.com/blog/rotating-java-and-javascript-on-the-server)

</comment></comment></comment><comment><USER21> There are too many script languages and implementation as is

<comment><USER9> Yup, and every time a new language becomes popular, it will make your app written in the "old" language stop working.

Oh wait, no.</comment></comment>


Discovering the Amiga 30 years late - <AUTHOR> https://www.reddit.com/r/amiga/comments/amwa6y/discovering_the_amiga_30_years_late/ <comment><USER2> True multitasking was handy on the Amiga when I wanted to do, e.g. movie- making and photo-editing while bouncing through the OS' file-manager. It really was like having multiple computers running simultaneously, in one box.

Like early Android vs early iPhone, one could be more productive on Android, until iPhone received multitasking, with apps holding state between de/re- focus.</comment>


Go Proposal: Accept GitHub PRs - <AUTHOR> https://github.com/golang/go/issues/18517 <comment><USER2> I'd be curious to hear more about why the Go team thinks Gerrit is superior to Github for code reviews.

As far as I can tell, Github's latest additions to their code review flow pretty much brings Github on par with Gerrit (and with also a much larger mind share. Gerrit has always remained quite obscure and marginal).

<comment><USER3> Changesets are a big deal for seeing progress towards code review feedback.

Changesets take the typical GitHub workflow where the author force pushes to the PR to address comments and creates another "version" of that PR, with a new set of inline comments, but sharing the overarching PR comments. You can compare and contrast any set of "PR versions" in order to determine the changes applied by the author.

I desperately wish GitHub PRs worked this way.

<comment><USER4> I use a tool [https://reviewable.io/](https://reviewable.io/) which adds this functionality (and some other stuff) on top of GitHub PRs and it's invaluable.

<comment><USER5> +1 for reviewable. In addition to this feature reviewable's diff display is a lot nicer. For example it does a much better job handling whitespace only changes when a block of code gets reindented but otherwise doesn't change.

<comment><USER4> Oh yeah, collapsing whitespace-only changes is excellent. But even better is how it can detect and collapse changes introduced by rebasing the PR.

<comment><USER6> You can hide whitespace-only changes in GitHub by appending ?w=1 to the end of the url too.

<comment><USER4> But that makes the whitespace changes literally invisible. Reviewable strikes a good balance, where it will show you whitespace changes that appear in diff hunk contexts, and also explicitly call out when it's skipping a chunk of whitespace-only changes, and you can click on that callout to ask it to show you those whitespace changes anyway.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> With Servo we use [https://reviewable.io/](https://reviewable.io/) on github.

We don't enforce its use. If a newcomer makes a pull request, we'll just use the GH review interface. In general simple PRs go through the GH review interface, regardless of who they're from. We break out Reviewable when a PR actually _needs_ it (this is usually the choice of the reviewer).

This means that Servo continues to have a lower bar to contribution, without hampering maintainers on PRs that need more than GHs set of review features.

This has worked out well for us.

<comment><USER8> I've contributed to another Google project ([http://vitess.io](http://vitess.io)) that used the the same process. So while Go is a completely different team, it's not exactly unknown within Google. Reviewable is a dramatic improvement over the stock Github tooling.

</comment></comment><comment><USER9> Seems like a lot of hoops to jump through, I wonder why they want to use Gerrit. Meanwhile Elixir you open a PR and Jose and the gang address it quickly.

4 open PR's! [https://github.com/elixir- lang/elixir/pulls](https://github.com/elixir-lang/elixir/pulls)

<comment><USER10> Hey, we're getting downvoted! I guess gophers aren't so pragmatic after all, I thought they followed New Jersey style!

</comment></comment><comment><USER10> I can't help thinking that requiring a specific code review tool is a bit ridiculous, especially considering the hoops they want to jump through to enforce it.

<comment><USER11> Because maintainer timer is, in your world, a worthless thing?

<comment><USER10> No, because the tools are very similar and they can just ask contributors to adapt to the maintaners wishes. Code diffs are such a small part of reviewing a new feature. "Just deal with it" is what I think. I don't require notepad on my Mac, so why should they require gerrit on github? And besides, if they want to they can just diff it on their own machines with whatever tools they like!

<comment><USER11> Gerrit and Github are not "very similar". They are quite different. (Something that would be rather immediately clear to anyone who used either for some duration)

> And besides, if they want to they can just diff it on their own machines > with whatever tools they like!

Oh yes, a very compelling argument when discussing _workflow tools_ is to suggest local diffs. Bravo!

<comment><USER10> Well, I happen to have used both. And it all depends on your perspective. I would change my tools in a heartbeat to streamline the process for users or contributors. To me it depends on if you're user focused or technology driven. I think it's kind of akin to switching to git but insist that all merges have been done with perforce merge, because I think it's better in some way. Sure, it might be true, but do you really want to go against the stream to prove your point?

</comment></comment></comment></comment></comment><comment><USER12> I contribute pull requests to quite a few github projects. However I avoid contributing to (or even using) projects with a Contributor License Agreement. Such projects are too bureaucratic.

<comment><USER13> > I avoid contributing to (or even _using_ ) projects with a Contributor > License Agreement.

That's a pretty tough thing to do. Most (all?) Apache projects require a CLA, as does Go, Java, Mysql, Cassandra... It's pretty standard for any project that is both managed by a corporation and accepts third-party contributions.

EDIT: removed Postgres. Thanks, 'anarazel!

<comment><USER12> ~~You got me on Postgres. Don't use the others.~~

Edit: another post states that Postgres doesn't require a CLA for contributors. So I don't use any software requiring a CLA.</comment></comment></comment>


Why we created Julia - new language for fresh approach to technical computing - <AUTHOR> http://julialang.org/blog/2012/02/why-we-created-julia/ <comment><USER3> I wonder what they think about or have learned from <http://en.wikipedia.org/wiki/Fortress_(programming_language)> , another recent-ish attempt to deliver a modern and powerful scientific programming language.

Personally I'm a little wary of being ghettoised into something overly domain- specific for scientific/numerical computing. Really good interop may mitigate that -- something which can navigate the unholy mix of C, C++, fortran, matlab, octave, R and python routines one comes across trying to reproduce others research work, would indeed be awesome.

I do wonder if some of the noble demands of this project might be better delegated to library developers though, after adding a bare minimum of syntax and feature support to a powerful general-purpose language. For now Python+numpy+scipy seems a great 90% solution here.

<comment><USER4> Python+numpy+scipy does work only if you actually don't write much python or at least not run much python. Otherwise it sucks

<comment><USER5> I wouldn't say that it sucks - that's way too strong. I am one of the authors of Circuitscape (<http://www.circuitscape.org>), which uses python+numpy+scipy. The community loves it, the fact that its python, open source, embeddable in other tools, etc.

However, much of the code is written in a vectorized style for performance reasons, as is the case with many high level scientific computing languages. This leads to unnatural code in some cases, and also uses too much memory. First I thought IronPython was the way, but have been looking forward to pypy+numpy+scipy eagerly.

If I were to use julia, the code would be a lot more natural, because type inference and all the compiler goodies make it possible to simply write loops over arrays when I need them. This was one of the reasons we started working on julia, because everything else just seemed to fall just a little bit short.

<comment><USER6> What do you think of cython+python+numpy? I've used it successfully to do NLP work.

</comment></comment></comment></comment><comment><USER7> Much praise!! These guys have incredibly good taste. Almost every single thing I can think of that I want in a programming language, they have it. All in the one language!

The fact that it has parametric types, parametric polymorphism, macros, performance almost as good as C, good C/Fortran interop, 64 bit integers and an interactive REPL all in the one language just blows my mind.

I wasn't able to tell if it is possible to overload operators, which is another thing essential to mathematical code.

I was also unsure why the keyword end was needed at the end of code blocks. It seems that indentation could take care of that.

I also didn't see bignums as a default type (though you can use an external library to get them).

However, all in all, I think this is the first 21st Century language and find it very exciting!

<comment><USER8> I think they are aiming for smooth transition for MATLAB users. They also have 1-index based arrays as opposed to 0-index .

<comment><USER7> It would certainly be nice if there was an option to use 0 based indices in blocks of code. It's understandable in that they are pitching at the technical community, and many mathematical papers and books are written with 1 based indices. But I am a mathematician who prefers 0 based indices.

<comment><USER5> Actually, it is quite easy to implement 0 based indices or any other indexing scheme in julia, since all the array indexing code is implemented in julia itself.

[https://github.com/JuliaLang/julia/blob/master/j/array.j#L15...](https://github.com/JuliaLang/julia/blob/master/j/array.j#L157)

I personally would find multiple indexing schemes confusing both for usage as well as to develop and maintain. Given that 1 based indexing seems to be a popular choice among many similar languages, we just went ahead with that.

<comment><USER9> Have you looked at the Haskell Ix class? <http://www.haskell.org/onlinereport/ix.html>

It generalizes the choice of 0 or 1 to an arbitrary starting index. So when you create an array you specify not just where it ends but also where it begins. This lets you do neat things (consider a filter kernel with range [-s,+s]^n instead of [1,2s]^n) and the extra complexity it adds can be hidden when not needed using for-statements or higher order functions.

Nobody uses it because the implementation is not very efficient and Haskellers have a chip on their shoulder about performance. It subtracts the origin and computes strides on every index, but you could easily avoid this by storing the subtracted base pointer and strides with the array. Of course when you go to implement it you'll see light on 0-based indexing :)

</comment></comment></comment></comment></comment><comment><USER10> Just spent the last hour reading through the docs and playing around with it. This is some damn sexy stuff. It's been a long time since I've been this excited by a language.

</comment><comment><USER11> The language looks interesting, but I am a bit concerned about the license situation, as in my understanding they have misinterpreted the GPL with regard to shared libraries. Quoting:

 _Various libraries used by the Julia environment include their own licenses such as the GPL, LGPL, and BSD (therefore the environment, which consists of the language, user interfaces, and libraries, is under the GPL). Core functionality is included in a shared library, so users can easily and legally combine Julia with their own C/Fortran code or proprietary third-party libraries._

The FSF disagrees (<http://www.gnu.org/licenses/gpl- faq.html#NFUseGPLPlugins>):

 _If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug- ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins._

<comment><USER12> I believe what they're saying is that there are two things:

1\. The Julia core, which consists of the language runtime and core functionality, is MIT licensed, and builds into an MIT-licensed shared library.

2\. The Julia "environment", which includes a user interface, third-party libraries, etc., some of which are GPL, and which is therefore GPL as a whole.

I believe they're saying that you can link #1 with proprietary code, not meaning to imply that you can link #2 with proprietary code (because as you point out that wouldn't work). How useful that is probably depends on how many of the libraries the average application needs are in bucket #1.

<comment><USER13> That is exactly right. At the moment I think the only GPL library Julia uses is readline — but obviously that's pretty important for the repl, so we chose to do it this way.

<comment><USER14> The last REPL I wrote used linenoise ( <https://github.com/antirez/linenoise> ) instead of readline, and it worked great for us. You may need more of readline's features than we did, but it's worth a look.

</comment></comment></comment></comment><comment><USER15> Awesome stuff: <http://julialang.org/manual/metaprogramming/>

<comment><USER16> It's great the metaprogramming support seems to be a requirement for new languages these days.

Unfortunately, this one combines the inconvenience of Template Haskell (explicit invocation of macros with @) and the bugs of Common Lisp (the section on hygiene says, basically, "we have gensym"). Fortunately, the language is young, and I hope they can improve this story.

<comment><USER17> What else would you suggest?

I find that the @ syntax is amazing, since the reader (programmer) knows exactly which form is a macro (and can look it up), as opposed to introducing arbitrary, often very confusing syntax.

<comment><USER13> Thanks. We've considered doing other things — like function call syntax for macros (which is essentially what Lisp/Scheme have), but decided against it. It just causes confusion. Can you pass a macro around like you can a function? Can functions shadow macros and vice versa? What happens if a macro introduces a local variable that shadows the macro itself? Basically it comes down to fact that macros are syntactic and as such behave very differently from functions, which are not syntactic. With the @ syntax, there's no confusion.

<comment><USER17> Just a comment/suggestion: could someone with GitHub write access go over your wiki and fix code samples where multiple lines have been concatenated into a single line? E.g. [https://github.com/JuliaLang/julia/wiki/Types-and-their- repr...](https://github.com/JuliaLang/julia/wiki/Types-and-their- representations), heading `Built-in types`.

<comment><USER13> We've actually switched the documentation over to the main website: <http://julialang.org/manual/>. The website is hosted on GitHub using Jekyll: <https://github.com/JuliaLang/julialang.github.com>. As a side-effect, you can edit the docs and create pull requests, which you can't do on GitHub wikis.

</comment></comment></comment></comment></comment></comment><comment><USER18> It's not yet another language that we need. It's more high level functions.

C or fortran can be as fast as they want, but in mathematica I can do MorphologicalComponents[] and get the components. having these functions available to me speeds up my time to discovery by 1000x or more.

</comment><comment><USER19> Looks very much like a python without the legacy and a touch of ruby, ipython as the default shell, better multiprocessing, better os/system access, decorators and mathematics. Nice clear documentation too.

Given how similar to python they are their main competitor is pypy, which isn't too far behind them in performance I'd suspect (absent from the benchmarks though). I was fully expecting someone to make a non-compatible fork of pypy to create a faster python-like lang/something like julia. They should quickly get some elegant small libraries like sinatra/bottle and requests (access to dbs with http interfaces as well). A robust requests+lxml library built-in would be simply amazing.

<comment><USER20> PyPy provides an entire framework for people to write interpreters in. If you were to write one you wouldn't fork PyPy, you would use it.

<comment><USER19> Well you are being a bit nitpicky as pypy is both the python implementation and the JIT/Rpython/framework bit. What I mean was someone holding very close to the python implementation in almost everything (syntax etc.) but streamlining it/breaking compatibility/giving it a new name ("python3-as-it- should-have-been" perhaps?).

Further, if we are going to be nitpicky, when you use something like that for its intended purpose it's still a fork - I forked Twitter bootstrap for my new project/I used Twitter bootstrap for my new project - so "you wouldn't fork PyPy" is a false statement.

<comment><USER21>
      >  if we are going to be nitpicky, when you use something
      > like that for its intended purpose it's still a fork

No. Fork is definitely not semantically congruent with use. You're only forking Bootstrap if you create a path that diverges from its mainline; don't get confused by GitHub parlance.

<comment><USER19> Pypy most commonly refers to the python implementation anyway, as can be easily seen by going to the pypy website[1]. Daslch abused the fact that "pypy" points to two things to make a meaningless nitpick. Now you are claiming that I have claimed that fork and use are semantically congruent, where do I claim that? I think you are nitpicking and parsing "it" wrong. In either case a question asking for clarification would be more polite than going on attack.

There seems to be a disease, let's call it Eric Raymond Disease (ERD), on HN in particular[2] of people busting in rudely to declare with supreme confidence on the usage of quite generic words and/or slang. Let's start by tabling the fact that a particular "software definition" of "fork" has not yet reached the OED, or online dictionaries like Merriam-Webster for that matter. Going from that I can't see how you can declare it to only have one definition when _you already admit there is a competing one_ ("GitHub parlance"). The base concept of the word fork is a divergence, a branch, which seems to me to cover any copy+modify move for software so someone copy+modifying bootstrap is forking it, someone copy+modifying the _implementation of python called pypy_ is forking _it_.

Are you and Daslch really contributing to HN or are you taking a rather banal comment and turned it into a 100% useless thread by bickering over semantics?

[1]<http://pypy.org/> [2]<http://news.ycombinator.com/item?id=3467035>

</comment></comment></comment></comment></comment><comment><USER22> Pardon the possible naïveté, but I'm so old I remember Ada. Seems that language was designed to address a very similar problem space. What does Julia offer that Ada doesn't? Or perhaps: why is ada so deficient that spending 2+ years inventing a new language was a better proposition than taking the time to improve Ada?

<comment><USER23> While there's a resurgence of interest in ADA recently, the general sense is that it's WAY overdesigned and heavy.

I came across this bit of humor a while back that communicates the general feeling well:

<http://bit.csc.lsu.edu/~gb/csc4101/Reading/gigo-1997-04.html>

If the problem IS that it's huge and inelegant, then the solution isn't to try to improve it, but to start from a clean slate. Julia looks like a reasonable attempt.

<comment><USER22> Funny, I remember reading similar conspiracy claims about C.

</comment></comment></comment><comment><USER24> I have made the same rants about numeric computing language issues as the Julia creators. I would avidly adopt Julia based on the documentation on the website. It seems to me that this is a beautifully conceived language given the concerns it attempts to address. Amazing even if the performance never improves.

The R thread on the dev list gives an accurate representation of the obstacles to Julia being widely adopted, however. One might become very unhappy while using R, but sometimes you have to use it, because something you want is only in R, due to the ubiquity of that tool for stats.

If Python, which does not have that many disadvantages besides not having been explicitly designed to appeal to users like me, cannot unseat Matlab and R, Julia will have a difficult time.

But I will give it a try, and will implement some simple but core algorithms that I use a lot.

Another idea to test Julia's usefulness would be to port a tool like Waffles to Julia. In my opinion implementing such a sensible tool like Waffles in C++ is a heartbreak.

</comment><comment><USER25> I'm a little worried about some of those benchmarks. They appear to have benchmarked R from a few years back against 2011 Matlab, for instance. In addition, they provide no code used for the benchmarks. That being said, this looks really interesting, and I'm gonna bookmark it for when I have time to examine it properly (after the damn phd is finally submitted).

<comment><USER26> They do link to the code: <https://github.com/JuliaLang/julia/tree/master/test/perf> . It doesn't look like a very reliable microbenchmark - run test x 5 times - but it should provide a useful starting point if you want to run your own.

<comment><USER25> Thanks guys, I'm not sure how I missed that. The benchmarks look interesting, but it is strange how old an R version they used. That being said, its a really interesting language, and I look forward to playing with it.

</comment></comment></comment><comment><USER27> This looks like it would be a great language to tackle the Project Euler problems with - which is usually a good sign, in my book. A big-int type would be nice though.

</comment><comment><USER28> So, the usual caveats about writing code to match the languages strengths apply here. For example the fib function plays to a python weakness - <USER2> overhead. Rewriting the code to be a simple loop removes the inefficiency:

      import time

      def fib(n):
        if n < 1:
          return None
        if n == 1:
          return 0
        if n == 2:
          return 1
        x0 = 0
        x1 = 1
        for m in range(2,n):
          x = x0 + x1
          x0 = x1
          x1 = x
        return x

      if __name__=="__main__":
        assert fib(21) == 6765
        tmin = float('inf')
        for i in xrange(5):
          t = time.time()
          f = fib(20)
          t = time.time()-t
          if t < tmin: tmin = t
        print str(tmin*1000)

<comment><USER13> That's quite true, but this micro-benchmark wasn't chosen to make Python look bad — it was chosen to test how good each language was at function calls. So using a loop defeats the point of the benchmark. Using double recursion to compute Fibonacci numbers is also stupid and could obviously be avoided in all languages.

The story the micro-benchmark tells is that Julia's pretty good at function calls, but JavaScript is even better (and, of course, C/C++ is the gold standard). In general the V8 engine is really amazing. We had the advantage of being able to design the language to make the execution fast (with the constraints of all that we wanted to be able to do with it), but V8 makes a language that was in no way designed for performance and makes it blazingly fast.

After I wrote the benchmark code for JavaScript and saw just how fast it was I had a moment of "should we be doing scientific computing in JavaScript?" Now wouldn't that be nuts?

<comment><USER5> Yes, I pretty much had the same thought, but then I started thinking about multiple dispatch, calling C/Fortran libraries, polyhedral optimizations, and I realized that V8 developers may not have the same design targets in mind.

<comment><USER29> ... and the JVM (HotSpot) is even better than V8.

<comment><USER13> I feel like V8 faces a harder problem and has solved it ingeniously. Not to knock HotSpot, which is excellent and keeps getting better — it just seems like making the JVM go fast is not as hard as making something like JavaScript go fast. It's a tough comparison; kind of apples to oranges.

</comment></comment></comment></comment></comment><comment><USER30> Nice! I do a fair amount of scientific computing in MATLAB. This looks to have a lot of the powerful array syntax / functions of MATLAB, but with the neat feel of Python, and all kinds of extras.

</comment><comment><USER31> When you try to install julia on MacOS X 10.7.3, you may see the make fail because wget is not installed. Easy to fix with:

brew install wget

[Edit] git page says gfortran (and wget) are downloaded and compiled, but if they're not already installed make fails. So...

brew install gfortran

The need to do this separately may have to do with licensing?

[Edit] And if you're not root, install to /usr/share/julia will fail. So you'll need to do:

sudo make install

I'm sure all this is perfectly obvious to Unix-heads who are inured to this sort of abuse, but I'm a Mac-head, used to things that Just Work, and I hate this shit.

<comment><USER13> Sorry! The only thing I can say in our defense is that this is pretty trivial compared to installing a lot of scientific computing packages. But seriously, we'd like a drag-and-drop Mac installer. Anyone want to do that? (Only half kidding.)

Stepping back a bit, this is one of the reasons why having an entirely web- based experience is appealing — then you can let people use a known-good setup without needing to mess around with installing a fairly extensive amount of software just to get basic things to work. Then there's also the general appeal of doing big data work a la Google docs or Gmail. The trick is getting the user experience to be good enough on the web.

<comment><USER31> Please don't let perfection tomorrow keep you from meaningful improvements today. Just better instructions for Mac installs would be helpful!

</comment></comment></comment><comment><USER32> Slightly off topic, but V8's benchmarks really surprised me

</comment><comment><USER33> Pretty tied into Python/Numpy ecosystem & 3rd party libs; however, after reading that (somewhat over the top, albeit very persuasive) posting, I'm definitely going to dig a bit deeper. Really nice first impression, especially like the clean syntax and calling of c -- looks promising, thanks!

</comment><comment><USER34> this is surprisingly complete for a relatively new(?) project.

one notable restriction is that inheritance is only for interface, not implementation.

also, can anyone find a sequence abstraction (like lists)? arrays seem to be fixed size and i don't see anything else apart from coroutines. am i missing something?!

[perhaps not, if it's intended for numerical work. on reflection i am moving more and more towards generators (in python) and iterables (in java, using the guava iterables library to construct maps, filters etc) rather than variable length collections, so maybe this is not such a big deal. it's effectively how clojure operates, too...]

<comment><USER13> pron is right: you can inherit behavior from abstract types and abstract types, unlike interfaces, can have code written to them. (In single-dispatch OO languages, you are in the strange situation that you can write code to interfaces if they are arguments but not if they are the receiver of a method; thus, you're in a situation where you can either dispatch on an interface _or_ you can write code for it, but never both at the same time.)

Arrays are not fixed size: there are push, pop, shift and unshift operations on them just like Perl, Ruby, etc. This uses the usual allocation-doubling approach so that the entire array doesn't need to be copied every time, but it's still usually much better to pre-allocate the correct size. Of course for small arrays that are typical in Perl, Ruby, etc., it hardly matters. If you're building an vector of 1 billion floats, however, you don't want to grow it incrementally.

The sequence/iterable abstraction is duck-typed: an object has to implement methods for three generic functions:

      i = start(x)
      done(x,i)
      next(x,i)

The state i can be anything.

Lack of implementation inheritance is one of those things that intro to OO books make a big deal of, but when you don't have it, you don't miss it at all — or at least I don't. I've never found tacking a few fields onto the end of an object to be very useful. I don't want to inherit memory layout — I want to inherit behavior. Julia's type system lets you write behavior to abstract types and inherit that for various potentially completely different underlying implementations.

<comment><USER29> I don't know if I'd call it duck-typing when methods are not grouped into interfaces. I think you could say that in Julia, each method is an interface. I find it much cleaner than actual "duck-typing" (the way it's done in , say, Scala with structural types) because then you have both an interface, which specifies a contract, as well as the method name, which also specifies a contract when duck-typing is used, even when it's found in different interfaces.

Must compound types in Julia be concrete? I don't think I saw it in the documentation.

<comment><USER13> It's been discussed, and would be satisfying to have an `Iterable` abstract type and ensure that every object implements `Iterable` satisfies contract of having appropriate `start`, `done` and `next` methods, but that requires two features we don't have yet: multiple inheritance of abstract types, and some way of specifying an interface. There's been some discussion of this, and I believe we have the way multiple inheritance _could_ work mostly worked out; enforcement of interface implementation, not so much. However, it's a pretty massive undertaking to add it to the language. Quick teaser: generic functions and final concrete types actually make multiple dispatch work a lot better than it does with single dispatch and the "bag of named methods inside an object" model of traditional OO.

So far we haven't actually felt a "pressing need" for multiple inheritance or interfaces, and we tend to take a pressing-need approach to language features. If you can live without a feature for a while, then maybe you really didn't need it in the first place. But we'll have to see what happens when other people are starting to try to use if for things.

Aren't compound types inherently concrete? The compoundness describes the implementation of the type, implying that it must have an implementation, hence must be concrete.

</comment></comment></comment></comment><comment><USER35> I am currently building it - OS X Lion. First, I had to install wget:) Then, I got a certificate error on the https, so I pasted the command into Firefox and got the tarball. After copying it to the julia dir, I edited the tar command and ran it. Finally, doing make right now.

Here is the certificate error: Connecting to github.com (github.com)|188.8.131.52|:443... connected. ERROR: The certificate of `github.com' is not trusted. ERROR: The certificate of `github.com' hasn't got a known issuer.

<comment><USER5> We used to use curl until recently so that it would build just fine on OS X. We changed it to wget, because it just seems so much easier to use than curl, and we had to do some nasty stuff at one point to download a few libraries that I couldn't figure out how to do with curl.

BTW, do try out the mac binaries if the build is an issue. We are still trying to make it all build seamlessly!

<comment><USER13> For the record "ease of use" was not why we switched to wget — there was (for a while) a dependency that could only be downloaded using wget's recursive downloading. That's not the case anymore, however, so we should really switch back to curl.

</comment></comment></comment><comment><USER8> Very exciting. The real power of MATLAB likes in its toolboxes, though, I wonder if there will be an easy (and possibly automatic) way to convert toolboxes.

One more thing: it would be awesome if the `manipulate` from Mathematica could be incorporated somehow in that web interface. See:

<http://www.wolfram.com/broadcast/videos/manipulate/>

<comment><USER5> MATLAB toolboxes are simply awesome for users, even though they are expensive. We hope that if enough people find julia useful, many such libraries will be built. Having written a ton of mex and matlab stuff, and a lot of julia libraries, I find that julia is nicer to use personally - but of course I am biased. :-)

I do believe that open source + good compiler + simple C/Fortran calling interface will lead to others being able to write toolboxes in julia itself and plugin libraries when needed.

</comment></comment><comment><USER14> Would be interesting to see how Julia perf compares to C++ compiled or JITed with LLVM via G++ 4.6+Dragonegg or Clang 3.0/svn. Would be more apples-to- apples, since both would use the same middle- and back-end. G++ 4.2.1 is a bit obsolete at this point, but as it probably came by default on the MBP they tested on, it's understandable.

<comment><USER13> That would certainly be doable. If the performance is better, we can certainly switch to using that for our benchmarks. The idea for the benchmarks is to compare to a "gold standard" — hence the fact that the best results are taken across all optimization levels. We could even take the best results across multiple C compilers to give ourselves the absolute hardest comparison :-)

</comment></comment><comment><USER36> For analogy there are few original liquor (vodka,rum,Whiskey,Brandy,Wine etc..) but god damn so many cocktails, so many cocktails.

Same in Programming Language design. Few original concepts, Lisp,C,Smalltalk, but so many cocktails even my grandma is creating one. All we want is more libraries.

</comment><comment><USER37> I'm more concerned with visualizing the data than with compiler optimizations or types/operators.

I see that d3.js is included in the package, but a cursory glance at the docs and I didn't see any examples of how to generate a chart.

</comment><comment><USER38> I hope this really takes off. Though, for it to really take off it needs a large ecosystem. The fact that the source is hosted on Github is a good start.

</comment><comment><USER39> If you look at the Github repo, you will notice the second most used programming language in the repo (C being the first) is Objective-J ! I wonder why?

<comment><USER10> Because the julia source file names end in .j, probably.

<comment><USER13> bingo.

</comment></comment></comment><comment><USER40> This is very exciting - congratulations on the launch of Julia. Now good luck as you move towards building a strong community!

</comment><comment><USER40> Anyone else having compile issues? I'm on Ubuntu 11.10 (Server x64) and make fails consistently.

<comment><USER5> Is it due to openblas not building? This may help:

<https://github.com/JuliaLang/julia/issues/370>

<comment><USER40> Thanks for your suggestion. I tried that, but it wasn't it. I'm still getting lots of build errors, culminating with this:

Saving to: `lapack-3.4.0.tgz'

2012-02-19 01:03:26 (55.3 KB/s) - `lapack-3.4.0.tgz' saved [6127787/6127787]

make[3]: gfortran: Command not found make[3]: __* [lsame.o] Error 127 /bin/sh: ./testlsame: not found /bin/sh: ./testslamch: not found /bin/sh: ./testdlamch: not found /bin/sh: ./testsecond: not found /bin/sh: ./testdsecnd: not found /bin/sh: ./testieee: not found /bin/sh: ./testversion: not found make[2]: __* [lapack_install] Error 127 make[1]: __* [lapack-3.4.0/INSTALL/dlamch.o] Error 2 make: __* [julia-release] Error 2

<comment><USER41> Is package gfortran installed?

<comment><USER40> @olaf: I was missing gfortran and libncurses5-dev. It's working now, sweet. :)

</comment></comment></comment></comment></comment><comment><USER34> a bit late to the party here, but i see no-one has mentioned gpus. since julia supports calling c libraries i guess this will work, but i wondered if anyone knew of any work on closer integration?

(also, julia is not a great name for googling....)

</comment><comment><USER42> Is Julia homoiconic? Could someone give an example of a Julia macro?

<comment><USER43> <http://julialang.org/manual/metaprogramming/>

</comment></comment><comment><USER44> Their site seems to be taking a hammering. Any mirrors?

<comment><USER13> We're GitHub hosted so hopefully this doesn't take GitHub down! (j/k)

</comment></comment><comment><USER45> How does one open up a socket in Julia?

</comment><comment><USER46> Do you also want ice cream on top?

</comment><comment> k-a-r awesome language but the manual need some works in user-friendliness

</comment><comment><USER47> Congrats! Great job!!

</comment><comment><USER48> And the moon on a stick :-) Not sure many "technical" programmers would take c as the desert island programing language.

Sound interesting though if it can make hadoop easier to use id take that as win I dont think its going to replace fortran as a HPC language.

<comment><USER49> C as desert island programming language but making all indexing 1-based: "the first element of any integer-indexed object is found at index 1, not index 0, and the last element is found at index n rather than n-1, when the string has a length of n." Also begin end blocks - maybe there was a pascal ninja hidden in the syntax committee room?

<comment><USER10> Matlab, Octave, Mathematica, and other mathematical programming environments use 1-based indexing, it's a well-established norm for the domain.

<comment><USER50> Does 1-based indexing have any advantage, beyond familiarity to scientists?

<comment><USER51> With 1-based indexing, length == last index.

Does 0-based indexing have any advantage, beyond ability to do pointer arithmetic with indexes?

<comment><USER52> In 0-based indexing, n % length is a value inside the range.

</comment></comment></comment></comment></comment></comment><comment><USER53> They want something like OCaml ...

</comment><comment><USER54> No Windows support, really ?!

<comment><USER55> That's pretty common for new language implementations - Node.js was around for a couple of years before the Windows port was ready.

To be honest, if you're targeting early adopters of a programming language Linux and Mac support is probably a lot more important than Windows. Smart Windows users can always run Linux in a VM.

<comment><USER48> and most users of this sort of languages aren't going to be running it on windows but on Unix systems.

<comment><USER54> Are you insinuating that Windows users are too stupid to use those languages (and use only rotten ones like V.B etc. ) ?

Please, be a minimum objective and constructive.

<comment><USER56> I doubt it was intended as an insult. Julia (and other scientific languages) are often used in clustered environments, and Linux is much, much more common than Windows in HPC.

</comment></comment></comment></comment></comment><comment><USER57> Obligatory xkcd: <http://xkcd.com/927/>

It's about standards, but it still applies.

<comment><USER13> I realize this is just a comic, but it's one of the reasons that we try to be as compatible with C and Fortran libraries as possible — that's where the vast bulk of high-quality scientific computing work has been done, and we want to be as compatible with it as possible. The goal here is not to duplicate all the work that's already been done, but to allow existing high-quality libraries to be smoothly and easily used together in one environment. That's very much the same philosophy that NumPy and SciPy have, and indeed, it much the same goal. The biggest issue with NumPy, IMO, is that Python arrays aren't designed with linear algebra and interoperability with libraries like BLAS and LAPACK in mind. This leads to the somewhat maddening distinction between Python arrays and NumPy vectors and matrices — and lots of conversion back and forth between them.

<comment><USER57> I also posted that comment without reading the article -- that was just my first response to "yet another programming language".

I'm sure that it's filling a real need. I just wish that groups could cooperate to make a handful of languages/libraries better rather than having 100 competing ones.

<comment><USER5> Actually, there is much more co-operation than is visible. Almost all the groups share the same libraries, same bugfixes, same patches, etc., which typically will account for much of the user experience.

The different language approaches will typically compete on things like syntax, speed, etc., and this leads to innovation and cross-pollination of ideas. I personally prefer to have some choice, and use a number of languages for scientific computing myself - but I guess too much choice makes things confusing for the newcomer.</comment></comment></comment></comment>


Godep: Dependency Management in Go - <AUTHOR> https://blog.codeship.com/godep-dependency-management-in-golang/

<comment><USER2>
        > Godep works differently than the endorsed approach…
        > Instead of requiring changes to be made to the source
        > code to support the vendored import path, the GOPATH is
        > modified to use the vendored folder.

This isn't correct — Godep has two modes, and this is just one of them. The other way is indeed rewriting import paths.

This is incorrect on another level, too. Rewriting import paths isn't "endorsed" by the Go authors. In fact, Russ Cox, in his GopherCon 2015 keynote, explicitly noted that

        > Our basic proposal was that all tools agree on the
        > approach of rewriting import paths during vendoring...
        >
        > [But] the community spoke with essentially one voice to
        > say that rewriting import paths during vendoring was not
        > tenable...
        >
        > Keith Rarick posted an alternate proposal for a minimal
        > change to the go command to support vendoring without
        > rewriting import paths . . . That proposal will ship as
        > an experimental feature in Go 1.5 and likely enabled by
        > default in Go 1.6.

Dependency management in Go is an ongoing sore spot, but there's light at the end of the tunnel, in the form of the referenced proposal[0], its spec[1], and the third-party tool gb[2]. Godep was a good intermediate solution, but it should no longer be recommended as something worth exploring.

[0] [https://blog.golang.org/open-source](https://blog.golang.org/open-source)

[1] [https://github.com/kardianos/govendor](https://github.com/kardianos/govendor)

[2] [http://getgb.io](http://getgb.io)

<comment><USER3> Thanks for the feedback! We're certainly excited about the recent move towards go's experimental vendoring, I can't say I've had many positive experiences with vendoring myself as it is. The only thing worse than vendoring is not vendoring.

This article is a little outdated in terms of the maintainers endorsements, I'll see if we can update it with that, along with the correction.</comment></comment>