However, it may work with the article's process - a 100x100 png with lots of 2GB-of-nothing iTXt chunks could be gzipped and served with `Content-Encoding: gzip` - so it would pass the "is a valid png" and "not pixel-huge image" checks but still require decompression in order to view it.
Is there a reason the malicious part of the payload has to be pixels? You could have a 100x100px image with 000s of 2GB iTXt chunks, no? That would bypass naive header checks that only reject based on canvas size.
As I understand it, that’s not _strictly_ true. 17% live in “rural” areas, but this includes towns and villages in rural areas. It’s 8% for “rural village and fringe” [0], or much less for actually outside of towns and villages. Unless you have other stats to share?
I'm always torn by these posts. I love perl's (well Moo's) class definitions - the simple, obvious way to make immutable objects combined with the `lazy` pattern fits really well with how I like to write code. But.
I have never quite got my head around the point of runtime constraints. If something passes bad data to a function, moo(se) throws an inscrutable error and I'm stuffed - there's no obvious way to recover, things just die. Static type checking tells you at compile time that you goofed, and then the system doesn't have to spend all that time checking every argument to every function every time it's called. PEP484, jsdoc + tsc & RBS show you can do this incrementally on existing code.
Huge amounts of existing perl code & libraries are not async-aware, so rewriting things to take into account concurrency is a huge undertaking. From Log4perl's global MDC through to pretty much every single file parser's blocking behaviour, there's so little code that can be reused from the perl5 oeuvre that I honestly think it's too late.
The fundamental issue here is that yes, all of these things could happen. We could assert that perl8 will be concurrent/async, have awesome runtime type checks etc etc. But why bother? Who is going to pay for it (aka spend time on it)?
The elephant in the room is that even if we did all this stuff - rewriting all the "core" libraries needed for a modern language to follow these awesome new paradigms (from json parsers, date libraries, web frameworks, database libraries - essentially, all of go's core libraries + a ton more), perl is still slow.
As hn discussed a few months ago, the author of mojolicious decided to try a JS version of mojolicious. His experience, like mine, was that even as a naive JS coder writing stupid schoolboy code, he saw a 5x+ speedup. Go is the same - a seasoned perl dev writing stupid, beginner go code results in >5x performance, and pretty much free concurrency.
It's almost embarrassing researching technologies these days. When was the last time you found something that provided perl support? We all know the hierarchy: Java, js, go, python, .net, rust. Then the next tiers: php, ruby, maybe scala, kotlin or swift. Maybe even the unexpected: dart, lua, OCaml. Perl? Maybe if someone on cpan wrote one. I honestly think the last first-party library I saw was mongodb, back around 2010 (the perl library is now officially EOL since 2018, obvs).
By all means write a new perl because you love it, but be honest with yourself in terms of what is achievable. No-one is going to spend the time/money/resource required to take the existing perl codebase and make it into a modern language that can compete with python, js, java, go or rust. And even then, what compelling/unique features can a "new" perl offer? Rust gained marketshare because it was safe with near-c performance. Go compiles & runs almost as fast as a dynamic language, compiles to a single binary, had an awesome core library, excellent performance and a compelling concurrency story. Nodejs had an critical mass of devs who already knew js from browsers, a bunch of highly-resourced companies competing to make it fast, and is getting better all the time (async/await, const/let etc etc).
I understand that people love languages, but sometimes we have to understand that perl is like Amiga (or blackberry, zune, or even scala (ooh, contentious)) - we can love a thing but understand that its time has been and gone. We can mourn what could have been, but there is no world in which Amiga will become a significant force again. Similarly, there is no world in which perl will gain significant marketshare again.
Not quite - that was his initial implementation which he described as "That’s not good at all, but I was trying to work within Perl’s limitations". The corinna syntax is
class Point {
field ( $x, $y ) :param = 0;
method clear () {
( $x, $y ) = ( 0, 0 );
}
}
It's because "volume limit" is fuzzy. It's more like cpu turbo boost - if you put a lot of frequency energy into the speakers they will overheat, but not instantly. Most vendors just say "In worst case (square wave) you can shove 2W continuous energy into the speakers and they'll probably be ok", but this is saying "you can spike more energy into the tweeters/woofers for a short time, but they'll heat up. Make sure they don't go over 140C. Oh, and by the way, my woofers and tweeters have these gains, so you can balance them properly rather than just guessing"
It has been interesting watching this develop, if for no other reason that Express is somewhat stuck after TJ left to make koa[0] and hasn't changed much since 2014. Express 5 has had no commits for 9 months - it's not dead, but it's not exactly thriving either. While there are alternatives to Express, none seem to have huge amounts of traction or do far more than a backend framework (nextjs, sveltekit), so maybe there is room for another framework.
I'll never forget seeing this tweet[1] - what I considered a core pillar of the perl community discovered that after a short period of familiarization, a perl developer of many years could write code that is many times faster just by switching from perl to js. No deep voodoo, no special tricks - just write code in JS and handle 3x as many reqs/s. I'm glad to see that the rest of the mojo ecosystem is coming along - Minion is a really nice, simple job queue that can piggyback on your existing postgres database without depending on redis or anything. Would be awesome to see a dynamodb backend someday. Hmmm.
Unfortunately I'm not sure who the target market is - a typescript web framework selling itself as "Perl-grade" anything is not a good look for 99% of JS/TS devs. Maybe it's positioning itself as the logical migration path for companies moving away from perl?
Yes, H2O is the strongest greenhouse gas, but its concentration (~5000ppm average) is limited by temperature and it will condense out as mist/clouds/rain. CO2 is nowhere near saturation levels, so atmospheric levels of CO2 have been growing. [2]
By all means you can tell the world that we should go back to a planet that looks like it did 15M years ago (miocene), but a 40m sea level increase is a pretty hard sell and IMHO does not match the "this is fine" tone of your post.
CO2 tends not to liquify but forms solid dry ice, so CO2 is not present in "liquid air" [3] (nor is anything with a boiling point <80K). Your proposed "obvious and dead simple" experiment is flawed.
"an engineer that has spent WAY too many years going down every single rabbit hole" is hard to justify based on the easily-debunked assertions you make, but even if you are correct and farming is the biggest cause and that it can/should bear the brunt of reduction efforts, it does not follow that we should therefore ignore all other avenues to address the problem. Yes, iron may be a part of the solution, but can you not see that building wind turbines, insulating houses and having electric cars is less risky than dumping huge quantities of iron in the sea?
Please consider that there _is no conspiracy_ and that scientists are mostly underpaid humans with a deep interest in their areas of study. Also consider that we know that fossil fuel companies have been funding AGW-denial. If you want conspiracies, try looking there.
However, it may work with the article's process - a 100x100 png with lots of 2GB-of-nothing iTXt chunks could be gzipped and served with `Content-Encoding: gzip` - so it would pass the "is a valid png" and "not pixel-huge image" checks but still require decompression in order to view it.