Live data from Hacker News

XML is the future

bitecode.dev

381–390 of 408 posts

Re: XML is the future

#381
post #263

Genuinely curious, not being sarcastic or cute here. With hype everywhere, and job ads filled with buzzwords and acronyms, how does one choose what to learn? Something that is sane, that is joyful to work with, that will be around for at least a few years, but also puts food on the table? I suppose SQL is going to be around for a while? Any other recommendations?

If you're a software developer, cultivate deep expertise in one or two popular languages that are likely to stick around. Everything else - the hot new web framework or whatever - is downstream from the actual language, and is easy enough to pick up.

If you're in IT operations I guess it's harder to keep up, because everything is different.

Re: XML is the future

#382
post #30

It's easy to just mark XML off as one of the many fads in tech given how many there are. But I think it's much more worthwile to dive into the particulars of why it failed. While they're all fads, some of them share commonalities that, in hindsight, I think we can say were major catylsts to their downfall. With XML, it failed because something like JSON was much simpler. Time and time again I see people saying that j…

IMO XML failed because of mismatch between programming language structures and storage format. JSON is perfect because it maps 1:1 to arrays and objects. XML does not. There were whole ORM projects to map XML to data structures. That's a fundamental issue and replacing XML was not that hard. My prediction is that SQL will fail too. There are infinite attempts to dethrone it. And the reason is the same: tabular data d…

> Dethroning SQL much harder, though. It'll take decades.

Maybe not decades. I personally love EdgeDB (https://www.edgedb.com/) as an SQL replacement.

Re: XML is the future

#383

Earlier quoted context omitted.

Today’s beloved tech with well maintained docs is tomorrow’s institutional knowledge tech that companies rely on.

Not my observation sadly. We've got some excellent 10+ years old tech -- Golang, Rust, Elixir -- yet a lot of companies out there holds on to C#, PHP and Java with an death grip. And I've worked with all of these. The newer stuff is better in every way except penetration (which is held back by bias and misguided evaluations of the word "safe").

I wouldn't put C# and Java in the same pile with PHP as bad tech and Go against them as good tech.

Re: XML is the future

#384

Earlier quoted context omitted.

> Look I'm not even complaining. But it feels like I'm stuck in a Franz Kafka novel. We just keep changing and changing the same things again and again because that's the new way to do. Big distraction. Destroys your workflow. Forget about all the util scripts you wrote last 6 months being useless. Here's how I stay sane -- I focus on the changes. For the technologies that you noted, here are some good questions that…

I would phrase almost the same idea from the opposite angle: focus on the fundamentals that never change, and view the trends in terms of how they relate to those fundamentals. But also, those are some pretty odd comparisons. For sure Ansible and Terraform aren't directly comparable. If anything they're complementary. Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines.

I did a 3x of my career by doing this.

Now everything thing looks like a shell script or json exchange.

Ansible is a bunch of scripts. Terraform is a bunch of json exchanges.

Re: XML is the future

#385

Earlier quoted context omitted.

So how are you supposed to create static react app now?

They no longer want you to create a React app by itself[1], but instead use Next.js, Remix, Gatsby, or Expo. [1]: https://react.dev/learn/start-a-new-react-project

None of which are static. How are you supposed to create a static React app?

Re: XML is the future

#386
post #187

Earlier quoted context omitted.

> forget about it for a few years No version upgrade required. :D

Haha yeah I can say, with the same sincerity, that I get occasional calls about fixing PHP apps that I built 2007-2013. They've been running (without upgrades) on some forgotten server in a multinational corporation. I tell them that they should let their compliance department know, that the version of PHP isn't even supported, and I list some of the thousand security fixes that they aren't using. I usually end up VP…

I had this happen about a year and a half ago with an application I wrote in 2009. Finally got them to allow me to rewrite everything in C#, allowing me to keep up to date on security vulnerabilities and performance improvements, without having to do much but run through a series of tests when a NuGet package or .NET version upgrade is released. NuGet with current .NET is a far different beast now, than when you used .NET Framework and plenty of XML assembly binding.

Re: XML is the future

#387

Earlier quoted context omitted.

1. Pooling is trivial to setup with servers. In fact, pretty much all clients like Knex and Prisma does connection pooling by default without an external dedicated server. 2, 3. The promise is that serverless APIs can be deployed on the edge for improved latency. The edge does not matter if your data is centralized. So you're adding complexity without the benefit of speed. 4. One of the most important aspects of any…

> Even if you want a simple cron job ..., you can't do it with serverless functions. I don't understand this. Can't you have a AWS lambda run on a timer, for example?

Yea, you can. It's just not as simple. In addition, lambdas have time limits so many longer running cron jobs won't work. How about web sockets? Simple queue? Simple cache?

There are many things that you can quickly and easily do with a server that you'd have to reach for 3rd party services to do with serverless. That adds complexity and cost.

This is why I advocate for servers when you're trying to build a product for the first time and serverless if you have a special need.

Re: XML is the future

#388

Earlier quoted context omitted.

A better comparison would perhaps be “ansible” vs “puppet” vs “chef”. I wrote everything in shell, then puppet, then chef, then ansible. Doing literally the same thing. Because fads.

Taking this comment in good faith, because HN... Do you really not see any difference between Ansible and a shell script? Even just the move between shell and bash/csh/tcsh/zsh whatever else can make a marked difference in productivity and ergonomics.

Context: I wrote deploy and configurations in Shell in 1999, for Employer A. I started writing Ansible in 2013, for Employer F.

In the middle I wrote puppet and chef. All doing basically the same stuff. And yes, obviously there's worlds of differences. Using Puppet killed my productivity, for example.

But my point was that those tools are more comparible than 'terraform' vs 'ansible'. I stand by that comment.

Re: XML is the future

#389
post #7

I've been working in the tech industry in the US for about 5 years. Ever since I knew myself I've been coding. From middle school to high school, given any problem, like Sudoku, or keeping up daily chores, my solution was Programming! Programming wasy homebase. Then I studied it in uni, thought I was kinda good at it, and loved it. But when I started working in the industry, I realized that it's absolutely exhausting…

I am in the exact opposite,but equally frustrating boat. In last 5 years, I have worked at 2 Faang and a large hedge fund and everywhere they had extremely outdated stack or undocumented in-house stack or outdated undocumented in-house stack. Already derecated dependencies were pinned years ago and management won't let you modernize anything since there "no business value in it" and we need to ship a feature instead…

Congratulations. It sounds as if you are working for a company that knows what it is doing. They are clearly focusing on customer value instead of chasing the latest shiny new but buggy and gone tomorrow “new” tech. Giving you an opportunity to focus on delivering value to customers in a stable environment. Making each delivery higher quality and less buggy than the previous.

I work in such an environment and routinely deliver million+ line applications with ZERO bugs in production to very large customers around the world. Highly satisfying.

Re: XML is the future

#390

Earlier quoted context omitted.

I am in the exact opposite,but equally frustrating boat. In last 5 years, I have worked at 2 Faang and a large hedge fund and everywhere they had extremely outdated stack or undocumented in-house stack or outdated undocumented in-house stack. Already derecated dependencies were pinned years ago and management won't let you modernize anything since there "no business value in it" and we need to ship a feature instead…

really surprised faang management doesn't see the value in addressing technical debt.

Rewriting an application will usually simply give you a more buggy app with less features and more technical dept. At a high cost.

Smart businesses and developers instead step-by-step refactor and upgrade their existing apps.

Post reply on HN