It's perhaps developers fault, but my company recently adapted node.js and usually when you rewrite an app it is much better than the older one, not in our case, the app crashes on average every 30min in production, looks like express comes with a monitor that restarts the app which implies that this happens often enough to warrant such program. We also had situation when the monitor just died and nothing was there to restart it.
It sounds like you guys are not handling errors well. One can write a broken server in any language. Node-restarting tools are purely for the use case usually covered by crashing threads in other languages- that of shit really going wrong.
Angular 1.x is complicated and kludgy, IMO. It's not bad but it had a steep learning curve. Angular 2.0 should alleviate those problems. I've been using Aurelia a bit here and there and like it a lot. I think Aurelia's rigid, opinionated structure is clearer and succinct than Angular's more "framework" approach.
why angular? because once you understand the framework it's totally RAD. You can build complex applications in a matter of hours , and you don't even have to think about the app architecture , everything has to be in a certain place. AngularJS comes with a lot of battery included and for every task there is an angular module.
Why not angular ? hmm i'd say , the angular team fucked up with version 2.x announcement. I personally don't like this atScript/Typescript thing ,It's no longer safe to begin an angular project that will have to be maintained for years as devs don't really know if angular 1.x will still be maintained by Google 2,3,4,5 years from now.
With 1.x if you were into jQuery plugins, you could easily include them into any angular project which makes development really easy. You don't need to write classes or stuff like that, just write a function , put a bit of markup into the HTML and voila, you have a functional angularJS app.
I'm still using angularjs because it's just the best MVC framework out there.React isn't a framework but a view engine. React doesn't solve any architectural problem other than the view.
'React doesn't solve any architectural problem other than the view'
Fair enough. But, when coupled with a flux implementation (like Reflux) and a router (like React Router), what do you find missing in the React toolkit?
Don't know if the concept of DevOps is bs but I know that it's unfortunate if a developer never did system administration: there are many of this "git push heroku" kind of devs who pee in their pants if they have to deal with bare metal and the production servers. It's not that they wouldn't be able too handle them, it's that they are afraid because they never did and besides, good system administration knowledge leads always to better application and system design.
I blame Java much more than heroku. Corporate drone Java developers have a much greater tendency to only write code (too much code!) and not be interested in learning anything beyond the confines of their comfy auto-completing IDE. It seems to me Java developers will howl "not my job!" the loudest whenever anyone suggests that maybe they can mange their own environments.
In the enterprise Java world, the comfy auto-completing IDE is a smart strategic choice when "managing the environment" means weeks of frustration at installing, configuring and fitting together by trial and error an application server like IBM Websphere and the application.
Funny tools like Maven, Subversion and certain Eclipse plugins add extra puzzles and unpredictability for the true amateur, but the normal unforeseen complications are usually enough to forfeit any hope of good automation.
Sounds like what has been around since the mainframe days and batch computing. Or maybe one could liken it to Star Trek, with ops being the people keeping the warp core going even when faced with borgs and black holes?
Dogmatic thinking is never good. I've been on many conferences and many could been perceived as wasted time. And on one which was one of the worst I met tons of 'useless' people and by accident one guy who invested in me $4M.
So you never know who will be 'useless' and on conferences you meet so many people in a very short time, that it's ultra efficient. And you get appointments easier because meetings can be quicker.
However, most important with any conference is that you try to get at least 5-10 appointments for a conference which means you have to reach out to min 50
I don't think so, but I'll second a request for that! I think it would be good to have on the Showcases page.
Here are some examples that have some UI widgets in common, like list elements/navigation, but they are clearly different apps so it's not blatantly obvious which differences are based only on the platform:
Many folks in this thread are expressing that it's the OP's fault and not Ruby's.
The OP made his post as objective as possible, politely written and nobody is loosing his face, neither Ruby as a language nor the Ruby community. But people are still resentful and fire back.
I believe it's not a discussion about Ruby anymore, its strengths, its weaknesses and wether Ruby still fits in 2015—no it's the fear of people that their core competence might be less worth in future. That all the time and energy they invested all the years into one language might be not a good investment anymore. The fear that better tech will replace their tech and that they have to start at zero again.
I know I am going to be heavily downvoted for this post. Before you downvote just think a second again why you'll downvote me.
The point is that articles about rebuilding entire systems in different languages conflate two things — an architecture change, and a language changes.
This often results in the sort of appraisal you see here – 'Go is better for us than Ruby, because we completely rebuilt a system and it's now better'. That's got some value, but it's frustrating to see it used as something of an absolute metric regarding the suitability of a language when it's conflated by the far more important architectural changes.
So I think your view that there are a bunch of developers who are afraid of the future is a little shallow; rather I suspect there are a bunch of developers who saw exactly the same sort of thing happen when Ruby was becoming popular, and realise that extracting helpful data when there's an ongoing fad ('we're jumping from X to Go') is rather difficult.
But a change of language might bring you more tools, for example to handle thread-pools or process pools (service worker pools). Some of these things might be much easier to do in Go (or Java or C#) than in Ruby and if that part was a reason the new version works better the language change did help. I am no saying it was impossible to improve performance with Ruby but they might believe it was easier with Go.
I still think a monolith app can be more performant than micro services in a lot of situations but you might have to use things like thread pools/channels.
Others already mentioned several places you made invalid assumptions. Any good engineer worth their salt is language agnostic. I agree there are some that are threatened simply because their favorite language is no longer hip. I personally couldn't care less what the next language du jour is, be it Go or otherwise. What I do care about is that when posts like these are written they confound too many things and squander away an opportunity to let the larger programmer community double check all the numbers and verify that indeed the language/runtime was the culprit instead of something else. As it stands this is just a good story to justify the sunk cost of a re-write and nothing more.
Express: yes
Neo4J: why not
Angular: rather not