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

371–380 of 408 posts

Re: XML is the future

#371

Post by pradn »

yread wrote: post #125
preommr wrote: 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…

I still can't believe that we (as a profession) kinda traded away schemas, namespaces, comments, sanity and well defined dates basically because some kids were too cool to write out closing tags. My early 20s teammate now closes blocks with } //for in his JS. That's even worse than XML!

Maybe we need a Kotlin for XML. I mean a JSON-like, simple syntax without some of the verbosity of XML.

Re: XML is the future

#372

Post by edejong »

jerf wrote: post #309
edejong wrote: post #290

Earlier quoted context omitted.

CPU/Memory: scale horizontally when needed. Monitor cost. Disk: essentially limitless. If disk of VM runs out, node will crash, new node will start. Service should keep running on other nodes meanwhile. If restarts happen too often, throughput/error rate will suffer or cost will rise. Modern mentality is "let it crash" [0]. Software has bugs. Design so it can crash and scale depending on need. [0] https://medium.com/…

Letting an Erlang process crash is letting a process holding a small collection of resources, maybe a single TCP connection and several kilobytes of local state. It does not necessarily scale beyond that. Pretty much by definition, if you've got something that can run out of disk, when it runs out of disk and you nuke it, you're taking out a lot more than a single connection and a few kilobytes of state. And "let it…

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

Re: XML is the future

#373

Post by wizofaus »

edejong wrote: post #290
steveBK123 wrote: post #269

Earlier quoted context omitted.

As a "not a cloud guy" who only recently got heavily exposed to it.. I found the state of the art / CloudOps attitudes towards monitoring astonishingly Stone Age. Yeah observability is great, but no one I've seen in cloud manages to launch with it. So in place of SRE org with full observability stack, they launch with effectively nothing. Strong attitudes of "we don't measure hardware metrics like cpu/memory/disk, we…

CPU/Memory: scale horizontally when needed. Monitor cost. Disk: essentially limitless. If disk of VM runs out, node will crash, new node will start. Service should keep running on other nodes meanwhile. If restarts happen too often, throughput/error rate will suffer or cost will rise. Modern mentality is "let it crash" [0]. Software has bugs. Design so it can crash and scale depending on need. [0] https://medium.com/…

How is that better than a simple monitor/alert for low disk space? That low disk space is likely caused by having an application store too much cumulative data in log files or temporary caches etc. and often easy enough to fix. And many applications out there simply don't need the level of scalability and extra-robustness you need that you can still expect decent levels of service in the immediate aftermath of having one node go down. Certainly from my experience it's less work (and cost) to put measures in place to minimise the chances of a fatal crash than it is to ensure the whole environment functions smoothly even if parts of it do crash regularly. I'd also note we can be grateful that the developers of OSes, web servers, VMs and database servers don't subscribe to "let it crash"!

Re: XML is the future

#374

Post by wizofaus »

pdimitar wrote: post #360
edejong wrote: post #290

Earlier quoted context omitted.

CPU/Memory: scale horizontally when needed. Monitor cost. Disk: essentially limitless. If disk of VM runs out, node will crash, new node will start. Service should keep running on other nodes meanwhile. If restarts happen too often, throughput/error rate will suffer or cost will rise. Modern mentality is "let it crash" [0]. Software has bugs. Design so it can crash and scale depending on need. [0] https://medium.com/…

It looks like you misunderstood the article. "Let it crash" in the BEAM VM world pertains to a single green thread / fiber (confusingly called "process" in Erlang). It pertains to e.g. single database connection, single HTTP request etc. If something crashes there your APM reports it and Erlang's unique runtime continues unfazed. It's a property of the BEAM VM that no other runtime possesses. "Let it crash" is in fac…

Is that so different to how Java+Tomcat or .NET+IIS work? A crash handling one request generally can't/doesn't affect the ability to handle other requests. Unfortunately it does often mean you have limited control over how the end-user perceives that one failed request.

Re: XML is the future

#375

Post by edejong »

pdimitar wrote: post #360
edejong wrote: post #290

Earlier quoted context omitted.

CPU/Memory: scale horizontally when needed. Monitor cost. Disk: essentially limitless. If disk of VM runs out, node will crash, new node will start. Service should keep running on other nodes meanwhile. If restarts happen too often, throughput/error rate will suffer or cost will rise. Modern mentality is "let it crash" [0]. Software has bugs. Design so it can crash and scale depending on need. [0] https://medium.com/…

It looks like you misunderstood the article. "Let it crash" in the BEAM VM world pertains to a single green thread / fiber (confusingly called "process" in Erlang). It pertains to e.g. single database connection, single HTTP request etc. If something crashes there your APM reports it and Erlang's unique runtime continues unfazed. It's a property of the BEAM VM that no other runtime possesses. "Let it crash" is in fac…

I understood the article just fine. The "Let It Crash" philosophy is scale invariant.

Please read the last three paragraphs in [0]: "a well-designed application is a hierarchy of supervisor and worker processes" and "It handles what makes sense, and allows itself to terminate with an error ("crash") in other cases."

I've personally designed and co-implemented mission critical real-time logistics systems which dealt with tens of thousands of events per second, with hundreds of different microservices deployed on a cluster of 14 heavy nodes. Highly complex logic. At first we were baby-sitting the system, until it became resilient by itself. Stuff crashed all the time. Functional logic was still intact. Then we had true silence for months on our pager alerts.

I call it anti-fragile and Taleb is right. You can't make a system resilient if you don't allow it to fail.

[0] https://wiki.c2.com/?LetItCrash

Re: XML is the future

#376

Post by flagrant_taco »

vbezhenar wrote: post #356
flagrant_taco wrote: post #267

Earlier quoted context omitted.

JSON itself doesn't have support for scheme of comments as far as I'm aware. Both are supported by individual rolls building on top of JSON rather than those features being part of the JSON spec. Whether that stiffener matters to someone is up them, but that difference is what many comments on this thread are pointing out with regards to us having spent a decade rebuild many features of XML back into JSON.

XML does not have support for schemas either. XML Schemas is a separate spec (and actually not the only one, there were few competing ones). I'd use JSON schema over XML schema any day. And I read and wrote many XML schemas and still do sometimes. JSON schema actually built by sane people. If that required a decade, so be it.

Oh that's interesting, I always thought schema names pacing was a part of the XML spec, learned something new!

Re: XML is the future

#377

Post by pdimitar »

wizofaus wrote: post #374
pdimitar wrote: post #360

Earlier quoted context omitted.

It looks like you misunderstood the article. "Let it crash" in the BEAM VM world pertains to a single green thread / fiber (confusingly called "process" in Erlang). It pertains to e.g. single database connection, single HTTP request etc. If something crashes there your APM reports it and Erlang's unique runtime continues unfazed. It's a property of the BEAM VM that no other runtime possesses. "Let it crash" is in fac…

Is that so different to how Java+Tomcat or .NET+IIS work? A crash handling one request generally can't/doesn't affect the ability to handle other requests. Unfortunately it does often mean you have limited control over how the end-user perceives that one failed request.

It is only the same when you observe the visible results and your APM, and nowhere else. The stacks you mention -- and many others -- engage much more system resources per request compared to the BEAM VM. I have personally achieved 5000 req/s on a 160 EUR refurbished laptop with a Celeron J CPU, a pretty anemic one you know, in my local network -- by bombarding an Elixir/Phoenix web app; Elixir steps on Erlang if you did not know -- and that's without even trying to use cache.

RE: error handling, Elixir apps I coded and maintained never had a problem. Everything was 100% transparent which is another huge plus.

In general CGI and PHP had the right idea from the start but the actual implementations were (maybe still are? no idea) subpar.

Erlang's runtime is of course nowhere near what you will get with Rust and very careful programming with the tokio async runtime, but it's the best out there in the land of the dynamic languages. I've tried 10+ languages which is of course not technically exhaustive but I was finally satisfied with making super parallel _and_ resilient workloads when I tried Elixir.

For a lot of tasks I can just code in the Elixir REPL and crank out a solution in an hour, including copy-pasting from the REPL and into an actual program with tests. Same task in Rust took me a week, just saying (though I am still not a senior in Rust; that's absolutely a factor as well) and about 3/4 of a day in Golang.

The only other small-friction no-BS language and ecosystem that came kinda close for me is Golang. I like that one a lot but you have to be very careful when you do true parallelism or you have to reach for a good number of libraries to avoid several sadly very common footguns.

Re: XML is the future

#378

Post by xdennis »

commandlinefan wrote: post #311
edejong wrote: post #179

Earlier quoted context omitted.

In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, a DB that wasn't backed up and major data consistency problems. Also, when your box's hdd crashed, you lost all those minor changes you had vim'ed over the years. But for the rest, yeah, all is fine.

I think the takeaway here is: programming is hard, and we deserve more money.

The sad part is that much of what makes programming hard is the fault of programmers (primarily the endless churn, but others too).

Re: XML is the future

#379

Post by xdennis »

rerdavies wrote: post #365
firecall wrote: post #328

Earlier quoted context omitted.

April 2022 was the last maintenance release. Out of curiosity, why is it discouraged? I’m not really in the React world, but have been fixing up a Create React App for a client recently, so learned a bit more about it.

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

Re: XML is the future

#380

Post by jerf »

edejong wrote: post #372
jerf wrote: post #309

Earlier quoted context omitted.

Letting an Erlang process crash is letting a process holding a small collection of resources, maybe a single TCP connection and several kilobytes of local state. It does not necessarily scale beyond that. Pretty much by definition, if you've got something that can run out of disk, when it runs out of disk and you nuke it, you're taking out a lot more than a single connection and a few kilobytes of state. And "let it…

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 often phrase it as "it gives me monotonic forward progress" but "it gives me antifragility" is a reasonably close spin on it too)... but that's not unique to Erlang nor does Erlang have anything special to help with it as everything Erlang has for robustness is focused at run time. You can have anti-fragile development processes with any language. (The fact that I successfully left Erlang for another language entirely is also testament to that. I had to replace Erlang's robustness but I didn't have to replace its anti-fragility, since it didn't have it particularly.)

Post reply on HN