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.

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.

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

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.

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.

Comments URL: https://news.ycombinator.com/item?id=41106280

Points: 140

# Comments: 184

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

Comments URL: https://news.ycombinator.com/item?id=40440436

Points: 96

# Comments: 24

Comments URL: https://news.ycombinator.com/item?id=40386382

Points: 9

# Comments: 1

[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.

Comments URL: https://news.ycombinator.com/item?id=40129886

Points: 1

# Comments: 0

But now that it's a different industry AI is eating up, we're congratuling the team and sharing generated songs.

This looks like a fun tool, but when the smaller artists in Udio's training set recorded their albums, they didn't price in a capitalist company using their work to put them out of business.

A tiny fraction of internet users will bother with alternate means of finding websites apart from ads, Google search, or sponsorships.