Ask HN: What is it like to run a VPN as a business? - <AUTHOR> Hello,
I'm going to set up my own VPN on some cloud hosting provider, and I'm toying with the idea of turning it into a small business.
Is there anything I need to know beforehand? Is it really that easy, or are there legal issues I need to handle?
Cheers
EDIT:
I should note that I know this is an extremely saturated market - I'm not aiming to build a hyper successful business, but moreso to manage a small public VPN as an ideological side-project. Anything above breaking even I'd consider a bonus. <comment><USER2> The fact that it is easy to set up a VPN does make this more competitive but that doesn't mean you can't build a business. Think about who your customers will be. Is there an underserved niche that you can reach? It might take a HN reader 10 minutes to set up a VPN but my mom wouldn't be able to figure it out if you gave her 10 months.

My battle plan for assessing whether or not I would pursued this would be the following:

1\. Who is my target market?

2\. How big is that market?

3\. How will you reach that market?

4\. How can you test whether or not you can reach that market before getting fully invested?

5\. Test out several ways to reach your market. Try changing the niche and marketing plan until you can find some positive signals.

6\. Analyze the data and make an educated guess whether this is worth your time or if you would enjoy doing something else more.

As far as legal issues, I don't have any good advice but talk to a lawyer. Look at some terms of use of existing VPNs. Find out where you are liable and try to mitigate your risks the best you can.

If you ever want to brainstorm some ideas hit me up at my email on my profile.

<comment><USER3> Adding an example of a niche: Those who wish to crawl Google/Bing/Amazon/Youtube results for SEO analysis around the world. You'd write a wrapper or other positive list of domains allowed through the proxy.

<comment><USER4> One very interesting niche that I recently learned about was providing a VPN with a "residential" IP block that could be used to geo-shift netflix viewing:

[https://www.lowendtalk.com/discussion/138668/vps-for-us- netf...](https://www.lowendtalk.com/discussion/138668/vps-for-us-netflix/p1)

Apparently there are a lot of people who would like to watch "US Netflix" but cannot do so from their location.

<comment><USER5> It's the main usage of VPN (as well as region locked mmos) for those who are not doing it for security.

<comment><USER6> The Consumer advocacy group here in Australia, CHOICE, specifically recommends using a VPN service to avoid geoblocking ([https://www.choice.com.au/electronics-and- technology/interne...](https://www.choice.com.au/electronics-and- technology/internet/internet-privacy-and-safety/articles/bypass-geo- blocking)). So there is definitely a market for this type of service.

</comment></comment></comment></comment></comment><comment><USER7> By and large, people are interested in VPNs because they're vulnerable, in some way or another. By becoming a VPN provider, you become a "pinch point" for the connections of a number of vulnerable people.

That way, a hypothetical bad actor only needs to compromise one entity (you) in order to gain access those people who rely on you.

Aggregating vulnerability makes you a target, and puts your customers at risk - Especially when you're relying on third-party virtualisation providers for your infrastructure.

<comment><USER8> I would add, the potential to become a legal target. That is, receiving, fending off and complying with subpoenas and court orders.

<comment><USER7> Aye. I care slightly less about this from my perceived threat model (if you go into the business then you know what's coming to you, whereas your end users are a lot less likely to understand the risks) but it's still worth thinking about.

</comment></comment></comment><comment><USER9> We offer VPN as a side thing to help our customers who are testing their websites from around the world. At the behest of some friends I added VPN as its own plan.

A choice you need to make really early on when you're offering a VPN is how much data you want to log. Eventually someone will do something on your service that pisses someone else off. That could be torrenting, spam, defrauding the elderly, etc. Ideally you, but more than likely your provider will receive an angry letter. Whether or not you've logged will choose what you can do next. If you're not logging, and unable to stop complaints from coming in your provider might turn you off completely, so you'll want to pick a provider known to pass letters on without caring.

I blogged about our choice (we log) here: [https://wonderproxy.com/blog/our- vpn-what-we-log-and-why/](https://wonderproxy.com/blog/our-vpn-what-we-log- and-why/)

</comment><comment><USER10> The successful companies appear to be run at least partially anonymously and based in tax havens. I figure that is because there is legal responsibility that they are trying to dodge.

People use vpn for illegal stuff, and the least worst is Netflix then p2p. P2p if you are a facilitator could land you in jail.

<comment><USER11> This. Had a lengthy discussion with a friend who has a friend where one works.

My theory was - why bot setup virtual VPN provider that all such companies could buy. After all it's simple and rea grunt of work is marketing and legal.

Legally, these companies are setup somewhere in Caymans et al.

Being such a shady business by definition, I have extremely hard time trusting such services. It's like the most obvious honeypot / trojan horse ever.

</comment></comment><comment><USER12> I'd be most worried about the legal liability, what happens if someone starts using your service to download or sell pirated movies or child porn? Whats your legal exposure?

<comment><AUTHOR> Yeah this is my issue. I'm not too worried about it being a successful business (more like a small side project), but I don't have the resources to fight any legal claims.

<comment><USER13> \- Do not run it in the US.

\- Do not sell the service in the country you run it.

\- Really, do not run it in the US.

<comment><AUTHOR> What are good, non-US cloud providers? I only know of AWS/DO/Azure/Google - what are the go-to providers outside the states?

<comment><USER14> Hetzner or OVH in Europe.

</comment></comment></comment></comment></comment><comment><USER15> The most difficult part about VPN as a business is dealing with the people that use the VPN for illegal activity.

The authorities will come after you first. Most large providers are located in some small country like Panama so they can't be sued or jailed.

</comment><comment><USER16> From a technical perspective, you're probably not breaking new ground here. The main things you'll need are ease-of-use and good marketing. There are existing companies that do this and make it fairly easy to get up and running, so you'll need to do the same. Perhaps start with a niche (e.g. easy setup on Ubuntu) and build from there. Still, your biggest hurdle is going to be that no one has heard of you, so make sure that you have a well designed landing page and think about who you'll market the product to.

<comment><USER11> One service I'd be willing to pay is intercontinental booster.

Living in NZ means you've got quite underprovisioned international pipe. 100mbps fibre realistically means 3mbps...

If a VPN could route you via their dedicated pipe...

<comment><USER17> You probably just need to find a vpn provider that provides vpn server located in NZ (should be plenty if you google it). By connecting to their NZ vpn server, you'll effectively used their international connection when accessing international sites instead of your isp's international pipe.

</comment></comment></comment><comment><USER18> I ran a venture backed VPN company for many years (Spotflux). These days there are tons of huge players in the market, some of which have hundreds of millions of dollars in funding. Your challenges will be as many have stated the following:

1) Convincing providers to let you have VPN traffic on their networks. 2) Dealing with tons of DMCA complaints 3) Dealing with GDPR compliance in the EU 4) Maintaining compatibility for dozens of different user configurations and having apps in the mobile app stores 5) Dealing with credit card and payment fraud. 6) Dealing with law enforcement once you reach a certain scale (no, incorporating in whatever random island will not help you) 7) Maintaining constant uptime of your servers. When a user faces even a minute of downtime, their internet connection is now effectively broken and you are to blame. 8) Dealing with lots and lots of customer support issues and an endless mix of customer configurations which will have you ripping out your hair trying to resolve. 9) Constantly make sure your systems are secured from the latest exploits so you can guarantee privacy and safety of your users. 10) Maintaining a brand and a niche with mature marketing channels that keeps new users coming and paying for your service.

At the end of the day, its a very difficult company to run and its even harder to maintain profitability with so much competition.

</comment><comment><USER19> One possible option is to sell VPN service to friends/family/acquaintances, for a price that is (clearly to them) cheaper than comparable commercial VPNs, in exchange for a promise to not do anything that would get you in legal trouble. You can trust the promise more than you could trust standard terms- of-service because you know them, and hopefully the lower price means they see it as you offering them something as a convenience from your side project instead of a "real" business and the problems of doing business with friends don't apply as much.

<comment><USER20> Just tell customers everything is logged and the logs are deleted on a rolling basis every year.

<comment><USER21> And the logs are stored encrypted offline. They move over a one-way link from main server somewhere else in case of a compromise. They're never shared except with law enforcement with a warrant per privacy policy and EULA.

Inspires more confidence if they're kept temporarily _but heavily protected_.

</comment></comment></comment><comment><USER22> I've also toyed with the idea of doing something like this, and would like to know more about this as well. Like you said, the technical side seems easy. I imagine handling legal issues is going to be the bulk of the work. How are you going to handle abuse reports? How are you going to handle requests from authorities asking to turn over user data? And most importantly: how much information about your users are you going to collect to make handling the legal issues easier?

<comment><USER23> > how much information about your users are you going to collect

Not collecting any data would be the obvious choice.

<comment><USER24> Which isn't legal in many parts of the world, especially if you take any kind of payment for your services.

<comment><USER25> If you don't collect data you can't give it to the authorities.

<comment><USER26> But you can still be asked for it, and you can still be required to appear in court over it

</comment></comment></comment></comment></comment><comment><USER27> You're going into a heavily saturated market. Not to mention anyone technically savvy can set up their own VPN in 10 minutes on a cheap DO host or other provider.

<comment><USER28> I'd consider myself tech savvy and I happily pay for a VPN (PIA). I don't want to manage a node, and at $40/year it's about equal to what I'd pay otherwise.

<comment><USER29> I guess it takes an average HN reader 1 hour to setup a VPN. If the purpose is have a secured gateway for using public wifi, it serves the purpose. However, if you want to gain anonymity, it does not work since the node has a unique IP and only you are using this IP. You still need different users to use this VPN to gain anonymity.

Therefore, we could only choose one of the following: security or anonymity, but not both, unless you becomes your own VPN provider and serves some customers for anonymity.

An alternative is Tor, but a compromised exit node still leaks HTTP site.

So, if someone could solve this problem, it would be a big selling point. I am not sure if it is possible to share an IP between different VPN nodes without an untrusted gateway in front.

<comment><USER30> In my country, VPNs sometimes get blocked. Along with half of the AWS and other random stuff.

So I've set up _my_ VPN and _also_ pay for another third-party VPN service, having best (or worst) of both worlds.

My gateway host is private, and I've decided that if it gets detected, I'll add an obfs4 layer on top of it. (Luckily, that hadn't happened - and I'm moving to another country in about a week. But that's a different story.)

All my first VPN does, is merely routing the traffic to an upstream VPN provider. This way I get a private entry point but also enjoy some degree of anonymity as my "final" IP addresses are shared with lots of other users. (Well, I share my gateway VPN with a few close friends. Maybe that's borderline cheating on the upstream VPN, but I don't see a way to pay them for my network-sharing guests anyway.)

Oh, and I don't need to reconnect to switch regions. I just made myself a tiny web service that changes the routing table used by my TAP connection, so whenever something doesn't work from one region I just need to click on a flag icon.

<comment><USER31> > In my country, VPNs sometimes get blocked.

This is why I love* Tunnelbear's[0] GhostBear feature and it uses obfsproxy[1]. Very few VPN providers provide censorship circumvention like that

[0] [https://www.tunnelbear.com/](https://www.tunnelbear.com/)

[1] [https://community.openvpn.net/openvpn/wiki/TrafficObfuscatio...](https://community.openvpn.net/openvpn/wiki/TrafficObfuscation)

[*] No affiliation with Tunnelbear, just thought I would point out this feature

</comment></comment></comment></comment></comment><comment><USER32> A great niche to get into would be Internet censorship avoidance in countries where Internet freedom isn't a thing. As an expat living in China, I can tell you that there are only a few companies that do this successfully (among them Astrill and ExpressVPN).

Operating this kind of VPN comes with its own set of unique technical challenges, such as avoiding DNS poisoning and offering the best protocols to use. Spinning up a homebrew solution on DO just doesn't cut it as an end user, so we rely on companies like these to provide targeted solutions.

A VPN provider that can focus on avoiding common blocking techniques would be very valuable to a lot of people.

</comment><comment><USER33> Be focused on a specific audience, because talking to consumers about security is very hard. First, I'd start with your friends.

The first questions they're going to ask is how can I trust you're not spying what I do. If you can convince your friends, then you can convince anybody.

Next is how do I use it / how does it work, that brings to make it as simple as possible. Minimal setup, no configuration, it just works.

Finally it's why should I use it. This can be "easy" because you can just look around the competition, see their messaging, find out which one you like better and copy it. Focus on benefits vs technical features and details. When consumers see something they don't understand, they leave.

I've never built a vpn, but I made a password manager (question 3 is relatively easy/understood), and now I'm making a security key (all these questions are proving to be pretty hard). Shameless plug, we're live on Kickstarter: [https://solokeys.com/kickstarter](https://solokeys.com/kickstarter)

</comment><comment><USER34> Your best bet, from an ideological perspective, is NOT a cloud hosting provider or a dedicated host, but buy rack space, and put your own servers in.

Control access to the machine/s.

This is more expensive, and not foolproof. But other hosting providers have so much access to track or log things, even if you don't want them to.

</comment><comment><USER28> Anecdote: You can do this really cheap on the billing side and use WHMCS for billing/member management. Better than rolling your own, and it's pretty extensible.

</comment><comment><USER35> VPN has a vast potential market in China, which has blocked most providers. I've used ExpressVPN for two years, and its connection is not always stable. I've also used the Lantern proxy with a premium account for a year. Somehow it didn't work most of the time. Maybe you can use more advanced technology and networking infrastructure to provide better service to such areas.

</comment><comment> vertex-four Surely from an ideological perspective, running a Tor relay node or two would provide about the same amount of fuzzies at much less risk?

</comment><comment><USER36> most of the job will be technical support and finding the right server providers. marketing will be the limiting factor. it's pretty quiet legally, usually it doesn't go further than DMCA cease & desists, but you need to mind countries and what logs each requires you to store. see packetimpact.net maybe i can help you

<comment><USER37> How does this work in practice though? I had a DigitalOcean droplet setup with OpenVPN and they contacted me pretty quickly (within a week) with a bunch of DMCA notices (due to torrenting). I can imagine that this would be quite a frequent occurrence as a VPN operator and not necessarily something I would like to be dealing with.

</comment></comment><comment><USER38> The problem is that just like you're able to quickly run up a VPN on a cloud provider, I can do the same. There are plenty of drop in containers for this now and the barrier for entry is low. I think you're just opening yourself up for a world of legal pain and costs given what most people will use VPN services for.

<comment><USER39> Your saying that if you use a VPN you are up to something nefarious?

<comment><USER40> No, that's not what cube00 said. The HN guidelines ask you to assume good faith and eschew flamebait, please do so.

</comment></comment></comment><comment><USER41> Apart from above suggestions, try provide wireguard support, if possible a shadowsock proxy as well.

</comment><comment><USER42> I've had a similar idea. I am thinking of creating a service that would install OpenVPN for you on your own server, and send you an email with all the configuration details. Would that be useful, worthwhile doing?

</comment><comment><USER43> You get consistent revenue from the NSA.

</comment><comment><USER44> Try it and report back, I'm curious

</comment><comment><USER45> how.. make fast money?

</comment><comment><USER46> One of my "favorite" evil business models is Hola VPN ([https://hola.org](https://hola.org)), a free browser VPN extension. Hola VPN users unknowingly become exit nodes for residential IP address proxies for sale at [https://luminati.io](https://luminati.io).

<comment><USER47> Thank you for mentioning it. Just removed it. Do you know of any good, non- expensive (VPN?) alternatives? I was using it to access Netflix in other languages for language learning purposes.

<comment><USER48> ProtonVPN has a free plan, I recommend it quite strongly. Netflix works on the server I use, though I'm not sure if it works for all servers. P2P traffic is not allowed on free servers.

Support is okay, not the fastest. Downtime is rare but not unheard of, they've been targeted with big DDoS attacks. Server options expanding but not in tons of countries. Most trustworthy and reputable service because it has a CEO you can actually put a name and a face to, and the history of Protonmail.

<comment><USER49> This is ironic given the connection between ProtonVPN and Hola/Luminati.

<comment><USER48> What are you referring to? The situation I found bits and pieces about didn't seem to amount to much of anthing. ProtonVPN was able to explain what happened to what I thought was a satisfactory degree [1].

I definitely don't trust NordVPN in particular, they advertise their "military grade encryption", and I have no clue who runs it.

[1] [https://www.reddit.com/r/ProtonVPN/comments/8ww4h2/protonvpn...](https://www.reddit.com/r/ProtonVPN/comments/8ww4h2/protonvpn_and_tesonet/e21tfqw/)

What other VPN would you trust? Mullvad, absolutely no clue who runs it. Private Internet Access had claims about logs proven in federal court at some point in the past, but I really still don't trust it.

Running your own VPN is one of the best options but you almost completely lose the relatively reasonable degree of anonymity that VPN providers serve to you. Depends on your objectives.

<comment><USER50> > ProtonVPN was able to explain what happened to what I thought was a > satisfactory degree

ProtonVPN's explanation was extremely hardly believable[1].

> Mullvad, absolutely no clue who runs it.

It's clearly stated on Mullvad's homepage[2]:

> The legal entity operating Mullvad is Amagicom AB. [...] Amagicom is 100% > owned by founders Fredrik Strömberg and Daniel Berntsson who are actively > involved in the company. The rest of the team includes Robin Lövgren, Simon > Andersson, Linus, Richard Mitra, Sanny Mitra, David Marby, Odd, Andrej > Mihajlov, Janito Ferreira Filho, Elad Yarom and Jan Jonsson.

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

[2] [https://mullvad.net/en/](https://mullvad.net/en/)

<comment><USER48> I thought the Reddit reply was thorough, though I can't speak to the claim by krn.

At the end of the day, I can't name many (if any) VPN providers that operate their own data center, which is extremely important since they all (including ProtonVPN) lease from the same companies. ProtonVPN does provide Secure Core though (routing traffic through certain countries to attempt to mitigate exit node threats), too.

I wasn't aware about Mullvad, thank you for pointing that out. I still have little clue who those people are, while Andy Yen has given a TED talk, so he has some public presence. I'm personally more inclined to trust them.

<comment><USER51> Actually, ProtonVPN does own the physical hardware and network for our secure core servers, which we fully operate and run ourselves. This is rather expensive to do, but it's the only way to be sure things are behaving as they should.</comment></comment></comment></comment></comment></comment></comment></comment>


Ask HN: Why Python over Ruby? - <AUTHOR> I would like to understand why Python is so much more popular than Ruby. Much of the software I've seen supports Python for scripting (e.g. Miro, OpenMoko, XBMC/Boxee), and people don't seem to care so much for Ruby. At the same time, people agree that Ruby is great for writing DSLs.<p>I don't want a flame war or religious arguments. I would like to understand what made Python win in this space. Thanks so much for commenting! <comment><USER3> Ruby has clever syntax. Python has pure syntax.

Ruby has method aliases. Python does not allow a string to capitalize itself.

Ruby uses Ruby methods within Ruby classes to extend Ruby. Python has decorators so you can write functions that return functions that return functions to create a new function.

Ruby has strict object-oriented encapsulation. Python is laid-back about objects, because you probably know what's going on inside them anyway.

Ruby lets you leave off parentheses so you don't miss objects having attributes too much. Python will let you mix tabs and spaces for indentation, but passive-aggressively mess up your scoping as punishment.

Ruby has seven kinds of closures. Python has one, in the unlikely case a list comprehension won't do.

Ruby's C implementation is a mess of support for language-level flexibility. Python's C implementation is so clean you get the unsettling thought that you could probably write Python using C macros.

Ruby supports metaprogramming for cases when programmers find it more descriptive. Python supports metaprogramming for cases when programmers find it necessary.

Ruby is expressive. Python is direct.

Ruby is English. Python is Esperanto.

Ruby is verse. Python is prose.

Ruby is beautiful. Python is useful.

I like Python, but coming to it after using Ruby for seven years, well, I think it's like dog people and cat people. You can like having one species around, but you're always thinking -- why they can't be more like the other?

<comment><USER4> _Ruby has method aliases. Python does not allow a string to capitalize itself._

        >>> "hello".capitalize()
        "Hello"

_Python has decorators so you can write functions that return functions that return functions to create a new function._

Or functions that return classes, or classes that use other objects, or any possible other use for the pattern "wrap this with that and save the result"

 _Python will let you mix tabs and spaces for indentation, but passive- aggressively mess up your scoping as punishment._

        $ ./mixed.py
          File "mixed.py", line 3
            print "b"
                    ^
        TabError: inconsistent use of tabs and spaces in indentation

<comment><USER3> I should point out that capitalize(), of course, returns a new capitalized string, just as it does in Ruby. But in Ruby you also have String#capitalize!

And as for indentation, I think Guido should have followed through with making tabs a syntax error, because they are part of the syntax and are fiendish sources of error. Let's just say you have this code, properly indented with spaces:

        class X:
            def visible(self):
                pass

And you open it in a non-Python-aware editor, say for Windows, which has a four-space tab length and does not convert them to spaces. You add:

            def invisible(self):
                pass

at the end of the file using your tab key. Now you have a potentially crazy- hard-to-figure-out bug.

<comment><USER4> _I should point out that capitalize(), of course, returns a new capitalized string, just as it does in Ruby. But in Ruby you also have String#capitalize!_

So the quote deals with mutability? I suppose that makes more sense, since Ruby tends to favor mutable objects. Of course, to my Python-based mind changing the definition of 'a' or 3 seems like a poor idea.

 _And as for indentation, I think Guido should have followed through with making tabs a syntax error_

Surely you mean "making spaces a syntax error"? That would be much more sensible, since using spaces for indentation is absurd. Even better would be simply ignoring spaces, since that allows them to be used for pretty-printing and alignment without any potential ambiguity.

Also, the bug in your example will not be difficult to figure out, because Python will/should raise an exception when parsing the malformed file. Not everybody runs with -tt, but that ought to be the default behavior (and is anywhere I get to control the installation).

<comment><USER5> > Even better would be simply ignoring spaces

Oh god no. Then you could have blocks that line up visually but execute in different scopes

</comment></comment></comment></comment></comment><comment><USER6> Ruby is slightly newer and wasn't particularly popular in the United States until it was popularized by Rails.

Python became popular with Linux and open source developers before Ruby did, and has had slightly more time to develop a nice set of libraries to do just about anything.

<comment><USER7> May I also add that Python works very nicely on a Windows box. Ruby/Rails works on Windows, but when I used it, it hobbled around on one leg. Going to PyCon this past year, I was stunned at how many Windows laptops there were. Python itself and the Python community are really quite OS agnostic.

The online Python documentation tends to be pretty good. When I picked up Ruby a year and a half ago, and I tried to find the documentation, people generally pointed to the pickaxe book as the de facto documentation.

<comment><USER8> Yes, the pickaxe book or the class docs at ruby-doc.org

Although I've been using Ruby on windows the last few weeks with Ruby Shoes from _why(normally use for unix scripts or web-dev). It's pretty nice (although a little rough around the edges as it's under heavy developement).

When you install shoes (the latest version anyway) you get the GUI tools, ruby gems, and sqlite, and a ruby interpreter, all neatly packaged. And there is a whole load of items I havent looked at yet. It's fun.

</comment></comment></comment><comment><USER9> What's clear to me reading the comments in this thread, is that there are a lot of people who like Python, and don't understand what people appreciate in Ruby.

None of these are reasons why people choose Python over Ruby. Or why Python has become more popular. It is worth noting that Python was also mentioned a lot as a teaching tool when its popularity began ramping up, and some universities have replaced Java and Scheme with Python as an introductory language.

Python really is not appreciably better than Ruby, in my experience. Nor will i claim that Ruby is appreciably better than Python. I personally use Ruby in daily life, and used to use Python prior to discovering Ruby. Both languages support some really weird warts, inconsistencies, and baggage that they retain for the sake of backwards compatibility.

Instead they really do provide different philosophies on life. To claim that Ruby is a tangled soup of options and syntactic sugar is to miss the point really. Nor is Ruby is not trying to be all things to all people. Matz cares about one thing, and that's the ability to let programmers get work done with as few cognitive hurdles sourced from the programming language itself. Does that mean you have options? Yes. Does that mean that it would be better to only have one way to do everything? Not necessarily.

<comment><USER10> _To claim that Ruby is a tangled soup of options and syntactic sugar is to miss the point really._

What _is_ the point? I sincerely wish to learn, for my own intellectual curiosity. Because I have read Ruby code and I have done Ruby tutorials and talked to people who use Ruby and for the life of me, no matter how hard I meditate on the issue, I cannot understand why anyone would use Ruby over Python.

I don't feel Python is absolutely better than Ruby, anymore than an apple can be absolutely better than an orange, but I have yet to gain a comprehension of how Ruby is even _relatively_ better. From a Python -> Ruby perspective I find it particularly perplexing.

Ruby presented far more cognitive hurdles for me because it allows you to do things in ways that seem simultaneously mildly more convenient and completely counter-intuitive to everything I've experienced with similar styles of languages over the past 10 years.

<comment><USER11> I currently use Python and Django for the following reasons: 1) Coworker familiar with Python 2) I had an easier time understanding the mechanics of Django than I did Rails 3) Some libraries I needed were only in Python

However, from a language point of view, I have a slight preference towards Ruby. Here are some things I like: 1) More consistent commitment to object paradigm, e.g. all function calls are actually method calls on an object. In Python, everything is an object, but sometimes you use methods, and sometimes you don't, e.g. list.pop() vs. len(list). 2) I think blocks are very handy. 3) I like the more Perlish regex syntax. 4) There is a cleverness to Ruby that might not be the best thing for a corporate environment, but it makes it fun.

So, if I was writing code just for myself, I might choose Ruby over Python, assuming performance and library support were sufficient.

<comment><USER12> Humor me for a moment, because I've been asking this question of many people for a long time and have never yet gotten a straight answer.

Why is len() always the thing people pick on? Why is it always "Python uses len(obj) instead of obj.len()", and never "Python uses str(obj) instead of obj.str()", or any of the various polymorphic built-ins like sum()? I've seen this so many times now that I'm honestly quite curious about it.

Also:

"More consistent commitment to object paradigm, e.g. all function calls are actually method calls on an object."

Every function call in Python is always an invocation of a method on an object, even if it doesn't look like it. len(), of course, delegates to a method on the object. But even standalone functions are method calls. Try this:

>>> def add(x, y):

... return x + y

...

>>> add(3, 5)

8

>>> import types

>>> types.FunctionType.__call__(add, 3, 5)

8

The last couple lines there are what's really going on when you call the function.

(also, just as Ruby's "built-in" functions are really methods on Kernel which is made available globally, Python's "built-in" functions really exist in a module that's made available globally (and __builtins__ is its name)

<comment><USER13> Even without going to the trouble of importing types, every Python callable has an __call__ method. Including the __call__ method:

        >>> def f():
        ...  print("Helllo __call__")
        ...
        >>> f.__call__.__call__.__call__.__call__()
        Helllo __call__

Don't use this in real life though, there's a performance penalty.

<comment><USER12> Of course, there's also the singleton that always returns itself:

      >>> recursive = lambda: recursive

</comment></comment></comment></comment></comment></comment><comment><USER10> Python is far more mature, isn't a strange ad-hoc combination of other languages, has a third-party library to do anything and everything (which is probably also reasonably mature), and doesn't have a community rife with arrogant children.

I'm generalizing to some extent, of course, but these are the things that I and other developers I know associate with Ruby (including many who's startups are built on it). I imagine as the language and community grow and mature they will shed these associations and hopefully create a language worth taking seriously. They haven't done that yet (strictly in my opinion).

<comment><USER14> _... a community rife with arrogant children_

It's difficult to accept your rational argument when you include stuff like this.

<comment><USER10> Why is that? It can easily be proven. I'm not trying to suggest that _everyone_ who uses Ruby is an arrogant child as I even have friends who certainly don't fit that bill, but when you have an especially abrasive attitude like that within a community, it only takes a minority to sour the majority.

And while it certainly isn't a fault of the _language_ , it definitely influences it usage for some people.

<comment><USER15> Umm....and have you _ever_ spent anytime time in #python? Some are helpful, but there are a choice few who I would describe as arrogant children.

In any community of size, you get good seeds and bad seeds. Python is not immune to this.

<comment><USER16> Actually, for a while I was spending quite a bit of time in #python. I didn't come across "arrogant children".

Looking at some of the drama and prima donna action in the Rails community (from a distance) just made me sad and grateful that my corner of Python (scientific computing) doesn't have those sorts of issues.

</comment></comment></comment></comment></comment><comment><USER17> For me it's very simple !

I can READ other people's Python code with greater ease than Ruby, Java, C#, C++ or even C. At the end of the day, the quicker I can assimilate library code the quicker I can use it well and the quicker the module gets completed and fully tested. Of course, with Google and Eric Raymond raving about it, the confidence factor increased further.

<comment><USER18> This is a cultural issue. In the Ruby (or Perl) community, if you use obscure language features to do a common task in a single line of code, you will be worshipped as a god. In the Python (or Tcl) community, you will be viewed with suspicion. Not that Python doesn't have one-liners (e.g. comprehensions) - just that everyone agrees which ones and when and how to use them.

<comment><USER9> I've been working in Ruby for 3 years now, and i can promise you that unclear code is very much not appreciated by not only the people i work with, but all of the open source projects i'm involved with.

It is true that Ruby gives you a lot of rope. People with good design sense appreciate that your code should not be too clever.

<comment><USER19> Agreed. The ultimate goal is clarity. Everything else is subservient to it.

</comment></comment></comment></comment><comment><USER20> Why language X is better of Y makes no sense. Every language has its benefits and downsides. Python has been slighly longer around and has a bigger user community which resulted in more available library code. Ruby and Python is pretty much interchangable in the sense of features as they often steal from each other and vice versa.

Ruby

\- follows TIMTOWTDI

\- Mutable strings etc.

\- has a greater emphasis on code generation ("meta")

\- VM's are much slower than Python (there is no Psycho etc.)

\- emphasizes code clearity and readabiliy (human cycles are more important)

\- Libraries are much less mature

\- ...

The lists of differences could go on forever. A comparsion and "why" is difficult. I think they are too similar and the people are too polarized.

A language is a tool to solve a particular problem. In the case of Python you have higher momentum of the community and the switch from C/C++/Java to Python is often easier than to Ruby. (Wild statement of me with tests from a sample set of 2 test subjects ;) )

Probably the best characterization I can come up with is. Python is already on this "Enterprise" trip where companies use it a lot and so forth. Ruby has some interesting companies pushing it (Twitter etc.) but is not compeletely there yet, it still has more "hacker" and "monkeypatch" feeling. Oh wait, we call that "ninjapatching" in Ruby ;)

<comment><USER9> Speed comparisons between Ruby and Python are kind of silly. Ruby 1.9 and JRuby are (if you look at [http://shootout.alioth.debian.org/u32/benchmark.php?test=all...](http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=python&box=1) ) comparably fast to Python, and obviously measure up slightly better against Python3.

Python is not a radically better choice in terms of speed (and hell that's true even w/ 1.8. Sure Python's faster, but we're not talking orders of magnitude here).

</comment></comment><comment><USER21> I prefer the design of Python over Ruby. I'd be hard pressed to explain why -- something vague about Python being straightforward yet graceful -- but that aesthetic preference is enough to sway me.

<comment><USER22> Me too, but I don't think it's _just_ a preference. I come from a C/C++ background (I'd say the majority of people do, or C# or Java), and Python looks much more familiar and obvious to me than Ruby.

For example, this from Wikipedia:

      (3..6).each {|num| puts num }

Has some funny brackets and pipes. In Python, it's much more familiar to C-ish folks like me:

      for i in range(3, 7):
          print i

<comment> nor-and-or-not Ruby's syntax is flexible:

      for i in 3..6 do
        puts i
      end

<comment><USER23> Very flexible. Once you learn what the sytnax means the implementation of blocks and iterators is one of the best parts of the language.

        3.upto(6){ |x| puts x }

I don't think the uniqueness of a language is any reason not to learn it. To be honest that sounds lazy.

PS I'm not a Ruby zealot, and Python is a great language

<comment><USER24> So I just saw 3 ways to print from 3 to 6... are those all used in the wild?

Zen of Python: "There should be one-- and preferably only one --obvious way to do it."

Sure, there are other ways to do it in Python, but it'd be frowned upon to use something like 3.upto(6) rather than a standard range() that everyone is used to. Readability matters.

<comment><USER25> I'd argue 3.upto(6) is much more readable and obvious than range(3, 7). Even just on a conceptual level, Python requires a degree of translation and its stop argument is not intuitive whereas even someone who has never programmed before can understand the Ruby.

<comment><USER26> [http://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831....](http://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831.html)

</comment></comment></comment></comment></comment></comment></comment><comment><USER27> Speaking purely for myself, the only reason I switched from Perl to Python is I had a great deal of difficulty understanding the perl code (because I'm a poor perl scripter) I wrote after a day or so. That, and the language construct HashOfArrays and ArrayOfHashes is exceedingly difficult to do in perl without referencing a manual. The only (Edit: Alternative scripting) language really out there with mindshare in 2001 was Python. I was able to read my python code. I never had to look at a manual to implement complex data structures. As a bonus, I can type "help(command) or dir(command) within the python CLI. I've never really had the need to switch to another environment. Ruby might actually be 10x better and faster for my typical tasks than python for all I know.

</comment><comment><USER28> From the Python website:

"Python has been an important part of Google since the beginning, and remains so as the system grows and evolves. Today dozens of Google engineers use Python, and we're looking for more people with skills in this language."

When I first saw this, I went "Google? Whoa. I gotta check this out" :)

<comment><USER29> It is impressive, but beware of cargo culting.

<http://en.wikipedia.org/wiki/Cargo_cult_programming> <http://weblog.jamisbuck.org/2008/1/7/never-ever-cargo-cult>

</comment></comment><comment><USER30> I haven't really looked at Ruby that hard, but from my perspective as a reformed Perl user I found Python's syntax to be very clean and well organized. On the surface ruby looks more Perl-like to me, more clutter, not as easy to read as Python.

Having found Python, I really don't feel a pressing need to learn another scripting language. Instead I'm working on Objective C.

<comment><USER28> Although I'm a Python programmer, I urge you to take at least a cursory look at Ruby. It's actually very different from Perl.

Ruby borrows some stuff from Smalltalk. You know what other language borrows heavily from Smalltalk? Objective-C :)

<comment><USER31> Part of what makes the difference is cultural. It is of course possible to write very legible Perl code, but that was, at least for a time, far less visible than the "cool hack in 1 line of extremely dense code" culture, and all the "more than one way to do it!" stuff. Ruby can be messy, but there is a tendency to keep a lid on it.

</comment></comment></comment><comment><USER32> Python is older, and gained popularity before ruby. That's why it's more established outside of the web development frameworks space.

<comment><USER33> How does python compare to ruby in terms of web development?

I get the impression that there are more 3rd-party libraries in Ruby, so it is easier to get web code up and running with ruby.

<comment><USER25> I think this impression comes from the culture of experimentation in Ruby and more widespread willingness to adopt new tools and libs very quickly. Python definitely has a diverse web development community and more options in some areas (like templates), but it's more conservative, not necessarily evolving as rapidly and, like Python overall, resists influence from other languages.

For instance, Haml and Saas are pretty widely accepted by Ruby web developers, whereas Django templates are very popular with Python web developers precisely because because they are close to straight HTML. Ruby developers (like Ruby itself) readily adopt good ideas from other languages, including Python (rack from wsgi, rip from pip, merb slices and rails engines from django apps), while anything that resembles anything from ruby or rails, like some Pylons components, gets criticized by many python developers. It's noticeable with version control, too, as svn is still very widely used by Python developers whereas Ruby and Ruby/Py developers moved completely to git and hg over a year ago.

<comment><USER16> FWIW, there are lots of Python folks moving to git and hg as well. But I don't understand what VCS choice has to do with language culture. What's next, a critique of editor choice? :)

Python is such a large tent that it's quite inaccurate to say that "the Python culture" lacks a sense of experimentation and adoption of new tools. What you might be getting at is the fact that there are already so many _existing_ libraries in Python for doing most things that there's not a lot of public reinvention of wheels going on.

<comment><USER25> _"FWIW, there are lots of Python folks moving to git and hg as well"_

It's not _remotely_ as universal as it was for Ruby developers. When working with Python you still can't go a day without hitting an svn repo, but with Ruby you'd easily not touch one for months.

 _"But I don't understand what VCS choice has to do with language culture."_

A lot, and I already described it. Ruby developers and the Ruby language overall are less conservative and more open to dramatic change than Python developers or the language. Each model has its benefits.

 _"'Python is such a large tent that it's quite inaccurate to say that "the Python culture'"_

It's a large tent, but the common thread is Python and Python's principles, and they define the culture.

 _"there are already so many existing libraries in Python for doing most things"_

But individual developers don't do most things, each works on certain things. Python has lots of libraries, but that doesn't mean it's the best choice for any specific job. As a web developer, there are a huge number of Python packages that don't matter at all in that domain. If sheer number of libraries mattered, we'd all be using perl.

</comment></comment></comment></comment></comment><comment><USER34> Personally I like generators, generator expressions and list comprehensions much more than the Ruby equivalents (chaining each/filter/etc). Python is cleaner overall, and if you want metaprogramming you can still do a lot of it. Also Python has better libraries and runs on App Engine.

<comment><USER35> I'm too big fan of iterators, they're great!

Although it's worth noting that Ruby too, runs on GAE using JVM based implementation (JRuby).

</comment></comment><comment><USER31> Python got popular earlier - it was already gaining significant converts in the early part of this millennium, and the later years of the last one. Ruby only really took off when Rails started to get popular. But it has _really_ taken off, in a way that I think sometimes makes the Python guys (who have been slowly and steadily gaining ground) a bit jealous.

They're both good languages with good communities though. Each has a few advantages and disadvantages, but they're similar enough that if you know one you should probably stick with it and be happy, and pick something farther from the tree as your next language (Erlang or Scala, say).

<comment><USER36> "But it has really taken off, in a way that I think sometimes makes the Python guys (who have been slowly and steadily gaining ground) a bit jealous."

Reality seems a bit different to me:

[http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

[http://bitworking.org/news/413/ruby-books-sales-a- retrospect...](http://bitworking.org/news/413/ruby-books-sales-a- retrospective)

</comment></comment><comment><USER37> I believe it is more of a personal choice than anything else. That said, here are the reasons I like Python more than Ruby.

* Namespaces - Ruby has namespaces but when you are reading some code it is very hard to figure out what got mixed into what. This may be more predominant in the Rails world than others. You can exactly know where each one of the classes and methods came from unless you are doing a 'from x import _'

_ Clean code - I know that with most editors today, you can have clean code. But python's insistence on indentation makes the code appear clean and very readable. This was an excellent design decision.

* Method and class invocations need () - This view is very subjective. While ruby's method invocation style gives rise to a lot of DSLs, python's style of invocation means that there are no silly Proc objects. If you need to pass a function to another function just send its name. I am not saying that one way is better than the other but I like python's explicitness here.

* OpenStruct by default - This is one of the best design decisions ever. Python uses a very fast implementation of dict for its objects. That means you almost get a javascript kind of object without the clunkiness of javascript.

I am biased a little bit towards python as I learnt python first. I do love Ruby's DSLs but I have a heart for Clojure too, in this regard. And I am actually quite happy that Jython 2.5 has come out. I am a little disappointed that Jim jumped over to the IronPython and left Jython hanging. But thanks to him, Python is there on all the major platforms.

</comment><comment><USER38> For me personally, it boils down to me liking the library more, the syntax more and the common programming styles. Ruby is very hard to follow me due to the (imho) overuse of meta-programming and using language constructs that obscure the actual meaning of the program. Patching objects and being overly clever with language features makes ruby code harder to read.

It's also, to me personally, a lot faster to whip something up in Python than in Ruby, even when I knew them at about the same level.

<comment><USER32> I find ruby more intuitive. I learned python first but switched over (not due to rails, just enjoyed ruby more). It sounds like you are complaining about the meta programming in the Rails code more than any intrinsic feature of ruby the language.

</comment></comment><comment><USER39> I wish Ruby were good, but it's so fucked:

      Matz's decision-making process
        He tries to make Ruby be all things to all people
          Lots of confusing sugar and overloading baked in
        I much prefer Guido's hard pragmatism

      The pointless panoply of function types: Methods, Blocks, Procs, Lambdas
        All intertwined and yielding into one another.
        I love that in Python there is only one:
          Objects with a __call__ method, defined metacircularly.

      The culture of adding/overloading methods on base classes
        Many gems do this en masse, and there are a lot of low-quality gems
          Seriously, Ruby might have a ton of new gems for everything, but they
          are almost universally awful. A culture of sharing any code that *could*
          be a module, no matter how trivial, leads to immature crap being widely
          used because it was there already, with a mess of forks to clean up
          afterwards. At least most of them are test-infected...
            Python does come with a few stinkers, mostly ancient syscall wrappers.
        Especially disastrous because it's unscoped, and infects the whole process
          For a language with four scoping sigils it sure fucks up scope a lot
        The syntax practically begs you to do it, anything else would look shitty

      The Matz Ruby Implementation
        The opposite of turtles-all-the-way-down (Smalltalk crushed beneath Perl)
        It actively punishes you for taking advantage of Ruby's strengths
        The standard library is written almost entirely in C
          It doesn't use Ruby message dispatch to call other C code.
          That means that if you overload a built-in, other built-ins won't use it
        Anything fiddly that's not written in C will be dog slow

<comment><USER17> Great comment ! Reminds me of Lisp, a very simple concept that is powerful and easy to implement and then CommonLisp comes along trying to include everybody's favourite feature. As a result many people get put off without digging for the gold.

</comment></comment><comment><USER40> I like Ruby (culturally) more than Python.

Python has NumPy/SciPy/and friends, so I use Python.

This, I feel, is a strong point for most who are using a scripting language to do scientific work.

<comment><USER41> How do you find Numpy/Scipy on Python compared to statistical languages like R?

Also what kind of work are you doing?

<comment><USER42> I don't know about tel, but I use both pretty frequently (and usually together with rpy). R is great for some things, but I typically find that I need to use a general purpose language to acquire the data I'm processing. There are some processing steps that I easier in R though, so I offload things to that when it is more efficient. But for simpler things, I find that numpy is more than adequate for processing data that I've already got in a Python session.

I use them for bioinformatics analysis (large scale genomic comparisons and microarray data analysis). So the larger problem isn't the calculations, it's the data management. And for that Python wins over a pure R solution.

<comment><USER40> That's pretty much exactly how I feel.

I personally love R. More specifically I love how _everything_ is implemented (at least sketchily) in it. Most specifically, I love how its plots look. If it could handle the large data sets I'm working with these days (MRI 3D+time images, sometimes multiple contrasts at once) I would use it a lot more.

So yeah, RPy is another big win for the Python side of things.

</comment></comment></comment></comment><comment><USER43> For me, it was the 'magic'. Ruby seemed to have a lot of 'magic' working behind the scenes - which confused the hell out of me when I tried to figure out how something worked a particular way. Python on the other hand has far less magic and more transparency - magic replaced with a transparent box showcasing the logic... Just made it easier for me to wrap my mind around...

</comment><comment><USER44> One is not better than the other, and neither have "won".

</comment><comment><USER45> In Python you dont' have to type 'end', just kidding although for some reason it reminds me of VB for this reason. I wish it didn't but it does. Why have an end be anymore than 1 character on a serious note, that is lots of keystrokes extra not needed.

But more seriously Python is a growth like Javascript. It has grown and adapted to every change it has been required because it has a very rapid iteration time and is great for wrappers to core C. It is clean and maintainable.

For this it has made huge inroads to system administration, game development, tool plugins, web development, command tasks and everything else. I have yet to have one instance where there weren't numerous libraries for every task. Even if you don't want to use a third party library there are many examples of how to do it.

Python is really at it's core many things. It is a functional language, it is an OO language and it can be procedural. It can wrap intense lower level libraries or port in a C extension for speed. The same code you wrote for your desktop api, can be used in a desktop app, a service, website, a web service, a tool plugin, at the command line or any way you need it.

It can float like a butterfly and sting like a bee.

Like Javascript, Python is based on a core few types, lists and dictionaries (objects). All the languages that seem to permeate like viruses have this basic computer science fundamental. It just is as simple and clean as you can get. Ruby also has this but it came a bit later.

And finally, it is named after the great Monty Python.

<comment><USER46> Just as a quick note, you can use '{' and '}' instead of 'do' and 'end' if you want. Standard conventions say that one line blocks get {}, and multi-line ones get do-end.

<comment><USER15> Just for blocks/procs. Method definitions still require def/end.

</comment></comment></comment><comment><USER47> I've worked with a lot of languages. Python, C++, Scheme (and CLISP), Java, C#, Perl, Ruby, etc. Every language I've used besides Ruby, I feel that I have to fight the language to actually implement my idea. The fact that programmers want flexibility should be obvious by the contortions present in C++ with boost, particularly the lambda libraries. People are so desperate for flexibility that they use template metaprogramming. This general impulse points to programmers wanting better abstraction capabilities. C# and Python have higher order functions and many other virtues, too. Ultimately, for me I could do anything I wanted to in Ruby without fighting the language. I'm sure there are people that have the same personal connection with Python. When I want the very flexible abstraction--I use Ruby. There are things that out of practicality I use Python and other languages for. Awhile ago I was experimenting with fractal terrain generation. The implementation is procedural, and all using Ruby does is greatly limit the performance of the program--so I implemented it in C++. I use Python for Bioinformatics research because of the excellence of Numpy.

</comment><comment><USER48> Python has IMHO better support for GUI toolkits - Tk support in main library, PyGTK+, PyQt. And two more words about library - import antigravity :).

And strong company backing: Google has have hired some of the core Python developers, and some of its infrastructure is written in it... Flumotion with its streaming media (although codec stuff is mostly gstreamer, but most of the networking stuff is in Python)

And the final straw - Python just seems to be a bit more beginner friendly...

<comment><USER49> People should be careful how much they quote Google as their reason for preferring Python.

The main reason was when they were standardising on the core-languages they could support, Python was enormously far ahead cf. the competition, so it was an obvious choice. And now, with all that code investment, you do NOT want to start again. And if you have the money, of course you'd be interested in hiring the best developers for your code-base.

Likewise, I believe Python 3000 is unlikely to used in Google for the forseeable future, due to that same code investment. I don't think Python 2.6 is fully supported, either...

I don't think "a bit more beginner friendly" is truly accurate. Most beginners will look for doc's and books, and for a good few years, recently, there was a dearth of good Python books while there seemed to be a new Ruby or Rails book every month, including several allowing you to d/l them for free.

I have to admit that I used to recommend Python to beginners for a long time, as it helped them avoid developing bad habits with the other equally popular "beginner" PHP and Visual Basic languages. These days, it's a toss-up.

If the person talks about writing web-apps, I'll tend to recommend Ruby and Rails as it has earlier ROI for a beginner, therefore a lot initially more satisfying.

<comment><USER50> This is somewhat tangential, but I'm pretty sure that Google re-writes the search code ever few years.

<comment><USER15> Yeah? Well, none of that search code is written in Python. It's C/C++.

See: [http://stackoverflow.com/questions/754301/what- programming-l...](http://stackoverflow.com/questions/754301/what-programming- language-is-google-written-in) [http://stackoverflow.com/questions/923225/does-google-use- py...](http://stackoverflow.com/questions/923225/does-google-use-python-for- anything-but-internal-utilities-and-administration)

</comment></comment></comment></comment><comment><USER51> I have been using Python for about year for Google App Engine projects. I have been using Ruby for about two years for various personal open-source projects. I like both languages, but I prefer Ruby over Python.

I hate Python's neglect (by Zed Shaw): <http://www.zedshaw.com/blog/2009-05-29.html>

Ruby seems to be so much more "symmetric", Python feels like a hack on top of dictionary to me.

<comment><USER18> _What I will blame Python for is the lack of even the most basic time conversion features that even C has. If all they did was give me the exact same POSIX C API I'd be happy. Instead, I got some half-assed library and some half-assed rationale about why this is a better way to do it._

Ermm, datetime.strptime and datetime.strftime?

</comment></comment><comment><USER52> Any popularity in Python over Ruby stems largely from the fact that Python came first.

I've heard Python developer's working on a Ruby on Rails application that the problem with Ruby is that approximately equivalent to Python in terms of productivity. They wanted to use Python, but pragmatically you can't make the case to management to switch from one language to the other if the other language is more or less the same. But most of the time this effect works the other way around, where Python was established before Ruby.

I was doing Perl in 1999, and looked at switching to Ruby or Python. Python was still quite small back then, but you had web frameworks (Zope, Twisted), albeit the incarnations back then are clunky by today's standards, but Python was establishing itself as a clean, readable, dynamic language. Ruby on the other hand had no web frameworks, and almost no documentation in English - <USER2> only reason I was considering it was because I was working with a Japanese localization team and they thought Ruby was quite hot.

The debate over which dynamic or scripting language to use was always between Perl and Python back then. Perl was the incumbent and Python the challenger, Ruby rarely factored into the picture. It wasn't until Rails started to become useable and gain attention in 2004 and 2005 that Ruby interest started to really blossom. And so Python was well established for many uses: scientific computing, ad-hoc data processing, network programming. If you're a development manager of an application that you want to make scriptable, you would have made the decision to already go with Python, there just isn't any compelling reason to switch to Ruby beyond the sake of switching.

Another example is IronPython versus IronRuby: work started on IronPython in 2003, work started on IronRuby in 2007. IronPython is at version 2.0, while IronRuby is at version 0.5, and this is reflected in the polish of these language implementations. A .Net developer might decide that they prefer the idiosyncracies of Ruby over Python's idiosyncracies, but if they had to start a large project in today, they'd most likely choose IronPython since there is much less risk of the project bumping up against the rough edges of IronPython versus IronRuby.

</comment><comment><USER53> Just my personal story, but perhaps extrapolating from it will help answer your question.

At my job I use Python because, well, at some point before I arrived one of the senior developers went on a jihad against Perl. :-)

I've read stuff about Ruby and while some things about the language intrigue me, it seems that any application you can build with Ruby can also be built with Python. If I'm going to learn another programming language in my Copious Free Time, I want to learn something _really different_ from what I already know, not something that has pretty much the same features with different syntax and libraries. So Python wins by inertia.

</comment><comment><USER54> Most of the discussion seems to ignore the "in this space" (scripting existing software packages) part of your question.

I submit that Python is more popular in this space because:

\- many end users will be users of the package first, and programmers very much second. In this case a very gentle learning curve is more important than ultimate expressivity for hackers.

\- In the same vein, it superficially looks more like BASIC than Ruby does

\- The C API may be simpler to use than the Ruby interpreter, though never having used Ruby's C API that's speculation on my part. Never understimate implementor laziness as a technical driver.

</comment><comment><USER55> I chose Ruby mainly because of all the syntactic tricks and weirdness but despite slowness.

You might choose Python for exactly the same reason; e.g., I wouldn't use Ruby on teams with >2 developers, especially in Google. Python is more straightforward but at a (small) price of freedom.

Example: you can rapidly prototype in Ruby using blocks and extend basic classes (even integer) using monkeypatching. I was fascinated by this, yet I wouldn't monkeypatch when working with other people so that advantage goes out of the window.

</comment><comment><USER56> I think it's mostly about maturity, of the runtime, of the language, and of the community.

For example, Ruby has backward incompatibility issues in minor releases that would never be permitted in Python. They had to jump to Python 3 for even fairly small things that wouldn't be accepted in the 2.x line. Even subtle incompatibilities between Python versions are taken seriously, and there's a documented process for deprecation that involves multiple releases and means when a feature is deprecated it'll probably still be available for years. There's cruft in the language as a result, but for people using Python seriously this is more than worth it.

I think the Python-Dev community is also more mature. Changes get serious review. Though there's not a formal "core", strong objections from certain people are enough to bring a new feature back to zero and require a restart (not because those people have special weight, but because they are respected and everyone kind of understands there's a benefit to listening to crotchedy naysayers if they are smart crotchedy naysayers).

The community is large enough that there's a lot of domain knowledge. Python is better at getting a canonical and complete solution to a domain problem than Ruby. WSGI discussions for instance involved some people with a very intimate knowledge of HTTP. People work hard to get 95% solutions instead of 80% solutions. In part because Python has been around a long time, and there's already at least an 80% solution for whatever problem you are looking at, and if you are going to throw your hat in the ring you ought to be ready to try harder. I think the more aesthetic tendencies of the Ruby community work against it here, as people are more likely to rewrite for aesthetic rather than functional reasons. (OTOH, when Python settled early on some 80% solutions, it's caused a lot of difficulties because it's been hard to overcome inertia to introduce a better solution, while it's hard to get really good adoption of the 80% solution; pydoc would be an example.)

Then there's simple maturity. The VM is more stable; it may not be a great VM, but it is predictable. There's lots of tools for writing extensions. There's code for dealing with large data sets, for dealing with images, for accessing system libraries, etc. For any one problem Ruby might work fine, but for the problems you don't yet know you'll have to solve it's less likely you'll hit a blocker with Python.

<comment><USER16> Ian B., aren't you occasionally one of those crochety naysayers? :)

</comment></comment><comment><USER57> They're both equally Greenspuned to usefulness.

</comment><comment><USER58> One major problem with Ruby has been that the performance as been _much_ slower than Python. This is no longer true with Ruby 1.9. I happen to have done a benchmark using a recursive Fibonacci algorithm yesterday, results: <http://pastie.org/528717> source: <http://pastie.org/528720>

I wouldn't say Ruby has lost just yet.

<comment><USER59> I don't think performance is holding ruby back I think that libraries especially mature and massive libraries, or lack thereof, is holding ruby back. Not to say people aren't working on it give ruby some time it will probably catch up especially with rails but just not right away.

<comment><USER58> Performance has always been a finger in Ruby's eye, but with 1.9 that doesn't seem the case.

Regarding libraries; you are right. Ruby has a lot of code out there, but much of it is in random repositories maintained by random people. Hopefully this changes.

<comment><USER60> Though it must be said, rubygems is _miles_ ahead of anything available for python.

<comment><USER61> I'm not convinced that's true, as the depth and quality of rubygems are inferior to the depth and quality of eggs available in python. Find me e.g. a "gem install scipy" equivalent for Ruby.

 _However_ \- "easy_ _un_ install scipy" REALLY needs to work!

<comment><USER60> My point precisely. I was referring to the package management system being better, not necessarily the packages available.

</comment></comment></comment></comment></comment></comment><comment><USER62> When you say "win", are you meaning in the sense of "there can only be one"?

Why limit the discussion to Python and Ruby? Why not include PHP, say? Why have Python and Ruby "lost" to PHP? What about C++, Java and C#?

Heck, VB is still more "popular" than either: [http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

<comment><AUTHOR> I wanted to understand the factors that led to a particular outcome: Python becoming the de-facto winner for scripting applications.

I compared to Ruby, because that's the language I would choose for scripting, based on the ability to create nice internal DSLs.

</comment></comment><comment><USER41> Having used Python a while, unnecessarily marking out statements a second time for the computer using brackets is a waste of time, and ugly. I use older faster languages and put up with this, but don't see the point of doing so with Ruby.

Nearly all of the installers and packaging formats and management tools in Linux have Python APIs.

Edited as I wasn't clear the first time round: I love Python's wide variety string methods, and the emphasis people put on these rather than using RegExs all the time (sorry, I have more Perl and less of a Ruby background). Looking further it seems there's Ruby equivalents of most of my frequently used methods.

I love etrees in the standard library. People who use regexs for dealing with tree structured data are mental. Again, perhaps a Roby fan might enlighten me if there's a similar data structure in Ruby, I wouldn't be surprised.

<comment><USER63> _"I love string methods. Not sure if Ruby also has them"_

What do you mean? Of course Ruby has a String class and plenty of methods on it, but I'm not sure if that's what you're talking about.

Ruby comes with an XML library standard, sure, but it's pretty bad. In my experience most people use competing libraries, of which there are several high quality options. You can get a walkable tree from the core library but you'd be better off with one of the superior third-party libraries like hpricot or nokogiri.

(edited badly written original)

<comment><USER41> You're right, that was ambiguous, I've edited my post to clarify.

The behavior I'm referring to is loading XML into a tree shaped data structure, so you can reference particular branches when seeking or adding content, and not have to think about about tags (well, once you'veran it though BeautifulSoup or a similar cleaner).

<comment><USER63> That's OK, my reply was also pretty ambiguous :D

I am not really familiar enough with Python to say for sure but from what I know, XML libraries are probably superior on the Python side - in fact most "enterprise" interoperability libraries are probably better, or at least more mature. The situation on the Ruby side is improving rapidly, but given its history, yeah, many things like that are probably a little behind. Ask again in a couple of years!

The flipside of this, though, is that everything in Ruby is currently in a state of flux. The "winner" of the libraries is constantly changing and the rate of progress is actually quite staggering. There's excitement, momentum and willingness to embrace new ideas in the Ruby community that seems to exceed Python's.

So yeah. If you want stable, mature libraries that you can rely on for the next 5 years, Ruby is probably not the choice for you right now. If you want, however, to constantly live on "the edge" and see, say, 5 competing interfaces to the latest DB come out within days of its alpha release then Ruby's the go.

This is all fairly minor though - they're both great languages with great communities, I don't get all this "A vs. B" nonsense. There are certain libraries in Python that I wish were available in Ruby. There are certain libraries I like in Ruby that I know are not available in Python. My advice to a novice would be to choose the one whose syntax they prefer.

<comment><USER41> Python has similar issues tho - look at unit testing. The standard library has unittest, everyone prefers nose.

</comment></comment></comment></comment></comment><comment><USER64> Using edge cases in the syntax to construct an API with unusual calling conventions is not "writing a DSL." Unless you build a compiler/translator for it, it is not a "DSL," it is plain-old Ruby, happily accepted by any conforming Ruby implementation--nothing more.

After their pretentiousness, their arrogance, and their vociferous obnoxiousness, I find their misuse of this once-widely understood term to be their most annoying attribute. It seems like not a day goes by without some eager Ruby programmer hacking together yet another block-based API that kind of, sort of looks like Smalltalk if you squint enough, uploading it to GitHub or some similar site, and then slapping the "DSL" label on it, because Ruby, apparently, is just too cool and powerful a language to have mere "libraries" or "APIs."

<comment><USER9> What is this, bring out the Trolls day?

Ruby does in fact both have libraries and APIs (hyperbole aside). But none of what you've described is a reason why Python has become more prevalent than Ruby. This is just your personal bone to pick over _nomenclature_ used by the Ruby community.

Rails is not the only piece of software in the Ruby community, and definitely not the most well designed (although it too is being improved significantly both in consistency and cleanliness in the push to 3.0).

</comment></comment><comment><USER65> Both have their uses. I was a Perl hacker so Python was the obvious choice for me - but I would use Ruby for specific projects, for example if I desperately wanted a one-off app that primarily depended on a stable Ruby library where no Python one existed.

<comment><USER66> "I was a Perl hacker so Python was the obvious choice for me"

Interesting. I was a Perl hacker, and Ruby was the obvious choice for me.

</comment></comment><comment><USER67> Ruby feels like all the misery of Perl mashed into Smalltalk. Which is a shame, because I hear such good things about Smalltalk.

</comment><comment><USER68> <http://xkcd.com/353/> I need no other reason.

</comment><comment><USER69> python is easy to learn like php and ruby have sometimes strange looking syntax like perl for newbies. A good programmer doesn't have this problem and will love the goodies and syntactic sugar from ruby.

<comment><USER70> php syntax is much more perl-y than ruby

</comment></comment><comment><USER71> NumPy.

</comment><comment><USER72> Google SketchUp is scripted in Ruby

</comment><comment><USER73> For embedding and scripting, I'd take python too. It'a s known value here, and I've heard ruby isn't so much.

When NOT talking about embedding or scripting, I'll probably take ruby.

</comment><comment><USER74> 1\. Get latest OpenSolaris. 2\. Install latest SunStudio 3\. download latest source of Python (3.1) and Ruby (1.9.1). 4\. Try to build them with CC=/opt/SUNWspro/bin/cc" CFLAGS="-m64" 5\. See the results. Run make test for ruby.

<comment><USER41> So Ruby compiles cleaner on failed Unix OSs?

<comment><USER74> No. Its standard modules were coded more portable way.

btw, Solaris will stay on its niche like FreeBSD.

<comment><USER41> 10 years ago Solaris' niche was being the standard OS at financial services companies. These days, that standard is Linux, generally Red Hat - nobody's buying SPARC anymore and Solaris on Intel runs very few apps. The largest hedge fund, the top tier investment banks, and the top retail banks have all abandoned Solaris. The only new purchases from Sun are support contracts on ancient kit that's still waiting to be replaced.</comment></comment></comment></comment>


Local File Editor for Chrome using NPAPI. - <AUTHOR> https://github.com/captn3m0/sympathy

<comment><AUTHOR> I've seen lots of opinions about such a project. Lots go against it, as in the case of recent Chrome Terminal, while many have been asking for such a thing.

Is this good? Will you be interested if your browser becomes your editor and terminal as well?</comment>


Is 'Friending' in Your Future? Better Pay Your Taxes First  - <AUTHOR> http://online.wsj.com/article/SB125132627009861985.html

<comment><USER2> Don't tell lies that can be falsified by looking up publicly-available data. Is this really so hard?

<comment><USER3> What's changed is not the publicly available data, but the cost involved in searching it.

20 years ago would it have been worth the resources required to put a 'search agent' (a real investigator) into the social network (every pub) to recover a four figure sum of taxes owed?

People's expectations haven't yet caught up with regards to being caught for low level crimes that were routinely not enforceable in the recent past.</comment></comment>


Celebrate St. Patrick's day with Bitbucket by doing a "git push" - <AUTHOR> http://www.bitbucket.org

<comment><USER2> There's no information here, just a sign up page. How does this celebrate the day in anyway?</comment>


Is this the future of Project Glass? - <AUTHOR> http://www.geek.com/articles/mobile/is-this-the-future-of-project-glass-20120728/ <comment><USER2> Interesting video. A bit dark at the end, though. It bothered me seeing how disengaged both characters were when they were on their date. It's considered poor manners to have your smartphone out during a date, but what would happen if there was no visual signal to indicate that you were checking your social networks during dinner?

To me, these thought experiments put us close to the realm of 'post-scarcity'. What happens when first-world society can replace physical goods and entertainment with virtual ones? It's fun to think about.

<comment><USER3> Meh, alarmist tripe. People aren't _that_ stupid, and as with any new technology there will be a period of adjustment.

When smartphones first hit the mainstream, people had them out _everywhere_ , and yeah, you had a lot of cases where people checked their email during dinner with friends and whatnot.

But now that the technology has matured some, and we've gotten used to it, we've developed etiquette around its use. We can no openly frown when someone whips a phone out at dinner, we even play phone stacking games to make fun of the phenomenon.

So sure, when something like Glass comes out we will go through a brief period where we're abusing the uses and social acceptability of this device to no end. But that too will pass and will settle into a steady state that is nowhere near as dystopian as these alarmist videos would have us believe.

<comment><USER4> Unfortunately you just don't get it.

I and many others DON'T LIKE BEING RECORDED.

It is a gross invasion of our privacy, illegal without our permission and opens up innumerable issues should I do something that could be classed a crime. And absolutely no amount of "getting used to it" is going to change that.

<comment><USER5> > illegal without our permission

Unless you're in a public space, of course.

> absolutely no amount of "getting used to it" is going to change that.

The Amish believe something similar about phones in the house - the belief that a stranger being able to reach out and interrupt you at any point is detrimental. The rest of the world seems to have adjusted okay, though.

<comment><USER6> I keep Facebook chat turned off for a very similar reason.

</comment></comment></comment></comment></comment><comment><USER7> Alternative ending: she leaves, he appears disappointed but a closeup of his mouth shows a wry grin slowly appearing. Cut to her on a new date, switch to her view of a completely different looking guy. It's going great!

Outside shot of the couple reveals it's the same guy - he's just overlayed a different face on his own.

Cut to game wall .. "hidden identity" badge pro level

</comment><comment><USER8> Amazing video. Dystopian, yes, but dystopian visions are a useful counterbalance to the optimism and short-term thinking of most day-to-day tech news and discussion. It outlines the negatives of what could develop in the future, and it gives us all a jolt - shit, we realise, this stuff needs to be taken seriously. The imperative now is for us to monitor the development of these technologies and see that the negatives are minimised and the positives optimised. Because of course there are plenty of positives. This technology could have absolutely amazing applications - just like all of the technologies we are haphazardly developing, there is awesome potential for both good and bad. The difference in outcomes will derive from the choices we all make as they emerge and mature.

Summary: a bit of fear is healthy here. Now it's time to start imagining the opposite of this video: how could such technologies make our lives and planet amazing?

<comment><USER9> There are plenty of positives in the film — the cool flightsim, the lack of need for a physical TV, help with cooking... heck, the dating app was even helping improve the dude's love life up until he revealed he used it at the end. I think the point is that these helpful augmentations, taken too far, become harmful.

But if we really want to improve the world, I like the counter in the fridge telling you how many days each food will stay good. That could be enhanced. What if, when you know you have too many zucchinis, you could click a 'share' button and instantly offer them to friends in your apartment building, so they end up in a neighbor's stir-fry and not the trash? Or let Sight predict your cooking habits for the next week based on past behavior, so when you're shopping, it can beep, put a red outline around the zucchini and say "recommend not buying - likely to rot before use." This kind of tech could seriously reduce food waste, which is a big deal in the developed world. I don't have a citation on hand for how much food gets thrown away in the US, but I believe it's over 25 percent.

</comment></comment><comment><USER10> Funny that I haven't seen one mention of gamification in this thread. To me that was the big takeaway here. When Glass/Augmented Reality/whatever-its- going-to-be-called hits, this could probably be how most people will interact with it.

It's all over this video. Watch the guy get frustrated when he doesn't get a perfect score chopping cucumbers. Note the high-score table in his closet. Even the "Wingman" dating app is pushing him to succeed via goals and achievements.

</comment><comment><USER11> If you found this interesting, I can recommend the 3rd episode of the British show "Black Mirror".

</comment><comment><USER12> If it comes to pass, it will create a huge gulf between people 'with' augmented sight and those without. That would not be helpful.

<comment><USER13> I remember when there was a gulf between people with cell phones and people without. Then cell phones got super-cheap. More recently, smartphones were a "digital divide", but that won't last long either.

</comment></comment><comment><USER14> Nice video, but it is a mixed bag of interesting and implausible. In particular, it's unfortunate that the video had to be mostly wasted on the implausible date scene, with an app reading emotions (such as impatience) and suggesting things to do or say. I'd say that is in fact the perfect example of what NOT to expect in any foreseeable future.

<comment><USER15> Actually the Affective Computing group at MIT has been actively working on this since at least 2007. They had a fully functionaly prototype last year. [http://www.newscientist.com/article/mg21128191.600-specs- tha...](http://www.newscientist.com/article/mg21128191.600-specs-that-see- right-%20through-you.html?full=true) and [http://theinstitute.ieee.org/people/profiles/rosalind- picard...](http://theinstitute.ieee.org/people/profiles/rosalind-picard- develops-specs-that-see-through-you)

<comment><USER14> I'm not surprised that this is a research topic but compared to all the other applications, I still think this will take much longer to get running reliably.

They are working on centered, pre-registered faces and stationary cameras. Once you add low-quality sensor that moves with the head (introducing huge amounts of motion blur to the image), and rich, real-world scenes full of other distractors, the technology will fall apart.

I'm certain we'll get hacked up implementations that work half the time if you keep perfectly still for some of the very basic and easy to tell emotions such as happy and sad, but it will mostly be a disfunctional joke for a long time. Time will tell!

<comment><USER15> Faces will be pre-registered with Facebook (and the Face.com tech they just bought). Anyway if it's that useful, people will learn to keep their heads still while waiting for the computer's assistance :)

</comment></comment></comment></comment><comment><USER16> The scariest part about this video:

Comments on it saying "well, it had a frightening turn towards the end".

The video opens with someone eschewing physical activity for literally wriggling on the floor, like a fish out of water. Streamlining activities like ordering food or selecting clothes, but each step we remove from the process, each abstraction, is another human interaction lost, another retreat into hermitage.

I don't want this future.

<comment><USER17> Who's to say that wriggling on the floor in a virtual reality simulation isn't the next Pilates or Yoga? Also, the girl referred to her jogging gamification and navigation app.

Isn't it plausible that many more people would exercise with the added encouragement training that such technology could provide?

Streamlining mundane activities frees time for more interesting ones. Augmented reality might enhance human interaction, rather than diminish it.

Anyway, I appreciate your thoughtful comment, but I thought I could counter it with some devil's advocacy.

</comment></comment><comment><USER18> "The real" Google glass is the bluetooth 2.0, if you know what I mean.

</comment><comment><USER19> I thought it was odd that the video's producers apparently don't know anything about the seduction community subculture, despite barely managing to side- swipe it in the dating app references.

I suppose I could see that they were trying to make it about AR, rather than PUA stuff... but really, all I saw was a criticism of PUA practices and nothing significant about AR issues except that they make PUA practices easier.

</comment><comment><USER20> Humans -> Androids</comment>


Ask HN: Is a summary of a non-fiction book a good substitute for the whole book? - <AUTHOR> For fiction the way a writer tells you a thing really matters.
But for non-fiction books isn't the summary good enough?
I am thinking, in particular, of business books.
On reading an interview with Doerr of his new book (measure what matters), I feel I have a good sense of what is in the book and how to implement it.
Do I? Has anyone read the whole thing? Can they comment? <comment><USER3> It depends on the kind of book.

For something like "measure what matters", the basic idea comes through in the title. I would expect that a summary would capture things pretty well - <USER2> will omit some detail, but it will be just detail. The big idea is the point, and that comes through even in the title. I suspect that most business books are in this category, but I am not sure.

For some things, though, the details _really matter_. Take "The C++ Programming Language", for example. You could, maybe, write a summary of that book. Do you know anything from reading it? Not really. Too much of the content is details. The whole point is the details.

</comment><comment><USER4> I think the difference between reading the whole thing and the summary is about making the knowledge yours.

If the non-fiction book has merit, it usually includes the rationale and real- world examples of the thing explained. Therefore you can examine the idea and have a deeper understanding of the subject or even improve on the original work.

Summary forces you to memorize a few facts and you wouldn't even have a basis to evaluate the validity of the idea. I read summaries only when the book is written for the general public and I already have expert knowledge about the subject.

In my opinion, reading summaries give a false sense of accomplishment. Reading is not about understanding one idea and implementing it. It is about understanding how to reach that idea, therefore you can improve on it.</comment>