That's the basis for my critique of CSS. There were plenty of other layout systems extant at the time CSS was cooked up. How CSS could have delivered such an incomplete and broken scheme is beyond me. To this day, it sucks harder than GridBagLayout from AWT of the 90s (and that one sucks a quite bit).
> If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier.
I would look to the UCSD p-System as a precedent to the JVM. Both are byte-code interpreted VMs. Gosling used the p-system earlier in his career, prior to joining Sun.
mod_php was distributed w/ Apache httpd, so it was "already installed". mod_perl needed to be installed manually, so it posed immediate friction, if not a complete freeze-out, depending on the situ. I believe that was why PHP became popular.
Systems with mod_perl (or just Perl allowing normal CGI) installed, especially shared hosting was so common as to be the norm in the late 90s and early 00s.
I think instead the biggest reason PHP took off was it had far less deployment friction and better aesthetics than Perl did on machines where you didn't have admin access, basically ever shared web hosting ever.
Typically CGI scripts on shared hosting were limited to explicit cgi-bin directories that had +ExecCGI. At the same time hosts would often not enable mod_rewrite because it could get computationally expensive on hardware of the era.
This all meant that all your dynamic content had to live at some "/cgi-bin/" path. It could be difficult to have a main landing page be dynamic without an empty index HTML just having an HTTP-Refresh meta tag to your "/cgi-bin/" path.
Contrast with PHP which would be processed from any directory path and was its own built-in templating language. It was also usually included in the DirectoryIndex list so an index.php would act as a directory index leading to cleaner URLs.
In the era when deployment mean MPUT in an FTP client those small differences made a difference for people trying to make their first dynamic website and look "professional".
Perl CGI scripts were ubiquitously supported by shared hosts, but IIRC mod_perl was not unless you had some custom setup on a dedicated server. Also IIRC, mod_perl was just a lot more complicated to set up and use, while mod_php was dead simple.
Not sure what you mean by "primitive support". Java 22 added FFM (Foreign Function & Memory). It works w/ both on-heap & off-heap memory. It has an Arena interface.
That brings back some memories...when Frank Yellin and Sheng Liang (from Javasoft) visited our team at UW I think in 1996 or 1997, we mentioned that our bytecode verifier/failure injector was really fast because we were using arena allocation, which was only possible (at the time) because we did the project in C. If you are using non-pointer offsets, you totally can do arena allocation with a byte buffer. I still don't get how you can do it safely with high level objects even with the mechanism described above, but there are definitely lots of unsafe ways to do it.
I've often wondered if PostScript or PDF contained the roots of a very good config language. Perhaps it simply is (PDF docs at least) but nobody regards it as such.
My guess is the RPN nature would be a no-go for many people. Nevertheless: comments, dicts, arrays, good string syntax, numerics, binary data, etc. Maybe that makes it too complicated.
PostScript is not so bad as a programming language, and it has a binary format as well as a text format, although the limits of numbers and some other things can be too small for many applications. The syntax of TER is based on PostScript (although it is not actually compatible, for many reasons; for example, the syntax "1.0" does not denote a number in TER, but "+1.0" does).
I would find the product more compelling in a puck form factor (sans kbd). I can't imagine missing the extra key labels. That would make it significantly smaller, more robust, & less expensive.
I'd also prefer DisplayPort to HDMI, but that might have been chosen for cost, or for the home gaming / nostalgia play.
