HN user

CodeBrad

60 karma

interested in program analysis, compilers, and programming languages.

Posts5
Comments22
View on HN

This was one of my favorite talks from RustConf this year! The distinction between cancel safety and cancel correctness is really helpful.

Glad to see it converted to a blog post. Talks are great, but blogs are much easier to share and reference.

I may be biased, as I definitely love more than 50% of Rust, but Go also does not protect against logical races, deadlocks, etc.

I have heard positive things about the loom crate[1] for detecting races in general, but I have not used it much myself.

But in general I agree, writing correct (and readable) concurrent and/or parallel programs is hard. No language has "solved" the problem completely.

[1] https://crates.io/crates/loom

I think Claude Code also already has the option to provide an API key directly for usage based pricing.

I'm a fan of having both a subscription and a usage based plan available. The subscription is effectively a built in spending limit. If I regularly hit it and need more value, I can switch to an API key for unlimited usage.

The downside is you are potentially paying for something you don't use, but that is the same for all subscription services.

Hey! I wrote this. The python being barely legible is my own fault, as the one who wrote it.

The whole post is written to be a little ridiculous, but I must not have gotten that across =(

I agree with you. In real life, python is absolutely a better choice than trying to write a Rust macro to produce the result as a compiler error.

I added a footnote to the end of the referenced paragraph to say that python is great.

You get what you pay for.

If there is a one off person who can command a higher salary, its unlikely they alone will make a huge difference to the company anyway.

If there are a lot of people who could command a higher salary in that role, the pay is too low.

Overall it seems like a pretty good system. You could argue that the current system favors people who are good at negotiating, and not necessarily more skilled workers.

I know not directly related to WebCrate, but it looks like the signup for DetaSpace is broken, so I am unable to try WebCrate.

When I try to sign up for DetaSpace, I get the following message:

Exceeded daily email limit for the operation or the account. If a higher limit is required, please configure your user pool to use your own Amazon SES configuration for sending email.

Lift uses machine learning to measure which bugs developers fix most, eliminating likely false positives, and continuously delivering higher quality results that improve over time.

Is this a pre-trained thing or something that is done custom per repository?

I agree, good code coverage can probably get most of the way there. But there are some problems with relying on coverage.

Coverage can be misleading. Maybe there is some function being executed in parallel:

  int global;
  void foo() {
    int local;
    
    if (complex_condition)
      bar(&local);
    else
      bar(&global);
  }
And assume maybe somewhere way down the call chain the data passed to bar is modified. The bar function and all of the functions called in bar can have 100% test coverage, but if the else branch is not covered, the race will be missed.

So without true 100% test coverage, it is possible races are being missed by dynamic tools, and true 100% test coverage is probably not possible or feasible in large complex projects.

In my opinion, the main limitation of TSan is that it cannot find all possible races. (An impossible task so I think TSan is a pretty great tool to get to the point that this is the main limitation)

As a dynamic tool, if a race is observed during execution by TSan, the race is very likely to be real. But it is impossible to "observe" execution for every part of a large code base, and so real races are likely still hiding in some edge case that TSan did not execute.

Static Analysis tools are interesting in that they have the opposite problem. Static tools can detect races across the entire code base, but without runtime information it is difficult to know if the races are real. This leads to more real races being detected, but also comes with more false positives.

There is a lot of interesting working being done on data race detection and how we can bring these two sides closer together to find more real races, without overwhelming developers with false positives.

Hello, my name is Brad and I am one member of a small team who have spent the last year building the Coderrect Scanner, a fast and accurate static analysis tool for detecting multi-threaded bugs. After a year of late nights and hard work we have reached a stable tool, and are proud to announce our GitHub action that allows the tool to be easily integrated into projects hosted on GitHub.

I'm happy to answer any questions.

I am in the US, and at my school masters and PhD students all take the same classes.

It is not ideal because many of the masters students are coming from a non-CS background. Some of the graduate level CS courses I have taken were easier than 4th year level undergrad classes.

C++ is becoming a real mess of features

I am now looking forward to learning Rust

Prepare yourself. I personally think one of the major downsides to learning Rust is how quickly the language is moving.

I first started looking into Rust in ~2015, but it seems most hobby projects from that time won't even compile today.

It feels like there are non-breaking changes to the language almost weekly. I still cannot figure out if I should be using nightly rust, stable rust, or switching back and forth depending on the project.

Overall I think Rust is doing a lot of great things, but I'm not sure it is handling the "mess of features" aspect of programming languages particularly well.