@tk Oh interesting! I was looking into the history of rust resistant snapdragons a while back. Turns out first there was no snapdragon rust in Europe, then one strain of rust but in the middle of the 20th century there were cultivars of snapdragons entirely resistant to it. Then more strains emerged and no now snapdragons fully are resistant, despite some efforts over the years.
@martijnbraam I don't recall having seen this with Rust, though I saw stuff like that recently trying to build some Python code that depends on C or C++. Is it something like that?
@skinnylatte@hachyderm. Person: bad thing Adrianna: you did bad thing! Person: defensive Adrianna: no you did bad thing Person: unfair, only trying to help Adrianna: maybe stop being bad instead
> I want to write this software, what language should I use?
Use your favorite hammer. The hammer you are familiar with and feel comfortable with.
If you want to learn to use a new hammer or don't have a hammer, many will recommend theirs, all with good arguments!
It is rare there are constraints so your hammer doesn't work - your hammer may not run on a platform or not be fast enough, for instance. But mostly you will be fine using your hammer.
I just tried Typst fo for the first time. I used it for something small. It was easy to learn the very basics, and I used a things like simple tables and alignment and managed to figure it out!
The latest image generation models do a great job on faces. They still break down massively (additional finger or even limb) but faces are fine. They can't do different flower species well at all though.
People tend to look down on print debugging as it's not using sophisticated tools at all. You're not using debuggers or profilers or sophisticated loggers.
But don't look down on print debugging. It's the tool that works for all languages. It's easy to understand and easy to implement. It focuses the mind on thorough reading and understanding of code, rather than getting lost in a forest of data.
Print debugging is really effective in many cases.
I really love getting context myself. Though perhaps others might be impatient and want to get to the thing already. But the context is part of the thing.
When people say "X is a best practice" any context is at best implied.
> Whereas if you're using the best practice, it can't really be argued that you should have been using a different practice instead which would have prevented the thing from going wrong.
"Nobody ever got fired for using the best practice"?
If something goes wrong, and this can be solved or prevented, improvement is possible, isn't it?
In the first case labeling a practice "best" may prevent learning or change for the better.
For the second case, if there are trade-offs that depend on context, then you pick a practice that fits them to the best of your ability, and I see little value in labeling it "best".
You may have practices to follow as a requirement - say, for space hardware. One could call this a best practice.
Meta stuff leading to improved processes and people are indeed more likely to be generally applicable good practices. Like "get enough sleep" or "fix the system rather than individual".
But "do code review when an individual submits changes" is way dodgier already. So is "use microservices". And I am pretty sure many people consider both best practices.
Me grok write code. Rust, Typescript, Python, JavaScript. Created: Morepath, lxml, Xot. Also: gardener, science & history fan, living life fan. I post a lot about programming as well as gardening pictures. If you come for just the gardening pictures the programming talk may baffle you. If you're a programmer, I invite you to enjoy the flowers!