7 ms·
Nothing critical (banks, military, factories) runs on NodeJS/JavaScript/AWS so probably nothing. Do you think a lot about some old BASIC Accounting Software? T
by Tom4hawk 9y ago
Nothing critical (banks, military, factories) runs on NodeJS/JavaScript/AWS so probably nothing. Do you think a lot about some old BASIC Accounting Software?
There are probably only two languages which might face similar problem as COBOL: C and Java. For now they are both actively maintained and used for new projects - so we are fine for at least next 50 years.
- openasocket 9y agoNodeJS and Javascript yes, but critical things absolutely run on AWS.
- Tom4hawk 9y agoOf course it depends on your definition of "critical". There was AWS outage ~2 months ago and banking systems around the world worked pretty well, same with military, big factories didn't stop because of this outage, planes were still flying etc. It was inconvenient for some people (quite frankly I didn't even notice anything - I've read about that in my RSS reader few days later ;)) but nobody died(excluding heart attacks), countries didn't collapse, wars didn't start because of this.
- openasocket 9y agoThe outage was for S3, and only in the us-east-1 region. Any critical system should have multi-region fail over. Yeah, factories and planes and stuff are critical and wouldn't use AWS, mostly because those are embedded systems that shouldn't even rely on an Internet connection. But as for banking, Capital One is a huge AWS customer for example. DISCLAIMER: probably should have mentioned this earlier, I'm an AWS employee :)
- apaprocki 9y agoWe're one of the largest JS users in the world, and I'm pretty sure we'd fall into the category of "critical" (in terms of impact, not end-of-the-world).
- myrandomcomment 9y agoRunning on AWS and doing it correctly so that one of the many regional outages does not cause you an issue is really hard and is a software problem. On the other hand using a system of tested proven code that runs on a system that is redundant by design at the lowest level of component (a mainframe cluster) where the software does not have to have knowledge of the redundancy is a bit simpler. I really think people miss this very important point. Redundancy is transparent for 99.9999% of the software you run on the old big iron systems. For something like a modern application on AWS you have to know, understand and code for the infrastructure.
- openasocket 9y agoWe're talking about two different issues here. First is the architecture/software of a mainframe system, with all of its redundancy and scaling. Second is the issue of hosting and maintaining your own hardware. On the first issue I'll admit I don't know enough about mainframes, perhaps they provide redundancy transparently to the programmer, but I'm a bit skeptical. Perhaps you simply think the redundancy is transparent because you understand the mainframe infrastructure deeply and internalized it? The second issue I'll push back on. If you just want to host your servers on EC2, the SLA is 99.95% uptime. So that's about 4 hours of downtime due to outage a year. Put your servers in a multi-AZ autoscaling group and you're pretty solid. Bonus points for having autoscaling groups in more than one region. If you don't want to use any of the other services AWS provides, you can simply use them as a basic hosting service and get pretty amazing uptime. I've never used an old mainframe system, can you get greater uptime than that? Including hardware failures, power outages, network outages?
- myrandomcomment 9y agoThere was one point in my life when I was working for a large mainframe company ;) A bank wanted to move a system to a new site. The uptime on that system was 11 years. Uptime on a mainframe system is pretty much considered 100% 4 hours downtime a year is just way to much for some systems. Just have a google for "mainframe uptime". Yes the software is abstracted from the HW redundancy. You can pull CPUs with running code in systems and things keep working. Really - walk up and pull the CPU out. No impact to running code. Heck you can run your private cloud on one: https://www.fool.com/investing/general/2015/01/24/heres-why-ibm-is-still-building-mainframes.aspx https://www.fool.com/investing/general/2015/01/24/heres-why-...
- oblio 9y agoC, Java, C# and/or VB.NET.
- douche 9y agoPython seems to be sticking around. I suspect that in 50 years, Haskell will still be the up-and coming thing.
- oblio 9y agoI don't think Python has entered the kind of domains where they tend to keep the same version of the system around for 50 years: military, finance/banking/insurance/accounting, healthcare, etc. I mean, it is present there, but most of the time it's part of some glue or automation, it's not part of the core systems. Those are usually Cobol, C/C++, Java and .NET. Or some proprietary language in case they were crazy enough.
- osullivj 9y agoIn wholesale finance Python has been deployed for core systems over the last 10 years. For example JP Morgan's Athena platform goes well beyond glue or automation and handles pricing, intraday risk, EOD risk, etrading and STP. Hundreds of millions of dollars have been invested in the build out, and it will be around for decades.
- PaulHoule 9y agoPython, like COBOL and Excel is a good language for people who program as part of their work but are not professional programmers: data analysts, scientists, some finance types, etc. Compare that to C where buffer overflows are common, Rust where the type system is a high art, Java where thread-based concurrency "just works" so you can get in trouble using it, etc.
- woodruffw 9y agoMy (limited) experience under a government contractor sadly contradicts this: the primary requirement for many projects is to fit inside of a server rack and "just work" when hooked up to power and the network. None of my work was in NodeJS, but I'm positive that JavaScript will be floating around the backends and frontends of our government's services for a long time.
- Tom4hawk 9y agoQuestion is: what bad would happen if you pull out this project from rack?
- woodruffw 9y agoIn most cases, you'd probably make the employees at whatever agency or department very unproductive for the next few days (or however long it takes to find the server and plug it back in). The kind of projects I'm talking about are usually internal and critical for getting the right data to the right people within an agency.
- Tom4hawk 9y agoSo its is not critical from country/world perspective...
- woodruffw 9y agoAt what point does something become critical, in your book? The kinds of services I'm describing are critical to the normal functioning of government agencies. They're running now, and they'll probably be running for the next 25 years (at which point another contractor will upgrade them to something new and shiny).
- Tom4hawk 9y agoWhen problems/lack of it influence life(life != work) of many people. - If power grid goes down you are facing riots. - If systems on your new shiny Boeing go down you are facing deaths of dozens of people. - If your military systems goes down you are facing russia ;) If employees of government agency works less efficiently(is it even possible?) for some period of time (few days, months?) - nothing wrong happens. That's why it is possible to change those systems every 25 years. They will be less productive after software change, they will face new bugs in transition period. A lot (but not all!) of work those agencies do exist only because of some stupid laws (example: in my country you have to have special permit to cut down a tree on your land - I know someone who had to start building their house year later because they couldn't get permit to get rid of one tree, another one: you cannot inherit some types of parcel if you are not a farmer - you have to either become farmer[of course virtually - but it takes few months] or change parcel's type [it's not always possible and it's also few months of fighting with bureaucrats ]).