injuly

Yes. You can either rent an entire blade, or purchase a dis-assembled box (majority share of the price will be GPU), and place it at a datacenter.

This cannot be done on most premises because of power, noise, and cooling.

Admirable effort :)

But in its current state I don't think it actually replaces any of CodeQL's use cases. The most straight forward way to do what CodeQL does today, would to be implement a flow analysis IR (say CFG+CallGraph) on top of tree-sitter.

Even the QL grammar itself can be in tree-sitter.

Flow analysis, especially propagation, is a hard problem to solve in the general case. IMO, the one tool that had the best, if language-specific, approach was Pyre – Facebook's type checker and static analyzer for Python.

Ah, I'd only know the title, "all your base are belong to us", haha.

Unfortunately, "JS tooling in JS" is a dead end.

Countless people before me have tried, and I myself have written and maintained a (proprietary) JS toolchain that has caused a some trouble with users over the years.

In the end, using a systems language is what I've settled on.

> Further, you double the dependencies

I'm acutely aware of this problem. Which is why if you look at Jam now, it has zero dependencies. Not even libc (which is mostly thanks to Zig).

The only "dependency" is a Unicode property detection library I wrote for Jam itself. And it is currently the fastest implementation for Unicode identifiers to exist. This simply isn't possible in JavaScript.

Same story with the Parser, etc. Parsers for JS already exist, but it's already known how far one can go, stitching together existing tools that aren't meant to work with each other.

Some dependencies can't be avoided in the long run, But I try to be very cautious, and vet every dependency thoroughly before considering it an option.

Ultimately, the dependence on two languages is a tradeoff that I've accepted, and the problem you mentioned with dev environments is one I'm going have to live with.

> For great justice? You know what you doing.

Not sure what to make of that. Can you elaborate?

> which is as performant than using mutable array.

I get what you're trying to say, but that is provably false. As great as the OCaml compiler is, it currently is not capable of the aggressive optimizations that GHC can do with lists.

More often than not, the compiler mostly won't have enough static assertions to reliably generate machine code like that in a real world application (unless explicit mutation is used, of course).

> Functional programmers just trust that their compiler will properly optimize their code.

Precisely. This is why having safe local mutation as a language level feature can give more control to the programmer. We no longer have to rely on the compiler to correctly guess whether a routine is better expressed as an array or a cons list.

> The whole article is secretly about Haskell.

and ML, Koka, Clean, Mercury. The article is about allowing local mutation without breaking referential transparency at the language level.

"Stop using haskell" is a very shallow conclusion, IMO.

> This is calculation is pretty pointless and the title is flat out wrong.

No, it's not. The author clearly states in the very first paragraph that this is the price it would take them to reproduce the results.

Nowhere in the article (or the title) have they implied that this is how much Google spent.

Well deserved. My top 3 Ted Chiang works:

1. The merchant at the alchemist's gate. 2. What's Expected of us 3. Exhalation

Qt licensing is its own mess. For commercial software, the pricing is 350-500$ per developer, per month. Seriously [1]. The company that now owns the framework doesn't seem to acknowledge the gap between big enterprises and solo developers/smaller teams.

[1] Yes, one can use Qt for commercial software without buying a license (as long as it is dynamically linked), but their marketing does everything it can to hide that fact. Also, the newer additions to Qt do not fall in this category – for those, you have to pay.

Interesting points. This isn't just about music, though. Udio can do standup skits too, and elevenlabs can already replace NPC dialogue voice actors in games and audiobook narrators. Smaller music producers who make intros for big youtubers, or sound designers who make tunes like notification sounds and SFX for video game screens are going to have their lives severely impacted by AI audio generators.