Earlier quoted context omitted.
Comments like this never, ever improve threads.
Yes they do. I learned that there are lots of places using golang in production, without even having to ask.
I think you misread my comment.
Go After 2 Years in Production
151–160 of 178 posts
Re: Go After 2 Years in Production
#152Earlier quoted context omitted.
So you ignored the part where the OP described having actually used it in development and liking it?
I think we need more than 1 account of Go in production before we start high-fiving each other about Go in the mainstream. And to be fair to the person you are responding too, there has been an inordinate amount of Go articles on HN over the last few months compared to anywhere else on the internet tech/dev wise, so much so that a number of my friends have independently made a joke of it.
> there has been an inordinate amount of Go articles on HN over the last few months
They are being submitted and voted up by people. If you want other content, then create / upvote it, just don't pretend 'inordinate' means anything in this kind of context.
Re: Go After 2 Years in Production
#153I know it's cliche, but I still can't live without generics or a macro-like approximation thereof. I suffered under Java 2 for too long to go back to that.
It's not cliche, it's just personal. For instance, most of the code I write is numerical code. To that end, any language without operator overloading is a non-starter, since it's far harder to find a bug in: div(add(mult(-1,b),sqrt(sub(pow(b,2),mult(mult(3,a),c)))),mult(2,a)) than it is in (-b+sqrt(b^2-3 a c))/(2*a) On the other hand, if I wrote server code, operator overloading would be far less useful. I'd probably…
> and the type checker can't tell a sine from a logarthim
Oddly enough, in Go it can.
type sine_val float64
type log_val float64
(Not that I am advocating this sort of approach, but it is possible to let the typechecker work this stuff out if you are dedicated)
Re: Go After 2 Years in Production
#154Earlier quoted context omitted.
"Reasonably fast" is in the eye of the beholder. In my opinion, many popular platforms and frameworks are not reasonably fast at providing a response in real-world applications. As a result, many web sites are frustratingly slow in my opinion (for example, a popular site used for hosting source code repositories). If those sites were to capture and share their profiling data (including time spent in drivers and the O…
I think the confusion arises because jd007 is discussing throughput and you are discussing latency . Latency and throughput can be inversely related depending the precise architecture of a system (queueing is the classic mechanism that trades them off). But in terms of "horizontal scaling", the goal really is to improve total throughput. Often imposing a tax on latency due to coordination costs.
True enough. This thread of conversation was kicked off by the premise that most applications are bottlenecked on their database server. When I said, "not necessarily," I meant as far as latency is concerned--for any given request on a slower platform, it is likely that the database's contribution is actually a minority.
That is the conventional wisdom I find in need of disruption.
But you are correct. Since a conventional database server can be more difficult to scale horizontally on its own right, even that small latency contribution, when multiplied by the number of queries being run by a wide array of application instances may ultimately mean the database server is the first observed bottleneck. By which I mean, the first device to reach 100% CPU without the simple recourse to just throw more money at Amazon and spin up another instance to solve the problem.
So I buy that.
But when I see slow web applications--when I criticize a site for being slow--I am always talking about latency. When we look under the hood, assuming the application is not being silly with its queries or doing a fundamentally challenging work-load, user experience slowness (latency again) usually originates from the application's own code or slow platform.
For example, I've observed applications that require 200ms of server-side time to render a login page. Behind the scenes, I may observe that they are badly designed and include one or two trivial (but utterly unnecessary) queries. Still, those two queries can be fulfilled by modern hardware in ~5 to 10ms. The remaining ~190ms of server processing is on the application. To my mind, that is unacceptable. A login page should be delivered in ~3ms of server time (under load!) on modern hardware.
And back to the OP, Go is a platform that brings JVM-class speed (the capability to return a login page in ~3ms) to those who can't stomach Java. Bravo to Go!
Re: Go After 2 Years in Production
#155Earlier quoted context omitted.
Has anyone here used Haskell in a production environment? I want a language that is small, clean, and can provide a lot of static guarantees . I know many people find static guarantees and unacceptable curtailment of their "programming freedom", but frankly I think it's the answer to many of the problems we face in software today. Small is another thing. E.g. Go and Scheme are small . C++ and Scala are large . You kn…
Total functional programming (and the associated analysis of codata has already been touched on), so I'll just address your interest in static guarantees for space usage. The Virgil programming language[1] has been designed with exactly this in mind. It is aimed at embedded systems where memory is extremely constrained and running out of memory could kill people. Heap allocation is not possible in the language and al…
I wonder if a restricted subset of a stack based language like Forth might also work?
Re: Go After 2 Years in Production
#156Earlier quoted context omitted.
This is probably a good thing in many respects because Go doesn't have the baggage from yore, and it was created by some pretty smart and capable people. As was Javascript plus Node.js two years ago, Ruby and RoR five years ago, etc. You'd think that more reasons are required than 'it is new, doesn't have baggage in was created by smart people'.
Go isn't a framework. NodeJS is a framework, as is Rails. JavaScript and Ruby are very old languages, both laden with baggage.
node.js is not a framework, it's a platform written in c++ and js.
Re: Go After 2 Years in Production
#157Earlier quoted context omitted.
I think the confusion arises because jd007 is discussing throughput and you are discussing latency . Latency and throughput can be inversely related depending the precise architecture of a system (queueing is the classic mechanism that trades them off). But in terms of "horizontal scaling", the goal really is to improve total throughput. Often imposing a tax on latency due to coordination costs.
True enough. This thread of conversation was kicked off by the premise that most applications are bottlenecked on their database server. When I said, "not necessarily," I meant as far as latency is concerned--for any given request on a slower platform, it is likely that the database's contribution is actually a minority. That is the conventional wisdom I find in need of disruption. But you are correct. Since a conven…
I don't entirely disagree with you but I do think you're not doing anybody any favors by "disrupting this conventional wisdom."
When I was an engineer at Formspring I profiled our social graph service which was basically PHP client hitting a Python service that queries against Cassandra. Thrift was used to communicate between PHP and the Graph Service and, being Cassandra, Thrift was used between the Python Cassandra client and the Cassandra server. So, two-way serialization, twice.
In the end, this isn't a bad design. I didn't write it then but if I were re-writing it now I'd probably use protobuffs but aside from that, it was a clean separation of concerns and fit in nicely with our larger SOA.
Point being, though, that serialization is CPU expensive. Reading from Cassandra was blazingly fast compared to the work Thrift was doing.
All that said, I think noob engineers should be taught that network operations (db queries included) are at least an order of magnitude slower than, say, opening and writing to a local socket. Experienced engineers can see the balanced view of things and agree with the point you're making, so advocating it, IMO, will only serve to make you look smart and confuse noobs.
Re: Go After 2 Years in Production
#158"Two years in, Go has never been our bottleneck, it has always been the database." I would expect this to be true with any language, if you code well. Regular web applications do not have state so they are very easily scaled horizontally anyway. Databases on the other hand are trickier to scale the same way and will end up being the bottleneck almost all the time.
Ah yes the old "engineers are more expensive than machines" adage.
Thing is, that's true for some small number of machines. But when you build scalable systems and actually scale them you get to a point where the balance tips. And it just so happens that building those systems is exactly what the Golang team has in mind.
Re: Go After 2 Years in Production
#159Re: Go After 2 Years in Production
#160Earlier quoted context omitted.
True enough. This thread of conversation was kicked off by the premise that most applications are bottlenecked on their database server. When I said, "not necessarily," I meant as far as latency is concerned--for any given request on a slower platform, it is likely that the database's contribution is actually a minority. That is the conventional wisdom I find in need of disruption. But you are correct. Since a conven…
I don't entirely disagree with you but I do think you're not doing anybody any favors by "disrupting this conventional wisdom." When I was an engineer at Formspring I profiled our social graph service which was basically PHP client hitting a Python service that queries against Cassandra. Thrift was used to communicate between PHP and the Graph Service and, being Cassandra, Thrift was used between the Python Cassandra…
I appreciate your point of view. It's not my intent to confuse noobs.
You're right, with that in mind, the conventional wisdom is worth retaining so to instill the proper fear of treating database queries as trivial. Thinking of queries as cheap--or not thinking about queries at all--is what gets applications into a state where a single request runs dozens if not hundreds of queries to deliver what is effectively static content! :)
That said, I've met more than a few senior folks who continue to fiercely stick with the premise that database queries trump all. As someone else in this thread said, profiling can be illuminating, even for senior developers. But it seems on that point, we're all in agreement.