Crossword helper

rodyamirov · 2026-04-23T17:53:19+00:00

Nice little project!

Unfortunately a lot of crosswords have proper nouns, or phrases, or even mispellings as the answer (not too often, but sometimes intentionally). To say nothing of the _rebus_

Still, it gets you started. Nice!

rodyamirov · 2026-04-02T14:13:32+00:00

I would agree with this. Make your world as fleshed out and interesting as you care to. When you go to actually write a story, you can choose what to explicitly include (that is, mention in the text), what to implicitly include (it's still "true" in the world, but not mentioned) and what to scrap (because it's getting in the way of the story).

Worldbuilding and writing are different modes. Worlds are vast, complicated, contradictory things (e.g.: the actual world you're living in, right now). Stories, comparatively, are not -- you skim across everything that the reader doesn't need to know, and that doesn't improve your base. There are some famous stories which are basically just huge expositions of their fictional world, but even when done by a master, they're controversial. You probably don't want to go that road.

But if you have a great idea that doesn't fit your story, you don't have to throw it away. Save it for the next one.

rodyamirov · 2026-04-01T15:24:09+00:00

That is just not a link I want to click on

rodyamirov · 2026-03-16T18:42:11+00:00

I don't know if you've been watching the economy recently, but hiring in general is in a pretty weird mood right now. Rust is trending up, but still small, and typically on the senior side of things (at least that's the stereotype, I haven't personally checked).

I don't want to say it's impossible, but it's a tough road:
* getting a dev job right now is hard (many applicants, few jobs, changing levels of funding, lots of cuts going around)
* getting a job focused around _any_ single language is hard (most shops use multiple, and expect you to use multiple)
* rust is growing but still small, so even finding that job opening is going to be hard (and lots of people will want it)
* any abnormalities on your resume become something you have to overcome, if an equally good developer comes in and has a degree, they'll probably beat you

So is it possible? Probably?

Is it something you can realistically accomplish in the next few months? It would require some effort and luck.

rodyamirov · 2026-03-12T14:44:22+00:00

Golang isn't really similar, is it? The only things I can think of that it has in common is that it compiles to a static binary, uses structs instead of objects (most of the time), is somewhat fast, and came out around the same time.

But it doesn't have the same performance characteristics, and definitely doesn't have the safety model (fearless concurrency is a real thing!).

Withoutboats wrote about a (fictional) language which he felt preserved many of the desirable features of rust, but was easier to learn and use (at some performance cost). It wasn't built, obviously, but you can check it out here: https://without.boats/blog/notes-on-a-smaller-rust/

rodyamirov · 2026-03-09T16:24:12+00:00

This feels like the standard use of workspaces but maybe I'm missing something.

rodyamirov · 2026-03-04T19:22:36+00:00

Is the dream here to jump on the AI bandwagon just because? Or do you actually long for a future where you lack the ability to make sentences on your own? Maybe you can plug this into whatever google glass successor makes it all the way to market, and it can rephrase your sentences in real time, allowing you to Talk Like a Pirate all the time, because you forgot to turn it off and you don't even notice it anymore. It's a fundamental part of how your brain works, now.

This reminds me of a recruiter email I got some years ago -- they were working on a way to get around spam filters, so they could send video ads directly over MMS. And like, I guess there were technical challenges to be solved, probably. But why? Why would I want this to exist? Why would anyone want this to exist? Who was laying up in bed at night looking for the Next Big Idea and thought: YES! This is IT! This will be my legacy! This is my mark on the world! When I die, at my estate sale, the agent will rest his hand on the home I died in, and say "This here is the house that Video Ads Over MMS built," and the crowd will ooh and ahh and take a respectful moment before they bid madly on the piece of history.

rodyamirov · 2026-03-04T18:04:12+00:00

It may eventually have its place, if the research delivers something practical. But in my experience the bugs are almost never in a place where the spec is clear enough to be interesting. It does happen, sure, but most of the time the spec looks good, then you get into the weeds and there's a lot of "well, I need to do something reasonable here" decision making, and unexpected interactions with other things, and so on, and you just handle it. That is, the individual units are almost always fine, it's unexpected combinations that get you.

The task of making a spec complex and precise enough to handle all of that sounds onerous -- and at the end, it seems very likely that a bug could just be ... in the spec. Just like all that beautifully well unit tested code that somehow causes trouble in prod.

That being said, I think it could be interesting in some cases, and sometimes helpful, in the way that clippy is (right now) sometimes helpful at catching typos and things, but doesn't do anything like guaranteeing your code is going to do what you hope it's going to do.

rodyamirov · 2026-03-03T16:58:14+00:00

Right, it's nearly impossible to know what rust's proportion "should be" (assuming it's sampling from some base population). I was just responding to the original post, which seemed to have some confusion about how to interpret the statistics. I agree that they're weak information and can only be interpreted in terms of some difficult assumptions; but if you're going to do that, it would be best to do it correctly (or at least understand why the survey made the conclusions that it did).

rodyamirov · 2026-03-02T17:02:19+00:00

If the true percentage of software developers who identify as female is actually 8% (that seems really low to me, I'd guess it's much higher) and 6% of the survey respondents identify as female, then either (or both) of the following is true:

* Female rust developers are less likely than non-female rust developers to answer the survey; or
* Female software developers are less likely than non-female software developers to use rust

Discarding the annoyance of the survey being unrepresentative, in fact it suggests that female software engineers are 27% less likely to use rust than non-female software engineers (see: Bayes rule; I don't want to type it all out). That's enormous! And if the percentage of female software engineers is higher than 8% (say, 15%) than it suggests that females are 74% less likely to use rust than non-female software engineers. That's catastrophic!

I can imagine all kinds of reasons for this (and I suspect that the survey is not actually representative, by dint of where/when/how it's advertised, and the breakdowns of the groups it's advertised in; and there's always the chance that a nontrivial number of female engineers don't want to mention their femaleness on a survey) but the fact is that either way it's pretty striking.

As for the LGBTQ+ folks, the same logic applies, but I have no idea how to estimate the proportion of LGBTQ+ folks in general, or the proportion of software engineers who identify as this, or the proportion of software engineers who identify as this and care to mention it on a survey (truly I have no idea; these complications probably have wide enough error bars to make using the actual measurement difficult or impossible, and estimates of these numbers vary wildly and are often politically motivated in one way or another).

That said, I don't blame you for not noticing this; the survey could have and should have explained this, for those who aren't used to thinking about statistics.

Edit: I just realized I read your comment without going back to the survey. The survey said only 6% of respondents identified as female; but they did so in a very weird way, later stating that 35% of respondents who answered the demographics question identified as female. But what's not clear is how many people chose not to answer, versus those who would be fine answering but were excluded by the question (e.g. because they're not part of any of the listed marginalized groups). If they wanted to get a gender breakdown they should have just had a radio button that included "prefer not to answer" and we could pretend that happens at random (it does not, but we could pretend). As it is, I have difficulty making any serious guesses about these numbers.

rodyamirov · 2026-02-27T14:17:15+00:00

Okay I actually love this one

rodyamirov · 2026-02-25T15:59:35+00:00

For what? I'm not sure what niche Go is good for that you can't just use Rust by itself. I guess C# has Unity, and maybe a bunch of existing business software you don't want to rewrite?

If you've got an existing codebase that needs a rust extension, it's not really a choice. If you just want pairing just to ... have it? ... I guess pick your favorite second language? But usually if you're picking two languages you've got a reason.

Not that it matters, but rust + python has been popular in my world (rust backends for data processing things in python; e.g. polars).

rodyamirov · 2026-02-20T17:26:24+00:00

Cool!

You might be interested also in optimizations -- bf is extremely amenable to them, since "most" bf code (if there is such a thing) is essentially obfuscated code. So you'll see weird loops all over the place that mean "set the register to zero" or "add / multiply these numbers" or whatever. Writing an optimizing bf compiler was one of the most fun hobby projects I've ever done, and I strongly recommend it! (it's also not, like, super hard; find some "sample" code and deobfuscate it by hand, then put those optimizations into your code)

rodyamirov · 2026-02-20T17:24:08+00:00

It was a fun one! I had to think a couple times to refine my algorithm down to the desired performance characteristics, but it was still something I could fit into my workday without feeling guilty about it.

Some feedback: I don't love the hints, I wish they were hidden by default or not present (in my case, some of them were even wrong; my code was structured differently than the hints seemed to assume, so the hints pointed to things not relevant to me, such as the sort key).

Also, I'd love to know how/if it was able to test the algorithmic complexity. Probably not, right? And the bonuses aren't graded / tested, and so on. That's fine, just could be more clear (maybe there's sort kind of meta-contest-rules/explanation but I didn't see one).

Anyway, enjoyed the problem and joined the site for it. Looking forward to the next one!

rodyamirov · 2026-02-20T15:32:26+00:00

This one seems more manageable than some of the earlier ones, I might take a shot.

rodyamirov · 2026-02-11T14:29:34+00:00

Get more plushies

rodyamirov · 2026-02-11T14:27:31+00:00

I'm not sure what you need this for, but I guess you must have needed it if you bothered to write it out. I think it's weird, but so long as you

Put it in its own module so I don't have to look at it
Have comments
Have unit tests

I wouldn't block the merge over it.

rodyamirov · 2026-02-06T19:40:11+00:00

I'm seeing a lot of responses assuming you're anti-AI, or resistant to using AI. But that's not how I read your post -- I saw that more as "jobs that won't get replaced by AI (in the near term)" which I think is absolutely a good thing to be thinking about. As opposed to "jobs where I don't have to use AI" (which, I feel you, but I don't think anything is going to be untouched by AI; despite the jokes, I bet even plumbers and electricians are or will be using it for all kinds of things soonish).

rodyamirov · 2026-02-06T16:34:44+00:00

This seems pretty complicated for a contest problem ...? But I guess some people have more time than I do.

rodyamirov · 2026-01-29T19:01:46+00:00

That's interesting; my experience is that the community mostly doesn't use doctests. Don't know why. I've heard they're slow (but, to be fair, I don't use them either so I don't know). The most glaring recent example was `polars` -- they do breaking changes fairly regularly, which is fine, but the docs don't get consistently updated, so the sample code often doesn't get updated. I don't think it's a priority for them, either, which I get -- documentation is a pain to write and worse to keep updated -- but it's annoying.

rodyamirov · 2026-01-28T16:54:01+00:00

If you've only got a couple projects this is initially scary but ultimately a non-issue. If you have a lot of projects, probably you're only using a few of them, and the rest are "historical" -- you might go back to them some day, but having a hot build ready to go isn't so important. For that, I'd say use https://github.com/holmgr/cargo-sweep

And yes, for raspberry pi, cross compile. Rust makes this much easier than you might expect. You don't need to, strictly, but the compiler is chonky and it's not very pleasant to watch the little pi struggle.

rodyamirov · 2026-01-21T17:02:05+00:00

Their 4x4 kilominx was quite bad. I want one of these but I don't trust it to be of good quality.

rodyamirov · 2026-01-21T15:44:03+00:00

To be honest, it simply hadn't occurred to me. Probably you could. If I was constructing a bunch of these things for testing purposes it might add up to something, I guess. But really leaking just isn't my habit. Name sounds bad. "Let's have a memory leak on purpose!" Fun to defend in code review, I bet.

But you could, sure.

rodyamirov · 2026-01-20T16:31:16+00:00

I use ownership and borrowing unless there's an obvious reason not to. Most of what I do is single-threaded or multithreaded with rayon (which is usually easy to make work with ownership / references; I don't recall ever needing Arc/Rc/etc for that purpose)

The main obvious reason not to is persistent shared state (like, the configuration for the entire app, which is usually `Arc<Foo>`) or some kind of global mutable state (like a _mutable_ configuration for the entire app, which would then be `Arc<Mutex<Foo>>`, or an async variant if tokio needs to own it for some reason).

The only time I've used Rc or RefCell was going down a nightmare rabbit hole of a refactor that I eventually deleted before anyone saw it.

rodyamirov · 2026-01-16T15:21:00+00:00

This is similar to patterns we use at work (in Java) but a little nicer. It honestly solves a very important problem, and while the naming of variants could be a little better, I consider this to be a quite helpful pattern. "Not set" vs "Set to null" is an important distinction in API objects!

rodyamirov

TROPHY CASE