Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XML is the future

bitecode.dev

Post reply on HN
Print view View original

391–400 of 408 posts

Re: XML is the future

#391

Post by hardwaresofton »

28304283409234 wrote: post #388
hardwaresofton wrote: post #192

Earlier quoted context omitted.

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.

thanks for responding -- I do agree that ansible, puppet, and salt are the closer comparisons (they are of the same lineage -- I mentioned them in passing and kind of clumped them together).

See my response here[0] as well, but to summarize:

- There is more overlap than it seems on the surface (not implying that you are taking a surface view)

- I wanted to get across was the way someone might ask if they were new/looked at it all as churn from the outside. The average dev who thinks "devops churns too fast" is not necessarily going to know the difference between ansible and terraform to begin with, never mind knowing that ansible/salt/puppet/chef are a different approach/lineage compared to terraform.

> And yes, obviously there's worlds of differences. Using Puppet killed my productivity, for example.

I never used Puppet -- it was love at first sight with Ansible for me, felt like the perfect amount of abstraction/structure even though some of the patterns were long in the tooth.

My career is not as long as yours, but I still use ansible to this day (with pulumi).

[0]: https://news.ycombinator.com/item?id=36476215

Re: XML is the future

#392

Post by alphager »

fragmede wrote: post #167
alphager wrote: post #145

Earlier quoted context omitted.

I think "XML" is way too broad to meaningful discuss anything. XML the data format is pretty great in its basic form. Not space-efficient, but unless you're dealing with bulk data, the inefficiencies don't matter unless you're googlescale or can't spare a millisecond. The format itself doesn't absolve you from the design work of your model; your ssn example is typical of the "CEO said we have to use XML now" rush-job…

> The insistence of the JSON-people to sabotage any kind of data validation is absurd to me. I don't understand what you mean by this. JSON supports schemas which can be used to validate input. It's not super advanced, but it's functional.

The JSON people were adamant about discouraging what https://json-schema.org/ ended up being. There's a reason JSON.org never linked to it (even back when they had a full screen of links at the bottom of their page: https://web.archive.org/web/20180727095653/http://www.json.o... )

Re: XML is the future

#393

Post by otabdeveloper4 »

edejong wrote: post #292
otabdeveloper4 wrote: post #280

Earlier quoted context omitted.

Not really. A "container" is usually just an instance of a Linux distribution, and the work involved in updating it is roughly the same.

In the 27 minutes after you wrote your comment, our CI/CD rebuild two containers from a latest snapshot. No manual work involved.

Good for you, some people can do automatic unattended OS updates too.

There's no benefit to using containers here, only more pain.

Re: XML is the future

#394

Post by namaria »

manvillej wrote: post #367
DarkCrusader2 wrote: post #245

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…

In both of your cases, I think there is this massive disconnect in decision making. Software development is a constant game of economic decision making. Which investment returns the greatest value. Agile worked because it spread risk and allowed for reaction to new opportunities. CICD/devops worked because it drastically reduced the risk & expense of defects, the cost of development, time to market, etc. But the chas…

If the way people allocate resources makes no sense, you are likely missing information on the returns they're getting from it.

Re: XML is the future

#395

Post by namaria »

jerf wrote: post #380
edejong wrote: post #372

Earlier quoted context omitted.

Let it crash is anti-fragile. Either you understand that, or you try to make super robust and super expensive applications.

Using Taleb's nomenclature, let it crash is not anti-fragile at run time. Erlang does not get progressively better at holding your code together the longer it crashes. It is only resilient and robust. Which is ahead of a lot of environments, but that's all. Many software development processes considered as a whole are anti-fragile... mine certainly is, which is a great deal of why I love automated testing so much (I…

Anti fragility is just a fancy name for 'ability to learn'. Erlang error handling philosophy enables learning by keeping thing simple and transparent. It's easy to see some component keeps failing, it doesn't bring your whole app down and you can look into it and improve it. Adding tonnes of third party machinery may be robust or even resilient, but if it makes things more opaque or demands bigger teams of deeper specialists, it precludes learning. Thus is not 'anti fragile'. You can keep your ability to learn healthy without Erlang, and you can use it without learning much over time.

It's not the tool, it's how you use it.

Re: XML is the future

#396

Post by robertlagrant »

senttoschool wrote: post #387
robertlagrant wrote: post #221

Earlier quoted context omitted.

> 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 f…

That's true. On queues, websockets, etc, it might be worth checking out Cloudflare workers durable objects[0]. I've never had to use them, but I wish I had the chance, as they look like a really interesting building block.

[0] https://developers.cloudflare.com/workers/learning/using-dur...

Re: XML is the future

#397

Post by cyanydeez »

gnulinux wrote: 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…

My man's ear never heard of corporate growth culture

Re: XML is the future

#398

Post by pdimitar »

oblio wrote: post #383
pdimitar wrote: post #358

Earlier quoted context omitted.

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.

I would, when it comes to parallelism. Java being stuck at OS threads (I know about Loom but it's nowhere near the BEAM VM or goroutines) is not doing it any favors.

PHP at least attempted some isolation between requests (emphasis on attempted) even though it didn't do it very well.

All that being said, people don't like seeing their favorite tech called out and the kneejerk down arrow presses are expected. Programmers are a tribal bunch.

Personally I've found my productivity multiplied with the above-mentioned more modern tech: Elixir, Rust and Golang. But I am also aware many companies would never risk it, and that there is no shortage of people who are OK coasting on old stacks if it pays the bills. Not judging.

Re: XML is the future

#399

Post by datavirtue »

throwuwu wrote: post #308
fifticon wrote: post #300

Earlier quoted context omitted.

news flash: You are working in exactly the same place.. it is just 5 years later :-) All that outdated technology you mention, was probably introduced as the newest-cant-live-without at some earlier time.

So how old does the tech need to be?

PHP old

Re: XML is the future

#400

Post by datavirtue »

manvillej wrote: post #367
DarkCrusader2 wrote: post #245

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…

In both of your cases, I think there is this massive disconnect in decision making. Software development is a constant game of economic decision making. Which investment returns the greatest value. Agile worked because it spread risk and allowed for reaction to new opportunities. CICD/devops worked because it drastically reduced the risk & expense of defects, the cost of development, time to market, etc. But the chas…

"Agile worked"

Citation needed.

Post reply on HN