I find it a little embarrassing that a blog about a web framework fails to load (though perhaps that's a little unfair considering a HN traffic spike). Especially since I thought one of Yesods main advantages was performance.
For the lazy (pun intended) his Conclusions are:
- Java-the-language and Java-the-libraries make a number of simple tasks very complicated.
- Therefore, we have a number of helper languages, like XSLT and Ant, to avoid the pain of a pure Java solution.
- However, these tools are all purposely missing some features we'll inevitably need.
- The result will be either missing proper handling of some features, a polyglot that will miss the point of using Java in the first place, or most likely both.
- There are great use cases for non-general-purpose languages, but they should have tight integration with a real language.
- Haskell's flexible syntax and great typing make it very powerful here.
I just spent last weekend putting together a Yesod web app and am very sympathetic to his mantra. Hamlet is a lovely language (valid HTML is valid Hamlet so very easy to pick up) that does one thing well, one thing well, and nothing else. It very easily allows me to go back into Haskell if I need to. The key is that Hamlet is merely syntactic sugar. Ant isn't just syntactic sugar, its far more than that, which makes it different.
But given that Haskell is easy to parallelise (compared to Ruby or Java), and compiles to very fast object code to boot, it seems like it should be able to withstand HN traffic better than the average blog that gets featured here. Its a little embarrassing because yesodweb.com is the main Yesod website, not some amateur like me hacking stuff together.
Fair enough, I'm just assuming that even given the capability to parallelise, they probably just don't have the necessary amount of hardware provisioned to cope with HN-magnitude traffic spikes.
The site seems to be running on AWS, so you're probably right. It's loading very quickly now though so I imagine they've upgraded to a bigger instance.
The reason for Yesod's poor showing in that benchmark was due to a flaw in the implementation of the benchmark. A certain function (newSTDGen) was called repeatedly within each request, even though it should have only been called once; it's a relatively "expensive" function so this had a large impact on the results of the test.
In addition, the Yesod test used TCP sockets to communicate with MySQL while the other frameworks were set to use UNIX sockets. This has also been found to have a non-trivial impact on performance, as discussed in this SO thread:
>A certain function (newSTDGen) was called repeatedly within each request
It is called zero times in the json benchmark, which yesod still did quite poorly on. That is only a factor in the "pull a random thing from the DB" test. I believe the biggest underlying issue was that sessions are enabled, which means transmitting more data (the cookie) as well as doing encryption and HMAC on the cookies. Disabling sessions doubled the performance.
I'm glad I read it, because I never would have known about XProc otherwise, but a lot of his specific complaints are moot today. XProc apparently supports directory listing out of the box and there is now a zip module for it. In any case you could extend these tools with your own code if you wanted to continue to use them, they all offer extension points (mostly in Java, sadly, but a directory listing is just a directory listing).
His overall point is not moot but at the same time I'm not all that sympathetic. As you dig deeper and deeper into the XML ecosystem you learn that more and more of it is really only there so that there can be an XML answer for every problem. I doubt many people see the benefits of a comprehensive XML ecosystem (frankly, I doubt that the benefits are all that meaningful) but if you don't see the point then you're engaging in pointless masochism by trying to use it. That he solved his problems by going outside the XML ecosystem suggests that he doesn't really perceive the benefit of it, which makes the whole exercise a little circular. "I like sweets and I don't like vegetables, and I discovered that if I put sugar on my vegetables I like them better than if I don't." Yeah, that's what I'd expect you'd find.
I think the missing concept here is composability. Hamlet composes cleanly with Haskell, XSLT doesn't. Although it should be pointed out that Microsoft's XSLT implementation is more than capable of running arbitrary code.
I think this article is oh-so-close to making some great points. Using a DSL like XSLT for XML transformation is a lot more productive than in Java.
"Quite simply, each language is good for its specific task, but can't (easily) do anything else."
Correct, let XSLT do what XSLT does (transform XML), and fill in the rest with Java. I've been paying attention to XProc for a long time and seems to be good fit for what it does, (manage series of XML transformations).
"All I need to do is use that XSLT directory listing function... that function that doesn't exist."
Well, that's true. I'm surprised that somebody extolling the virtues of Haskell would miss this point, but XSLT is supposed to be a pure-functional language. You should't make side-effect/non-deterministic calls during a transformation. Furthermore, since he discovered the ability to write to multiple output documents in XSLT 2.0, I'm surprised that he didn't think of multiple input documents.
The answer here would be to use java to produce all of the necessary input before the xslt/xproc pipeline. Create a temporary DOM filled with just a directory listing, you can configure Saxon to select on arbitrary documents that you create, and do it all in memory. Xproc is meant to make transformations composable in case you don't explicitly know everything beforehand, like if there's dynamically generated file content that gets populated from earlier transformations, but I think it's less useful than XSLT.
"Contrast this with the DOM model from Java."
Well, an API discussion on Java/DOM is a different matter entirely.
"Ant and XSLT are not designed for modularity."
Yes, they are. They are modular with respect to their domain models.
If the point was "Well, a client mandated the use of Java, but it wasn't so bad because I was able to do everything in XSLT and XPROC", it would have been interesting. Furthermore, one might have said, "If XSLT was a DSL written as an embedded API in a friendly language with extensible syntax like haskell, ruby or scala, it would have cut out the middle man".
To claim, however, that languages that aren't general purpose are dangerous becuase, well, they aren't general, is bit of a stretch.
> The magic features that's missing here is sum types. There is no good replacement in Java, and it precisely the right tool to model nodes in XML. Added to that the requirement to use mutable data structures here and it's painful. And don't even get me started on the difference between a null string and an empty string in the API.
More like from w3c (http://www.w3.org/TR/DOM-Level-2-Core/), but yes, shipped with Java. This is like complaining about DOM traversal in JS. There are other libraries/interfaces one can use for traversing XML other than what is shipped with the lanugage.
Seems strange to compare languages based on nsomething in a core lib of one and not in a core lib of another.
For the lazy (pun intended) his Conclusions are:
- Java-the-language and Java-the-libraries make a number of simple tasks very complicated. - Therefore, we have a number of helper languages, like XSLT and Ant, to avoid the pain of a pure Java solution. - However, these tools are all purposely missing some features we'll inevitably need. - The result will be either missing proper handling of some features, a polyglot that will miss the point of using Java in the first place, or most likely both. - There are great use cases for non-general-purpose languages, but they should have tight integration with a real language. - Haskell's flexible syntax and great typing make it very powerful here.
I just spent last weekend putting together a Yesod web app and am very sympathetic to his mantra. Hamlet is a lovely language (valid HTML is valid Hamlet so very easy to pick up) that does one thing well, one thing well, and nothing else. It very easily allows me to go back into Haskell if I need to. The key is that Hamlet is merely syntactic sugar. Ant isn't just syntactic sugar, its far more than that, which makes it different.