injuly (u/injuly) - Readit News

injuly commented on Show HN: Globstar – Open-source static analysis toolkit · Posted by u/sanketsaurav

Nothing comes closer to CodeQL!

If anyone is interested please checkout, codepathfinder.dev, truly opensource CodeQL alternative.

Feedbacks are appreciated!

injuly · 6 months ago

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.

injuly commented on Show HN: Globstar – Open-source static analysis toolkit · Posted by u/sanketsaurav

etyp · 6 months ago

I really love that static analyzers are pushing in this direction! I loved writing Clippy lints and I think applying that "it's just code" with custom checks is a powerful idea. I worked on a static analysis product and the rules for that were horrible, I don't blame the customers for not really wanting to write them.

Is there a general way to apply/remove/act on taint in Go checkers? I may not be digging deeply enough but it seems like the example just uses some `unsafeVars` map that is made with a magic `isUserInputSource` method. It's hard for me to immediately tell what the capabilities there are, I bet I'm missing a bit.

injuly · 6 months ago

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.

injuly commented on Why am I writing a JavaScript toolchain in Zig? injuly.in/blog/announcing... · Posted by u/signa11

spiritplumber · 9 months ago

https://en.wikipedia.org/wiki/All_your_base_are_belong_to_us Ancient meme.

injuly · 9 months ago

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

injuly commented on Why am I writing a JavaScript toolchain in Zig? injuly.in/blog/announcing... · Posted by u/signa11

nox101 · 9 months ago

Personally I hate tooling for one language written in another. I hate python used to generate C++. I hate go used to generate C++ or JavaScript. Every added language adds more knowledge needed to contribute.

For every 1000 JS developers and every 1000 Zig developers there are 25 that know both. Only those developers can modify the system.

Further, you double the dependencies. JS pulls in library to do X that requires 50 dependencies, Zig pulls in a library to do X that requires 50 dependencies.

You also have 2 toolchains to maintain.

And you have 2 dev environments to maintain. Get all your editors/IDEs to understand both language. Get double your checkers, double your testing, etc etc.

You effectively increase the tech debt exponentially.

injuly · 9 months ago

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.

injuly commented on Why am I writing a JavaScript toolchain in Zig? injuly.in/blog/announcing... · Posted by u/signa11

spiritplumber · 9 months ago

Why are you writing a JavaScript toolchain in Zig?

For great justice? You know what you doing.

injuly · 9 months ago

> For great justice? You know what you doing.

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

injuly commented on Functional languages should be so much better at mutation than they are cohost.org/prophet/post/7... · Posted by u/injuly

RandomThoughts3 · a year ago

The article utterly falls apart in its first paragraph where it itself acknowledges that the whole ML family including Ocaml has perfect support for mutation, rightfully assume most Ocaml programmers would choose to not use it most of the time but then assume incorrectly that it’s because the language makes it somehow uneasy. It’s not. It’s just that mutation is very rarely optimal. Even the exemple given fails:

> For example, let's say you're iterating over some structure and collecting your results in a sequence. The most efficient data structure to use here would be a mutable dynamic array and in an imperative language that's what pretty much everyone would use.

Well, no, this is straight confusion between what’s expressed by the program and what’s compiled. The idiomatic code in Ocaml will end up generating machine code which is as performant than using mutable array.

The fact that most programming languages don’t give enough semantic information for their compiler to do a good job doesn’t mean it necessary has to be so. Functional programmers just trust that their compiler will properly optimize their code.

It gets fairly obvious when you realise that most Ocaml developers switch to using array when they want to benefit from unboxed floats.

The whole article is secretly about Haskell and fails to come to the obvious conclusion: Haskell choice of segregating mutations in special types and use monads was an interesting and fruitful research topic but ultimately proved to be a terrible choice when it comes to language design (my opinion obviously not some absolute truth but I think the many fairly convoluted tricks haskellers pull to somehow reintroduce mutations support it). The solution is simple: stop using Haskell.

injuly · a year ago

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

injuly commented on Calculating the cost of a Google DeepMind paper 152334H.github.io/blog/sc... · Posted by u/152334H

sigmoid10 · a year ago

This is calculation is pretty pointless and the title is flat out wrong. It also gets lost in finer details while totally missing the bigger picture. After all, the original paper written by people either working for Google or at Google. So you can safely assume they used Google resources. That means they wouldn't have used H100s, but Google TPUs. Since they design and own these TPUs, you can also safely assume that they don't pay whatever they charge end users for them. At the scale of Google, this basically amounts to the cost of houseing/electricity, and even that could be a tax write-off. You also can't directly assume that the on paper performance of something like an H100 will be the actual utilization you can achieve, so basing any estimate in terms of $/GPU-hour will be off by default.

That means Google payed way less than this amount and if you wanted to reproduce the paper yourself, you would potentially pay a lot more, depending on how many engineers you have in your team to squeeze every bit of performance per hour out of your cluster.

injuly · a year ago

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

injuly commented on Ted Chiang has won the PEN/Faulkner Foundation's short story prize lithub.com/ted-chiang-has... · Posted by u/bookofjoe

injuly · a year ago

Well deserved. My top 3 Ted Chiang works:

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