I'd like to think that if we weren't all watching Node we'd have more people to pitch into other things. I hear a lot of bluster about "learn new things" but I often just see people sticking with what they know. When the bright minds of web development are figuring out new ways to make JavaScript less awful, those minds aren't focusing on other solutions.
FWIW I think Elixir holds a lot of promise for the future. Projects like https://github.com/dynamo/dynamo look really cool. Of course, it's new, and alpha. But maybe we could all give it a try?
Erlang pretty much blows Node.js out of the water, in terms of sophistication of concurrency primitives (to mention one thing). Erlang is really just syntax on top of BEAM, which is pretty tailored to the language (you'll notice Elixir and Erlang share identical types etc).
Elixir adds some nice metaprogramming features, and I love that it exists. Erlang is used for a lot of Important Things in production, and its value to many developers is stability and fault tolerance. Erlang moves slow. It's nice to see a sister language that can more rapidly develop new language features (maybe some of the goods ones will get added to Erlang (:
Joe Arms post about Elixir is pretty interesting [1]
A whole class of programmers have learnt to write continuation-passing code in Javascript for asynchronous operations, as that's the way AJAX works. Moreover, it's the only way you can do things in the browser.
Node is web-browser style javascript programming, detached from the browser GUI and given the ability to accept inbound connections. Along with this has come a whole slew of fun wheel-reinvention around frameworks and templating engines.
I'd argue the simple approach of having a web server (nginx, apache) send requests to a pool of workers (perl, php, python, ruby) is considerably superior.
the problem is can workers do something else while waiting for the db to respond? AND are all libs built for that use case? tbe only advantage of nodejs is you have no choice but to write code a certain way.
The biggest webservices of today like google search, facebook, aws are all written using models that your parent suggests. Are you saying if these guys rewrite all their code in Go, they will basically cut down 50% of their operation costs or something? What exactly does 'worker can do something else' translate to?
Technically, yes - the workers can be multithreaded. If you put multithreaded workers behind an event-loop web server (both nginx or apache can do this), then they can handle many http keep-alives as well. It's not the same thing as using an event loop throughout the whole stack, but it's pretty effective.
When you take the time to learn relational databases, sql, normalization and maybe some caching, suddenly you don't find yourself spending very much time waiting on the DB.
If something indeed is going to take that long, perhaps you shouldn't be making the user wait on it either. Queue that shit.
I've spend a lot of time porting node.js code to Go. While the Go applications typically get an unfair benefit of being the result of the refactor, they have without fail (in my XP) had similar to drastically better runtime characteristics, while I would argue (and my teammates agree), being much simpler to read and maintain.
I have have written a few web apps in Go as well spending most of my time writing things like high performance proxies, CDNs and databases in Go, and IMHO Go is a "more least worst" way to write highly concurrent code compared to node.
We have tens of servers across 4 Linode data centers. We get hit with both data-center-wide and single-server downtime pretty much on a weekly basis.
In the span of 3 months we had something like 25% of our servers go under "emergency maintenance" downtime. Just part of the ebb and flow of "the cloud", I guess.
You are not a lawyer, sure, but you are also, apparently, not Google's "compliance team". Section 10.1.2 says you can't charge anyone a fee for the "implementation". What is the "implementation" and what isn't? You might have one answer. Someone else in the company might have another. That's typical of big companies, where not everyone may enforce policies different, but still pretty scary for anyone who falls in this gray area.
Had to make an account and comment - my friend went through this whole thing and the terms of service get pretty fuzzy pretty quickly.
For his listings website that charged business owners fees for "premium" listings, Google[0] considered the embedded Maps to be part of what he was selling. They argued that the service as a whole (incl. maps) was "the product".
We disagree, apparently, but our interpretation doesn't mean diddly squat until push comes to shove.
[0] Edit: by "Google", I mean whatever sales drone is trying to get you to pay. I assume their salespeople are on commission like any other company.
> I assume their salespeople are on commission like any other company.
With one important difference: they're the most arrogant, uninterested and rude sales people i've ever had to deal with. "Because, what are you going to do, use Bing?"
Huh? This is definitely not true. As long as the map itself is not behind a paywall, you're fine, and charging for being listed in your system (not for visiting it) would pretty much easily pass the terms of service requirement listed above. Lots of people make money on sites with google maps embedded in them. The only thing you have to worry about is being more popular than 25k loads per day.
