Earlier quoted context omitted.
Off topic, I guess, but color me unimpressed by the guy claiming he would fire someone for rejecting a pull request that does nothing but advance a political agenda.
Color me impressed, because the political agenda that's being advanced is gender equality in technology, which to me seems pretty worthy.
Node.js, a popular tool for building modern internet services, has split in two
161–166 of 166 posts
Re: Node.js, a popular tool for building modern internet services, has split in two
#162Earlier quoted context omitted.
Is that not cool anymore. What's the next "cool" thing?
ITs not that its not cool, its the likelihood of Dart to be implemented in most browsers is low.
Re: Node.js, a popular tool for building modern internet services, has split in two
#163Earlier quoted context omitted.
ITs not that its not cool, its the likelihood of Dart to be implemented in most browsers is low.
Browsers don't implement CoffeeScript, TypeScript, etc either, but that hasn't hindered those projects.
Re: Node.js, a popular tool for building modern internet services, has split in two
#164There is a big advantage to node.js that used to be mentioned a lot in its early days, but not much now. The advantage is still there, but it's only noticeable if a developer has experience in other server languages. The big advantage is that node.js had an asynchronous development model from the beginning. This caused all the code written since then to also be written using async. When a node.js project imports othe…
Why Elixir - http://www.theerlangelist.com/2014/01/why-elixir.html
Re: Node.js, a popular tool for building modern internet services, has split in two
#165Earlier quoted context omitted.
I think any serious projects should have a CLA, or require sign off like the Linux project does, and suggesting a change is the only way to get around having to deal with that. For known contributors, yeah, it's a nice feature.
CLA?
Re: Node.js, a popular tool for building modern internet services, has split in two
#166Earlier quoted context omitted.
Perhaps you could name some website/app servers that aren't mostly i/o (or event-timing) bound? I wouldn't say the use cases are limited at all. You can always run multiple process instances, and communication between processes isn't really so different in practice than inter-server communication... Which just means you are scaling horizontally by design earlier in development.
I worked on some web-based project management software which was highly CPU-bound. A typical scenario would be the application querying a database for financial figures, doing a large amount of calculations on those figures and then generating an HTML report from them. I imagine any application with large amounts of business logic like this will be the same.