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.
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.
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.
> 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.
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.
I like how the comments in Devin's HN thread were all bleak and full of doom.
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.
Well, Google does exist.
For the overwhelming majority of internet users, it'll be their primary means of stumbling onto a website. And the pool of discoverable websites has been shrinking for years now.
A tiny fraction of internet users will bother with alternate means of finding websites apart from ads, Google search, or sponsorships.
Assuming those requests are evenly distributed over time, yes.
But in the event of an attack you would see a sudden surge in requests followed by a flatline, and still end up at 1B/month over 30 days.
Even though I don't share the same excitement about darklang,
I love it when people are psyched about the projects they pour their lives into.
I skimmed through the post, and it was fun to read.
Though to be fair, the human players had to rely on muscle memory to win lanes (CSing, blocking waves, pulling, trading hits, cutting waves, stacking, etc.); whereas the AI could perfect the timings down to the fraction of a millisecond.
No search engine is immune to LLM generated mumbo jumbo. Google makes an exceptional example at being a terrible search eninge despite majority market share, but as AI continues to pollute the internet, all search engines will deteriorate.
This cannot be done on most premises because of power, noise, and cooling.