kkowalczyk

I run 3 websites written in Go (http://blog.kowalczyk.info/article/uvw2/Thoughts-on-Go-after...)

Those are clearly not Facebook scale servers but for majority of people: you don't need this or any other such solution.

Here's what I do for deployment. I have a fabric script that:

- copies the new executable to the server - kills currently running executable - starts the new executable

The worst that can happen is that a few connections will get dropped and that's perfectly fine 99.9% of websites. You don't control internet so the users will get broken connections all the time for reasons you can't eliminate. They shrug and hit reload button.

Complicating things to avoid few seconds of downtime was not worth it for me and rationally, probably not worth it for most.

The famous last words.

Of course they are overwhelmed by the taks of keeping AdWords clean, just like Apple is overwhelmed by the task of timely approving apps for App Store, despite having more money than god and the number of AdWord ads submitted to Google is several orders of magnitude greater than number of Apps submitted to Apple.

Processes that involve humans are inherently non-scalable and determining whether an ad crosses the line of acceptable usage is a human task.

And humans have different opinions so there will never be "evenly applying guidelines", not for google ads, not for App Store apps. The only time 3 people have exactly the same opinion is when 2 of them are dead.

If the advertiser is not happy with Google's service, they are free to use another service.

"no one forces you to do X" argument cuts both ways?

Neither C nor PyPy is "commonly used optimization strategy" so the comparison is very much correct.

People reach for C when they are desperate for performance, have the skills to do C, have the time to do C and are ok with loosing the cross-platform capabilities. Pure python code runs on mac/windows/unix (90% of the time). The moment you add a C module to the mix, you end up with the usual cross-platform mess (separate installers for each platform, complicated build processes etc.).

Except it doesn't, not when improvement is so dramatic.

If he rewrote Python in Ruby, the perf would have been more or less the same.

If he rewrote in C, he would get even better perf but at much bigger cost (in dev time).

The point of his article is that Go is almost as easy to write in as Python but gives you 10x perf and that's why Go is attractive. It has the right perf/coding effort ratio.

I don't think that maps fallout is fairly characterized as "bunch of bloggers were pissed".

Look how iPhone vs. Android sentiment changed over time.

At first the majority opinion was that Android was capable but slow and unpolished.

Around 4.0, the majority opinion was that Android was getting closer to iPhone but not quite there.

The most recent sentiments are: Android is starting to outclass iPhone in some important areas (Maps, Google Now).

Obviously, it won't suddenly cause everyone to stop buying iPhones and start buying Androids, but if things continue, the tide will turn.

Simply stated: Google is out-executing Apple on software. Press, bloggers and everyone else are noticing that and people do care about what The Verge writes or that people like MG Siegler go from "Android is crap" to "Android is really, really good".

So yes, things like Maps and Google Now are important and hard to re-create by a company like Samsung (or any company, period). That keeps Samsung (at least for now) from forking Android and trying to squeeze even more revenue out of it for themselves.

Google's future control of Android will depend on how many important and hard-to-recreate pieces they can implement, and given that they are cloud services company first, they are well positioned to execute on that.

Let's remember this is in context of owning guns and having children.

Children like to swim in pools. Children like to ride bicycles. I sure hope even the most enthusiastic gun owner doesn't give guns to children to play with.

I don't have to justify the usefulness of pools or bicycles. The kids like them, it's a fact.

As a society we tolerate the risk of those things. Is it rational? Should we? I don't care - we just do and that's a fact.

You can take away a risk associated with a pool or bicycle but only by taking away the fun that children have swimming in pools or riding a bicycle.

It's true that some parents enjoy the things you can do with a gun. It's also true that having a gun in the house is additional, sometimes tragic, risk with no benefit to children.

First, as a parent you're supposed to put the benefit of your child over the little joys in your life, like squeezing a trigger of a 44 Magnum or getting enough sleep.

Second, you can enjoy most of the benefits of having a gun without actually having one in the house.

I'm pretty sure you cannot hunt or discharge firearms within city limits anyway.

You can still indulge yourself in hunting or go to a shooting range without endangering the life of your child by having a gun in your house.

The flaw in this argument is that guns and pools have very different uses.

You can't swim in a gun.

Guns have no useful purpose. The fact that pools are more dangerous doesn't justify owning a gun, so there is no "cognitive dissonance" here.

You don't want a gun in your house regardless of any other dangers that exists, just like you want to child proof the house.

You want a pool for the same reason you want a bicycle: it provides lots of benefit. Ultimately we make a choice that the benefit of the pool or the benefit of a bicycle for the child is greater than the risk.

We can't eliminate all the risk.

We can eliminate unnecessary risk (like guns).

Looks like very flawed analogy to me.

It's one thing to believe in something when there is no rational reason for the belief (religion).

It's completely different to not believe something just because someone says so.

I don't know if burning wood is as harmful as the article says.

Prior to reading it I had no data and if I were asked, I would indeed think that it's safe given that people were doing it since the dawn of human race and no one drops dead because they sat near fire.

If a random smart aleck accosted me at a party and started telling me how it's sooo bad (which seems to be the article's author MO), I would brush him off, and that would have been a rational reaction.

After reading this article I'm inclined to accept that burning wood is dangerous but I'm far from convinced - it's a single data point.

The author is clearly so in love with his "clever" analogy that he can't help equating apples to oranges (a skepticism about a claim due to lack of expertise to evaluate whether it's true or false and an active, irrational belief that is internally inconsistent and whose many aspects have been refuted by science and at a level that is comprehensible to regular humans (like finding carbon-dated human remains older than the age of universe according to bible).

Your nitpicking is correct. I don't think it changes the big picture, though, so it's kinda impotent nitpicking for nitpicking's sake.

If I were to be pedantic about every little detail, I would end up with unified theory of the universe.

But since you brought it up: MOOC will also dramatically alter how we look at higher ed.

For historical reasons, my CS department emerged from EE department, since electronics existed before computers. As a result, I had to take courses in analog electronics, semi-conductors and what not. Out of 5 years of study, about 3 were relevant to CS.

I hated those courses, they proved to be useless in my programming career and yet, I had no choice.

At the same time I couldn't have taken a course in Greek history, even if I also liked Greek history (Spartans, those buff, semi-naked men!) in addition to programming.

The future will not be like that. The future of higher ed will be à la carte.

People will no longer get a major in CS, they'll take whatever courses they like and think are useful in finding employment.

It's happening already - Udacity already made a big deal (rightfully so) about people who found employment at good companies after completing merely few courses.

(as an aside, the rarely spoken truth about programming is that you don't really need education; I don't credit my university with teaching me much about what's actually relevant to real-life programming)

I guess people see 10-20% completion rate and think: this is bad.

Let's do some math.

At my university (one of the biggest in Poland), there were 150 people majoring in CS per year.

According to the article, an average MOOC enrollment is 50.000. Let's assume 10% completion rate.

That's 5.000 people. It would take my university 33 years to graduate that many people (assuming 100% completion rate).

The cost per person? Several orders of magnitude smaller per student for MOOC.

Scalability? Almost effortless for MOOC, almost non-existant for the university (to double the number of students they would have to double the number of professors, double the number of buildings etc.).

What happens when you fail? At MOOC, try again. At university - you're out.

There are many reasons why completion rates are much better at university (you paid for it, you value it more; more external pressures (your peers, your parents), motivational support from your fellow students; the way you think about it (university: I have to do it or else it's really bad; mooc: no biggie, I can always do it again).

MOOC destroys traditional education at almost every other metric.

It's a classic Innvator's Dillema: a product that is not as good as what exists but so much better at some important things (cost, convenience) that it'll grow like weeds and will become better at things it's not good at (like retention) faster than incumbents becoming better at matching MOOC at price, convenience.

It's such a misleading title. It's nothing like Dropbox.

We're talking about 60 lines of python for the "server" and 90 lines of python for the "client".

That's a weekend hack, not a Dropbox clone.

It happened so many times in the past, that I'm patenting a method of getting on first page of HN:

1. Write something

2. Call it a dropbox clone

3. Congratulations, apparently no-one bothers to check if that "something" does anything even remotely similar to dropbox:

- does it have a GUI client with a highly polished interface?

- does it have an installer?

- does it have conflict resolution to reconcile changes made on different computers?

- does it try to not corrupt files if download/upload fails in the middle?

- is it self-contained or do you first have to install, say, python interpeter?

No offense taken. 2 comments, though:

1. fofou.org hosts the forum for my SumatraPDF site, which is 33,279 in Alexa. I think that's enough of a target, more than most forums out there.

2. I don't think it's productive to bring top 1000 websites into this particular discussion. OP's forum wasn't that popular and most forums, by definition, won't be either.

Once you're there you're playing a completely different game and at that level you should have resources to win it. I don't see spam on Wikipedia, StackExchange, Quora, HN etc. When there's will, there's a way to fight spam.

Blaming google for seo spam is not productive - spammers are legion and in constant battle to game google's ranking system, whatever it currently is. This won't change as long as google is used to search for things.

There is a solution to his particular problem: better forum software.

I don't want to trivialize the problem of writing spam-resistant forum software but it's not such an insurmontable problem (this forum being a proof positive for that).

For the reference: I've been running a fairly popular forum (http://forums.fofou.org/sumatrapdf) for several years, using forum software that I wrote.

I don't even require the user to log in, I don't require moderation for posts and yet I had zero automatic spam (I attribute this to my unusual captcha http://blog.kowalczyk.info/article/16fw/Best-captcha-is-exot...).

I occasionally get human spam i.e. someone writes a post with the only purpose of linking to some other website. I just hellban them after I see the post in my rss reader.

And I didn't even write any special anti-spam code (other than hell-banning), because I'm lazy. I can easily come up with simple ideas e.g. putting all posts that contain links in moderation queue.

To reiterate: his problems were caused by a crappy forum software that didn't do much to protect from seo spam.

I don't really know how current best off-the-shelf forums fare in this respect.

I would rather not spend my time maintaining my own forum software so I have high hopes for http://www.discourse.org. I'm sure StackOverflow had plenty of spam problems so discourse people should understand the problem.

It seems it all boils down to this: he didn't make as much money as he wanted.

I don't want to trivialize the issue: making money is not easy, but the guy over-plays the victim card.

He seems to be a successful artist. He quits and it's all a fault of other people, who don't pay him as much as he deserves.

Again, not to trivialize the issue, but an artist with a lot of fans should be able to find a way to make money.

Did he try to follow the steps of many cartoonists that make decent money doing daily cartoons on the web, like theotmealguy?

Did he try to create anything outside of work-for-hire arrangement that he entered (willingly, as a consenting adult) into with Disney?

No evidence of that.

According to him, it's just the system conspires against poor artist.

According to me, he's just a lousy businessman who lacks awareness of his own shortcomings and oblivious to many ways he could have made money with his art. Instead he chose a safe route of employment and as an adult he should understand that it also usually comes with limited upside.

If he wanted a bigger upside, he should have taken more risks.

"Patented" doesn't equal "was expensive to develop".

In the context of codecs we're actually seeing how it prohibits improvements of technology.

Broadly speaking (i.e. I'm sure there are counter-examples, but they are not significant in the big picture), people didn't patent compiler technology, and we had great progress in compiler technology.

People didn't patent database technology and we had great progress in database technologies, from both academic research and competition.

People didn't patent word processing technologies so that Google can re-implement Word functionality in the browser because none of the fundamental techniques have been patented. Again, lots of progress from competition.

For whatever reason, audio and video codecs are heavily patented and the technology is ludicrously outdated compared to what it could have been if we had progress from competition or academic work of free software implementations because the patents cover basic ideas in compression so no-one can build on them and patent holders have no incentive to improve the technology because it's much easier (and more profitable) to just collect royalty checks.

However, developing video codecs isn't any more expensive than developing databases or compilers or word processors.

See e.g. h264 encoder which is an open-source effort by few amateurs that is widely regarded as being of better quality than commercial offering costing thousands of dollars (because of patent monopolies, not because they were so expensive to develop).

You're confusing solid engineering with research.

SQL Server started as a fork of Sybase (Microsoft bought Sybase's source code and started hacking). Sybase, in turn, was based on Ingress and "Ingres was first created as a research project at the University of California, Berkeley, starting in the early 1970s and ending in the early 1980s" (http://en.wikipedia.org/wiki/Ingres_(database)).

SQL Server is literally based on technology for 70s.

Ingress was started by Michael Stonebraker, who then did PostgreSQL (which added novel, at the time, extensions to relational model), who then did Aurora, C-Store and Vertical (column-oriented databases), them Morpheus, then H-Store and then VoltDB.

Stonebreaker did more research (as in: creating novel things) than Microsoft as a whole in SQL Server.

SQL Server is a great database but it's a result of Microsoft paying an army of programmers for 24 years to work on improving a single product. It's a result of running a profiler often, not some unknown-to-the-world algorithms.

So, according to you, when Google employee writes a blog post on official Google blog (i.e. as an agent of private enterprise), this post is not covered by first amendment?

If New York Times publishes an article written by his employee, it is not covered by first amendment?

etc. etc.

Speed is pretty important.

Compiler telling you about a bug because you have a typo in your code (as opposed to blowing up at runtime, sometimes in a way that you won't notice) is also important.

Struct definition is also a documentation of your data. Another developer (or you a month from now) doesn't have to go back and re-read, say, Redit API docs. He (or you) can just re-read definition of the struct and know all the data that a given JSON request provides. That's nice.

An editor can parse the struct definition and give you auto-complete, which is also nice.

Your math, while precise, is meaningless.

I probably could have gotten away with paying $0 if I didn't care about the best performance.

App Engine is distributed. You get one front-end instance for free. The more front-end instances you spin up, the lower the latency for your requests (consider a fron-end instance a process, the more processes you have, the more requests you can handle in parallel, which lowers latency for each request).

All the money was spent on additional (3, I believe, front-end instances).

Was the price high? Yes, which is one reason I switched to a $60/month kimsufi server which hosts the blog and still has 99% of capacity free for other things.

It's possible I was over-paying. I'm not an App Engine expert. I picked the number of instances more on a gut-basis than a comprehensive analysis basis. I could afford it so it wasn't a big deal.

First, if you use C libraries, you can't just compile on OS A and copy to OS B. I'm not 100% sure but while Go has much better cross-compiling story than others, I believe net/http does uses OS's C library and therefore cannot be cross-compiled that easily.

Also, you have to copy the assets (templates and such) and if you're deploying a new version of a web app, you don't just overwrite the binary. My script makes sure that if something goes wrong (i.e. a new version doesn't work or has a bug), it's easy for me to revert to previous version.

That being said, none of that implies that Go makes deployment harder (or easier, for that matter) than deploying code in other languages would be. It's pain in the ass but nothing that I couldn't solve in a day with a script written with Fabric.

I did try D when it was in its early days (i.e. D 1) but at the time I was put off by lack of documentation, the standard library split (phobos vs. D) and general immaturity of the system. I'm sure things have improved since then but I really like Go's simplicity.

I develop on Mac, deploy to Linux (Ubuntu). Didn't have to use a debugger so far.

(I wrote the article and 3 web apps on Go).

I would be much more uncomfortable running on uWSGI than on net/http. As far as I can tell (https://github.com/unbit/uwsgi/blob/master/plugins/go/src/uw...) Go's uWSGI implementation is just a small wrapper over C code inside a dll.

It's not portable (support for cgo on Windows is extremely sketchy).

It also goes against common sense. Any code you can write in C, you can write in Go, except it'll be easier (Go is garbage collected, has built-in arrays, strings, hash tables etc.) and there's drastically smaller chance Go will have a security issues due to memory over-write.

It duplicates lots of net/http functionality.

net/http is well documented, well tested, reviewed by extremely knowledgeable people.

Most importantly, it is being used in production by me and many other people.

Finally, net/http gave me everything I needed to write my web applications. Before I would even considering using uWSGI (or anything else) someone would have to explain what exactly does it provide that is so indispensable for writing web apps.

I can't really quantify it as it was in drips but in general, since I already knew C and Python, learning Go was easy. I could have started to write a web app right away, following tutorials on Go website and elsewhere.

At the beginning it's frustratingly slow, as it always is when you learn something new, but if you know other C-like languages, picking up Go will be fast. You just have to put the time to learn standard library and Go way of doing some things.

Corrections:

1. "Some guy" = Jason Calacanis.

2. "on Twitter" = http://blog.launch.co/blog/there-is-no-series-a-crunch.html

You're saying that if Go had the same design flaws as C/C++, then it wouldn't be possible to write LLVM in it.

But Go doesn't most of the design flaws you mentioned. For example, there are no multiple Go compilers wildly diverging in what they understand. That's unique to C++. In Go, like in Java or C#, a compiler either implements the whole spec or it cannot be called a compiler.

Go also doesn't have the portability problems that have accumulated in C/C++ over decades.

Go doesn't have macros (which enable the mess that C/C++ code finds itself in).

Go doesn't have manual memory management, pointer arithmetic, array access is always bounds checked etc. - it's radically safer language than C/C++.

I also fail to see the logic connection between unused variables or unused imports and any of that.

Or how fixing the error caused by unused variable is a "maintenance nightmare". Count the number if #ifdef statements in boost and then let's have a discussion about what is and isn't a maintenance nightmare.

The crucial difference is that static typing is a well understood problem.

The subset of "modern languages without null pointers" and "languages used to write a lot of serious software" is zero.

And notice "a lot" in this sentence. Majority of serious software is still written in languages like C++ or Java, which are either much less safe than Go or at about the same level of un-safeness.

While I'm sure someone wrote serious software in Haskell, very few (comparatively speaking) did. We can theorize why "modern languages without null pointers" failed to take off at the scale of Java or Python, but that they failed is a fact and that makes all their properties, including lack of null pointers, of questionable utility in the craft of actually writing useful software.

Go is a pragmatic, minimalistic languages, built on proven and well understood ideas.

You mean only after 10 years since llvm has started and only after Apple has switched XCode to clang?

You should have checked out the project before ranting.

1. The major difficulty in writing an editor is in writing the editor core. He didn't write it from scratch but used existing ACE editor.

2. VIM is a huge mass of C code. Working on a huge mass of C code is ridiculously slow.

He's writing in JavaScript and using html for the UI - this is orders of magnitude faster.