Anthropic, the company that actually has much worse revenues and likely mislead the public? [1] That Anthropic? The same Anthropic that has taken billions of gulf state money where the countries are on the verge of divesting itself from the US or fear of potentially losing their refineries + oil fields for at least 50 years? That same Anthropic?
This house of cards is about to collapse and lot of "smart" devs are going to act shocked when the water recedes.
The same thing always happens: companies "adopt" open source then, unless you have monopoly, money problems eventually appear and leadership sees this lovely team with "bloated budget" in the bylines.
I hate it when people use commentary articles as fake sources for their points. It's even more aggravating when the "journalists" are making points that play to the ignorance and outrage of the reader, as they know those readers are the easiest to bait for clicks and mislead. For instance, how is Anthropic claiming that its total revenue since January 2025 as $5 billion contradict that its expected run-rate revenue for the year 2026 is $19 billion?
> Anthropic claiming that its total revenue since January 2025 as $5 billion contradict that its expected run-rate revenue for the year 2026 is $19 billion?
Isn’t the “exceeding $5BN” comment a lifetime revenue? … on $30BN (edit: previously said spent) raised (or something ridiculous.)
A lot of the commentary on the frontier model companies is based on how much money they’ve spent to the relatively small amount they’ve made in return, and the skepticism, especially given almost continuous reporting, that deploying AI in a variety of situations doesn’t seem to yield favorable business outcomes. OpenAI shifting to enterprise / coding type stuff this week seems, also, potentially informative. Is Gen AI actually useful for anything but code? Signs keep pointing to no… and even then, we’re in the early stages of figuring out how to build without destroying everything… something Amazon just recognized as possible with their recent shopping outage.
It also means the Bun team is no longer in control. Acquisition has a similar time frame and we've seen numerous projects chart a similar path to irrelevance.
Very good, actually. But you have to nudge them slightly. Tell them you prefer the modern version of the language, with gradual typing† and function signatures, and you'll get very good results. Perl interpreter comes standard on modern OSes and due to permissive licensing and impeccable backwards compatibility you can always assume you deal with very modern versions of Perl.
I write Perl scripts that are 10-100 lines of code, and at this size Perl is a Strictly Better Bash: better syntax, some type checking, better text support, and still effortless calls to external processes: essentially you put a command with arguments in backticks, and you get it's output. Ruby can do it too, but not all systems have it. Python is another obvious choice but calling external commands in it is annoying. I also use Perl for some one-liners as a better `sed` for text replacements.
† Perl nowadays have TypeScript-style type checking for function parameters. So, while the syntax is wild sometimes, the language is much better than it used to be.
Assuming every OS ships new Perl is a good way to lose a bet, since RHEL and CentOS are happy to hand you a system package from years ago.
All the gradual typing and signatures in the world do not matter when the interpreter on the target box is old enough to miss half of it, and then you are dragging in CPAN modules or juggling shebangs just to get the same script to run everywhere. Bash at least advertises its limits. Perl can look like a nicer shell tool right up until deployment turns into a version scavenger hunt.
What kind of context has you deploying into old systems that don't ship a recent perl? If that is a legacy requirement for whatever reason, then at least I'd use docker or podman to get a recent runtime. Or would you also write Python 2 or Php 7?
What are you using for parameter type checking? I switched to native function signatures, native try/catch and might look into the new class system soon, but I don't recall native type checking...
5 has this. There are modules that get you to function signatures and type constraints. It's all opt-in and, as was said, you have to nudge LLMs to use it, but they can and the results are indeed better.
What kind of performance impact does it have? Obviously it depends on the specific program, but let's say the worst case scenario, something like a recursive implementation of the factorial function.
Minor. Faster unpacking of @_, but it's not a huge win until you have a lot of arguments. The conventional Perl 5 interpreter has no JIT to leverage the benefits of stronger types, inline functions, unroll loops, etc. A factorial function has few arguments, so the unpack gain will be small to nothing.
reply