juvix VS codeql

Heliax | Multiple roles | REMOTE (+-2 hours from CEST ideal) | Full Time | https://heliax.dev/jobs#all-jobs

Heliax is a public goods lab which was built on years of pioneering experience across distributed systems, programming language theory, and zero-knowledge cryptography. All our work is open-source. Examples of some of our projects are Namada (https://github.com/anoma/namada), a sovereign proof-of-stake blockchain; Juvix (https://github.com/anoma/juvix), an experimental programming language; and Taiga (https://github.com/anoma/taiga), a framework for generalized shielded state transitions.

We are currently actively hiring for a number of positions, most notably Senior Rust Engineers, Senior Full Stack Engineers, and a Protocol Security Lead.

For the Senior Rust Engineer position, we are looking for experienced Rust developers that are interested in applying novel research to create high-quality open-source technology and solve outstanding problems in the blockchain space. You'll be working on distributed ledger technology implemented in Rust, all the way up and down the stack from the P2P layer to consensus algorithms, smart contract systems, proof-of-stake incentive mechanisms, privacy-enhancing cryptographic components, and on-chain governance procedures.

For the Senior Full Stack Engineer position, we are looking for either web developers with experience using TypeScript and other modern web frameworks or software developers who have experience with Rust. Some representative examples of features you’ll be working on in this role are: adding support for Ledger hardware wallet connectivity, support for generation and use of file-based keys, generation of shielded transactions using cryptographic libraries, display of any digital asset (including NFTs) and associated transaction history, and on-chain management of staking and governance. It's a plus if you've previously worked with WebAssembly.

For the Protocol Security Lead, you'll be responsible for breaking protocols both in theory and practice in and outside the company, and assembling a team to help them do so. You'll receive a high degree of latitude and autonomy to prioritize tasks and search for the weakest links in complex systems in order to break them. The rough structure could be compared to Google Project Zero, but with a focus on cryptographic protocols & implementations instead of web technology writ large.

> What are the companies that do exciting stuff in compilers?

Some companies solve problems that have a larger component of parsing and evaluating things.

One example is Hasura's SQL-to-GraphQL layer: https://hasura.io/

Another example is GitHub's CodeQL: https://github.com/github/codeql

A third example -- I forget the name of the company -- parses Counter-Strike games real-time and restructures this data for better analytical introspection, e.g. for betting, time-scrollable replay, 2D rendering, etc. There appears to be a lot of hard-earned going from a stream of events monkey-patched over two decades, to a complete model of a game (who's on what team, who is dead, what round is this, etc.)

Microsoft does a lot of interesting compiler-related stuff, too, of course.

Then there's blockchain: A lot of programming-language enthusiasts have been employed to write VMs and DSLs to express safe application-level environments. An example is Anoma's Juvix: https://github.com/anoma/juvix

A job I was looking at involved building a more programmatic interface to some legacy SCADA systems, i.e. make old factory monitoring systems interoperate via a DSL. The idea, I think, is to transform and manage the configuration files from a dynamic GUI system.

tl;dr: If your main tool is a compiler, there are compiler problems everywhere.

I dont know how hard it would be to port it to other platforms. Different Virtual machine.

Tezos uses a human readable stack based language as a low level represenation that is suited for formal proofs: https://tezos.gitlab.io/008/michelson.html

If archetype depends on that then its going to be hard to port but i dont think it does.

Another interesting project in development is https://juvix.org/ which targets more backends beside michelson like llvm and wasm. Might run on eth2/Ewasm.

There are also blockchain specific features like: https://medium.com/tqtezos/tickets-on-tezos-part-1-a7cad8cc7...

Rust is very nice and might be a good fit for smart contracts tough i am not sure what you really gain over Haskell. In Tezos you have a more developed ecosystem and can code in Python, Ligo, Archetype, Haskell and in the future Juvix. You also have a human readable low level (assembly like) representation in Michelson that you can do optimizations and/or run formal proofs with Coq. Smart contracts are a very very special beast and i am somewhat sceptical about developing them in a general purpose language vs a domain/smart contract specific one in the long run (but i could be wrong here).

and in the future: https://juvix.org/ (This stuff is just ridiculously advanced)

Github: https://github.com/metastatedev/juvix

Best regards,

apologies if this should be a discussion/issue/whatever but:

Do you envision going up against CodeQL and/or <https://www.jetbrains.com/help/qodana/about-qodana.html> by making semantic information available to the ast nodes? OT1H, I can imagine it could be an overwhelming increase in project scope, but OTOH it could also truly lead to some stunning transformation patterns

e.g. https://github.com/github/codeql/blob/v1.27.0/java/ql/exampl... or even more "textual" semantics such as

  var foo = "hello".substring(1); // knowing "foo" is a String

While not trivial because it is not documented, you can create your a database with your own facts. Some of the extractors that create the required files are open source https://github.com/github/codeql/blob/main/ruby/extractor/sr...

Efforts: Dependabot, CodeQL, Coverity, facebook's Infer tool, etc

> But why not for instance use a build system in some "container"?

I am not sure how this helps.

> I think the project could "bother" contributors with something like that, couldn't it?

Which project?

> An embedded C developer I've talked with quite often on some other forum, who imho is quite competent, said that Coverity is a poor tool that generates way too much false negatives and overlooks at the same time glaring issues.

He likely violated a license agreement with Coverity, since no one is allowed to say anything comparing Coverity to anything else.

> Said that's mostly an issue with all OpenSource tools for static C analysis.

I have been filing bug reports.

> OTOH the commercial ones are very expensive usually, with a target market of critical things like aviation of safety systems in cars and military use, places where they spend billions on projects. Nothing there for the average company, and especially not for (frankly often underfunded) OpenSource projects.

So you understand my pain.

> CodeQL? It's mostly an semantic search and replace tool, as I know? Is it that helpful? (I had a look, but the projects I'm working on don't require it. One would just use the IDE. No need for super large-scale refactorings, across projects, in our case).

I have never heard about this function. It is a static analyzer whose checks are written in the CodeQL language. However, it is very immature. When github acquired it, they banished the less reliable checks to the extended-and-security suite, leaving it only with about ~50 checks for C/C++ code. Those catch very little, although in the rare instances that they do catch things, the catches are somewhat amazing. Unfortunately, at least one of those checks provides technically correct, yet difficult to understand, explanations of the problem, so most developers would dismiss its reports as false positives despite it being correct:

https://github.com/github/codeql/issues/11744

There are probably more issues like that, but I have yet to see and report them.

> SonarCloud, hmm… This one I've used (around web development though). But am not a fan of. It bundles other "scanner" tools, with varying quality and utility. At least what they had for the languages I've actively used it was mostly about "style issues". And when it showed real errors, the IDE would do the same… (The question then is how this could be committed in the first place. But OK, some people just don't care. For them you need additional checks like SonarCloud I guess.)

It is supposed to be able to integrate into github's code scanning feature, so any newly detected issues are reported in the PR that generated them. Anyway, it is something that I am considering. I wanted to use it much sooner, but it required authorization to make changes to github on my behalf, which made me cautious about the manner in which I try it. It is basically at the bottom of my todo list right now.

> Wouldn't it be easy to add at least this to the build by using some "build container"?

I do not understand your question. To use it, we need a few things:

1. To be able to show any newly introduced defect reports in the PR that generated them shortly after it was filed.

2. To be able to scan the kernel modules since right now, it cannot due to a bad interaction between the build system and how compiler interposition is done. As of a few days ago, I have a bunch of hacks locally that enable kernel module scans, but this needs more work.

> Well, that's why I think something equivalent to `-Wall -Werror` should be switched on before writing the first line of code, in any language.

OpenZFS has had that in place for more than a decade. I do not know precisely when it was first used (although I could look if anyone is particularly interested), but my guess is 2008 when ZFSOnLinux started. Perhaps it was done at Sun before then, but both events predate me. I became involved in 2012 and it is amazing to think that I am now considered one of the early OpenZFS contributors.

Interestingly, the earliest commits in the OpenZFS repository referencing static analysis are from 2009 (with the oldest commit being from 2008 when ZFSOnLinux started). Those commits are ports of changes from OpenSolaris based on defect reports made by Coverity. There would be no more commits mentioning static analysis until 2014 when I wrote patches fixing things reported by Clang's static analyzer. Coverity was (re)introduced in 2016.

As far as the current OpenZFS repository is concerned, knowledge of static analysis died with OpenSolaris and we lost an entire form of QA until we rediscovered it during attempts to improve QA years later.

> But I guess I will stay with engraving my data into solid rock. Proven for at least hundred thousand years.

That method is no longer reliable due to acid rain. You would need to bury it in a tomb to protect it from acid rain. That has the pesky problem of the pointers being lost over time.

> At least someone needs to preserve the cat pictures and meme of our current human era for the cockroach people of the distant future. I'm not sure they will have a compatible Linux kernel and compiler available to build the ZFS drivers, or even punch card readers…

Github's code vault found a solution for that:

https://github.com/github/archive-program/blob/master/GUIDE....

I vaguely recall another effort trying to include the needed hardware in time capsules, but I could be misremembering.

Exceptions would be systems like CodeQL, but that's a bit out of scope for a game like WoW.