CodeBrad (u/CodeBrad)

CodeBrad commented on Go’s race detector has a mutex blind spot doublefree.dev/go-race-mu... · Posted by u/GarethX

jimbo808 · a month ago

My guess is that next the language gen will be languages that AI generates, which are optimized to be readable to humans and writable by AI. Maybe even two layers, one layer that is optimized for human skimming, and another layer that actually compiles, which is optimized for AI to generate and for the computer to compile.

CodeBrad · a month ago

> which are optimized to be readable to humans and writable by AI

How might a language optimized for AI look different than a language optimized for humans?

CodeBrad commented on Go’s race detector has a mutex blind spot doublefree.dev/go-race-mu... · Posted by u/GarethX

klabb3 · a month ago

> Rewrite your code in rust, and get something better than the go race detector every time you compile.

Congrats, rustc forced you to wrap all your types in Arc<Mutex<_>>, and you no longer have data races. As a gift, you will get logical race conditions instead, that are even more difficult to detect, while being equally difficult to reproduce reliably in unit tests and patch.

Don’t get me wrong, Rust has done a ton for safety and pushed other languages to do better. I love probably 50% of Rust. But Rust doesn’t protect against logical races, lovelocks, deadlocks, and so on.

To write concurrent programs that have the same standards of testable, composable, expressive etc as we are expecting with sequential programs is really really difficult. Either we need new languages, frameworks or (best case) design- and architectural patterns that are easy to apply. As far as I’m concerned large scale general purpose concurrent software development is an unsolved problem.

CodeBrad · a month ago

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

CodeBrad commented on Claude Code weekly rate limits · Posted by u/thebestmoshe

Jcampuzano2 · a month ago

My opinion is all of these tools should completely get rid of the "pay 20/month, 200/month", etc just to get access to some beholden rate limited amount that becomes hard to track.

Mask off completely and just make it completely usage based for everyone. You could do something for trial users like first 20 (pick your number here) requests are free if you really need to in order to get people on board. Or you could do tiered pricing like first 20 free, next 200 for X rate, next 200 for X*1.25 rate, and then for really high usage users charge the full cost to make up for their extreme patterns. With this they can still subsidize for the people who stay lower on usage rates for market share. Of course you can replace 200 requests with just token usage if that makes sense but I'm sure they can do the math to make it work with request limits if they work hard enough.

Offer better than open-router pricing and that keeps people in your system instead of reaching for 3rd party tools.

If your tool is that good, even with usage based it will get users. The issue is all the providers are both subsidizing users to get market share, but also trying to prohibit bad actors and the most egregious usage patterns. The only way this 100% becomes a non-issue is usage based for everything with no entry fee.

But this also hurts some who pay a subscription but DONT use enough to account for the usage based fees. So some sales people probably don't like that option either. It also makes it easier for people to shop around instead of feeling stuck for a month or two since most people don't want multiple subs at once.

CodeBrad · a month ago

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.

CodeBrad commented on Solving Advent of Code at compile time with Rust macros doublefree.bearblog.dev/s... · Posted by u/todsacerdoti

MeetingsBrowser · 8 months ago

Is this really what Rust macros look like?

CodeBrad · 8 months ago

It is! Although they are being used in a really weird and not normal way here.

I found "The Little Book of Rust Macros"[1] to be a really good resource for getting started with Rust's declarative macros.

[1]: https://veykril.github.io/tlborm/

CodeBrad commented on Solving Advent of Code at compile time with Rust macros doublefree.bearblog.dev/s... · Posted by u/todsacerdoti

weebull · 8 months ago

It's full of stupid comments. E.g. the python implementation has this attached.

```py """Warning: This code completes in a shocking O(n log n) time complexity and allocates memory with reckless abandon""" ```

How shocking that sorting is an O(n log n) algorithm.

Edit: he then goes on to use bubble sort.

I think there might be a large amount of tounge in cheek with this blog post, but it doesn't really land.

CodeBrad · 8 months ago

Technically, because the bubble sort is implemented at compile time the program is infinitely faster.

The answer is produced as a compiler error and so there is zero runtime at all.

CodeBrad commented on Solving Advent of Code at compile time with Rust macros doublefree.bearblog.dev/s... · Posted by u/todsacerdoti

cinntaile · 8 months ago

> Not only is the python solution barely legible

The article then proceeds to produce barely legible code, but it's in Rust instead! I would leave out own-goals like this, it detracts from the content.

CodeBrad · 8 months ago

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.

CodeBrad commented on Apple’s keynote event shot on iPhone and edited on Mac apple.com/newsroom/2023/1... · Posted by u/ayoreis

kemayo · 2 years ago

Expanding slightly on this, the cheapest Red Camera costs $6k (and I think might not include a lens?), so that's a pretty big savings.

CodeBrad · 2 years ago

Is it though? How much does all the associated gear, operators, actors, sets, producers cost? In the context of professional video production, a one time savings of $6k seems pretty small.

CodeBrad commented on Common mistakes in salary negotiation interviewing.io/blog/sabo... · Posted by u/eamonnm

victor9000 · 2 years ago

It sounds like a great way to miss out on talent that can command a salary higher than the average, while simultaneously attracting talent for whom this is a good deal.

CodeBrad · 2 years ago

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.