[hjek]

Indeed, and Arc has some brilliant ideas, but if you ever tried to hack in it, you'd experience how dog slow it really is. But Arc's web framework is implemented in somewhat low level MzScheme and is entirely different (and much slower) than web apps in Racket's[0].

Part of what makes Hacker News fast is that the page only has 4-ish images (if you count the invisible gif that is used for indentation) and a tiny amount of JS.

[0]: https://docs.racket-lang.org/continue/

[fiddlerwoaroof]

Yeah, but that's sort of the point: for most web applications, most performance issues are not the result of the implementation language but of the chosen architecture. If a fairly inefficient language like Arc can handle HN loads (for the most part, at least), almost anything can.

[hjek]

> for most web applications, most performance issues are not the result of the implementation language but of the chosen architecture.

I don't think that's true (but I also don't understand what is meant by architecture in this context).

There's a simple file upload form example in the Arc community repository. It's so slow that it would timeout on files smaller than 100K. I tried optimizing the POST request parsing, but could still only barely get Arc to handle file sizes of 5M.

Tried making a similar simple file upload form in Racket, and it runs way faster. But it shouldn't be surprising that some languages are less efficient than others, right?

I'm also not sure that most web applications are text-only. Many web applications send and receive other things that plaintext.

[pflanze]

> But it shouldn't be surprising that some languages are less efficient than others, right?

A long time ago I read a comment somewhere saying that Arc is interpreted (as in by a program itself written in MzScheme, instead of translated down to MzScheme), which struck me as odd but I didn't check back then, so now I finally went and looked through the Arc history[1] and release 0 already does the translation, so apparently that was just wrong. There can still be reasons why Arc could be slower, though, I remember PG's design called for overloading function calls so that e.g. hash table lookups could be written like function calls, and if implemented naively this could cost a slower than usual type check on each function call and prevent optimizations applied by the MzScheme/Racket compiler like perhaps function inlining. But just a different parsing infrastructure could explain it too (working on strings-as-vectors vs. lazy lists would make a large difference, but I couldn't get down far enough to see how that's implemented; srv.arc in parse-multipart-args uses regular expressions, not sure that's what you optimized?). Anyway, new code always has large potentials for optimization (early lisps were very slow, today's implementations are generally very fast; same was/is true for Java, JavaScript, ..).

[1] http://github.com/arclanguage/anarki