Glad to see it converted to a blog post. Talks are great, but blogs are much easier to share and reference.
60 karma · joined August 7, 2020
Glad to see it converted to a blog post. Talks are great, but blogs are much easier to share and reference.
How might a language optimized for AI look different than a language optimized for humans?
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.
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.
I found "The Little Book of Rust Macros"[1] to be a really good resource for getting started with Rust's declarative macros.
The answer is produced as a compiler error and so there is zero runtime at all.
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.
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.
- http://ai.
and http://.ai/ gets redirected to a search engine searchfor ".ai" by firefox.
But http://www.ai/ works for some reason.
My first semester teaching a lab I was told "No one is remembered for being a good TA" and encouraged to do the absolute bare minimum to get paid so that I could focus on research.
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.
What kind of things does lift do to ensure lower false positives?
Is this a pre-trained thing or something that is done custom per repository?
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.
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.
I'm happy to answer any questions.
Sounds great
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.
> 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.