The worst part is not that its 50 years old. The worst part is that some places still INSIST on using it. For instance I have to deal with FOTA and it's a pain.
Older technologies are more reliable and last longer, because they have survived the changes of time. That also means if you learn older technology (my rule of thumb is 15+– think Elixir, Lisp, Haskell, Python, Java, C++), your knowledge is unlikely to expire.
I was surprised to discover that FTP (or SFTP) is not reliable. A couple of years ago, I discovered that there were mis-matches between files sent to a remote SFTP server using Perl’s `Net::SFTP` and the checksum that was sent after the complete set had been transmitted. The uploaded files were a few bytes smaller than they should have been.
I didn’t have the time/resources for a deep dive to determine the root cause of the problem so my work-around at the time was to use `stat` to compare file sizes of the local and uploaded file. If they didn’t match, the file was simply re-transmitted – and it always worked the second time. ¯\_(ツ)_/¯
I think you mean Erlang there and not Elixir. Elixir itself is only 10 years old, Erlang is 35. That said, Elixir does seem to be pretty stable, I've not run into major issues when learning it with regard to dated material being "wrong" (either actually wrong with regard to the current language incarnation, incomplete like pre-`go mod` golang materials, or "off" from the current idiomatic use of the language).
I had a finance-industry client require we upload to their FTP server because they couldn't trust downloading the file over HTTPS from our server with a secure/unique URL.
I'm not in finance, but aerospace/defense is similarly change averse. Often things only change when the cost of the old way becomes too great (and even then it's hard) or causes a failure of some sort (security, bad release, missed milestone costing money). I recall at my first job that we had to sit a senior engineer down (in the hierarchy a level or two above the software team) and ask him to flip a switch on a relay board, reliably, every 1/10th of a second to simulate a test scenario. That was the thing that finally persuaded them to ok the purchase of equipment to automate those tests.
And this was a year or so after a major, and costly, rework was required due to a real-world system failure (no fatalities or injuries, fortunately) that would have been caught if testing had been more thorough. But testing wasn't more thorough because we simply couldn't actually flip switches fast enough to simulate a wide enough variety of behaviors, so the testing was woefully incomplete and the timing issue at the heart of the failure was sufficiently complex to be non-discoverable in code and design reviews. Literally having to spend several million out of pocket to fix a broken system wasn't enough on its own to cause them to let us improve our testing methods.
Worth noting, the cost of the new testing equipment was only in the 5-figure range, not the 7-figure range of the rework.
I had some related thoughts. They may have a strong content filter on their incoming web. I was sending them a CSV but we had to talk about it like it was a proprietary-format Excel document for the sake of those who would eventually be loading it with Excel.
My best guess eventually was that FTP was considered the best way to go around their content filter on purpose. Makes negative sense to me.
It's still pretty huge in the enterprise behind-the-scenes world of EDI exchange. I work in the railroad industry and use it pretty much daily (in addition to sftp, ftps, and other protocols).
