Hacker Newsnew | comments | show | ask | jobs | submit | axelf's commentslogin

Corvette Z06 can do 0-60 in ~3s for $80k

-----


I also had issues with it crashing safari on an ipad

-----


The inkling app lets you buy ebooks.

https://www.inkling.com/

-----


why were they using python for performance critical code in the first place? Go seems closer to java's niche to me.

-----


Disqus was originally built on Django: http://blog.disqus.com/post/62187806135/scaling-django-to-8-...

It seems that this is what the found team was most comfortable with, so it makes sense that they proceeded to solve problems using tools they already knew well. At some point, they exhausted how far they could take their existing tools and started investing into new tools.

-----


What Go web framework did they move to?

-----


We're not using a framework. This is a tiny component and the rest of Disqus is still Django.

-----


It doesn't say, but probably none. My guess would be they just used "net/http" + Gorilla (maybe). Gorilla: http://www.gorillatoolkit.org/

-----


Given it sounds like this application is not "web facing" (i.e. not an API nor rendering HTML), the use of any "web framework" or Gorilla doesn't make much sense.

-----


I write back-end stuff like this all the time and it often has admin interfaces.

-----


I imagine at their size they're using raw Go without any framework.

-----


They had a fairly popular post on the subject a while back:

http://blog.disqus.com/post/62187806135/scaling-django-to-8-...

In short, since they were not really pushing volume with Python, just feeding data to Varnish, throughput wasn't such a big deal.

-----


Yes, why is Go constantly compared to Python?

-----


For me, it felt comfortable writing Go, considering I've been mostly writing Python for the past 8 years. So the transition was a lot more natural, compared to using Scala or Erlang or anything else.

Again, this is my subjective opinion, and this is why we chose to use Go for our new stuff instead of something different.

-----


wouldn't a single abstraction over postgres, filesystem, hadoop, etc be either really leaky or really inefficient? different datastores are better suited for certain kinds of queries. It seems like the programmer should be aware of what he/she is querying.

-----


You invert the dependency. The abstraction is over the things that the higher level code needs. I don't need to know about query types, indexes etc. I need some business answer (all log records between x/y, a user matching username x), I program to an interface that provides all the answers necessary for the high level code.

The implementation of that interface is data store aware and implements the interface in the most effective way possible for the data store holding the things I'm interested in.

-----


I'm assuming that the Iteratee companion object uses implicits to get the client connection. I'd really prefer something more explicit like socket.io's approach.

-----


That assumption is incorrect. Implicits are not used here (for that purpose anyways).

The client connection is handled by that "WebSocket.using[String]" handler. This is just a function that takes a function which takes a Request and returns an Iteratee and an Enumerator. In Play, this is known as an Action. Actions take Requests and return Results.

You can see that in the type signature of the WebSocket class: http://www.playframework.com/documentation/2.2.x/api/scala/i...

  (f: (RequestHeader) ⇒ (Enumerator[A], Iteratee[A, Unit]) ⇒ Unit)
So the client connection is not bound using implicits, it's bound when that function is actually executed. This function (f) is invoked by the router when a request comes in for that controller action. This is done using HandlerInvoker: http://www.playframework.com/documentation/2.2.x/api/scala/i...

Now, my explanation is not the most eloquent nor is it really necessary to understand all of this, though it certainly helps.

-----


The special language syntax is being removed. Its now just a library.

-----


It seems like most people are excited for kotlin, but no one is really talking about ceylon which recently 1.0. Im curious why that is, have you looked at ceylon?

-----


I have, it's definitely an interesting language, more ambitious than Kotlin and more bold too (lot of new keywords, disjointed types, etc...).

I prefer the most conservative, slightly incremental Kotlin myself, but it's purely personal and certainly not a knock on Ceylon, which was implemented by people I have a lot of respect for.

-----


> most people are excited for kotlin, but no one is really talking about ceylon

Perhaps that should be "most Groovy people are excited for Kotlin". The reason "Groovers" look at Kotlin before Ceylon could be because Groovy creator James Strachan and Groovy++ creator Alex Tkachman jumped over to Kotlin.

-----


I have experienced exactly the opposite of this. Nobody seems interested in using Kotlin, while I think it is pretty neat.

-----


It seems like every time someone tries to replace javascript with a better solution someone has to bring up vendor lock-in. Are we supposed to just live with javascript for eternity? When javascript was introduced it only worked on netscape browsers than other browsers adopted it later. It wasn't made a spec until later.

-----


Indeed. Every trial to replace "standards" is called "evil". From this perspective, the web platform is far from open. The result is we all are in a local optimum trap. I already gave up expecting cool future and decided to stick to the native development for a while (for a decade or more).

BTW, as a game developer, it would be nice if this rendering latency issue will be fixed soon.

- http://phoboslab.org/log/2012/06/measuring-input-lag-in-brow...

- https://code.google.com/p/chromium/issues/detail?id=168459

I think this response time issue is a real show-stopper than JavaScript performance.

-----


This along with the fact that you can't avoid GC when handling browser events makes it really hard to hit a consistent framerate for sure.

-----


Well, asm.js gets around this by piggybacking on JavaScript's syntax. So that's one approach.

Adoption really is a big issue, and I think it kind of misses the point to handwave it by saying, "Oh, adoption is such a big issue that it's insurmountable, so let's ignore it." Google hasn't really done a lot to work with anyone else on PNaCl, or even really to address any issues anyone's brought up with PNaCl. They're just sort of creating an island so far. If PNaCl is going to be a thing, they're going to need to get past that.

-----


Because it is never done in collaboration between browser vendors.

-----


How is this proprietary? Isnt there an open spec?

-----


For Pepper? There is not, in fact. There's some developer documentation, but nothing resembling an actual implementation spec.

-----


The code is open source, but last I heard there isn't a spec for PNaCl/PPAPI.

-----


The PNaCl ABI is defined here: https://developers.google.com/native-client/dev/reference/pn... - and it's definitely a work in progress we'll be trying to improve. As for Pepper, it's also all documented here and below - https://developers.google.com/native-client/dev/pepperc/

Granted, this is documentation, not a standards-body spec.

-----


Yes, certainly has had effort put into proper documentation. Do you know if there is also work being done to spec it formally?

-----


We're definitely considering it.

-----


Is there a PNaCl spec or just Google's implementation?

-----


There's a bitcode spec [1] and a stability doc [2].

1 - https://developers.google.com/native-client/dev/reference/pn...

2 - http://www.chromium.org/nativeclient/pnacl/stability-of-the-...

-----

More

Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: