For a direct replacement, you might want to consider enums, for something like
enum Strategy {
Foo,
Bar,
}
That’s going to be a lot more ergonomic than shuffling trait objects around, you can do stuff like:
fn execute(strategy: Strategy) {
match strategy {
Strategy::Foo => { ... }
Strategy::Bar => { ... }
}
If you have known set of strategy that isn’t extensible, enums are good. If you want the ability for third party code to add new strategies, the boxed trait object approach works. Consider also the simplest approach of just having functions like this:
fn execute_foo() { ... }
fn execute_bar() { ... }
Sometimes, Rust encourages not trying to be too clever, like having get
vs get_mut
and not trying to abstract over the mutability.
There’s a good chance there will be a virtuous cycle, where the Steam Deck’s popularity makes it easier to game on Linux for regular PC users too, which will help out everyone gaming on Linux. Especially as Microsoft keeps dicking around with Windows and trying to turn it into a subscription OS and people just get sick of it.
Kind of looks like an alternative universe where Rust really leaned into its initial Ruby influences. IMO the most interesting thing was kicked down the road, I’d like to see more of the plan for concurrency. Go’s concurrency (which it says they’re thinking of) kind of sucks for lots of things, like “do these tasks in parallel and give me the return values”. Go can do it with channels and all that, but Rayon’s par_iter()
just magically makes it all work nicely.
You should believe it as much as you want. I don’t have any inside knowledge myself, I just remembered an HN comment that was relevant to this post and linked it.
Apparently there’s an effort underway. I don’t have any more context than this:
https://news.ycombinator.com/item?id=38020117
I will say that I actually like the flat namespace, but don’t have a strong opinion
I’m too lazy to convert that by hand, but here’s what chatgpt converted that to for SQL, for the sake of discussion:
SELECT
a.id,
a.artist_name -- or whatever the name column is in the 'artists' table
FROM artists a
JOIN albums al ON a.id = al.artist_id
JOIN nominations n ON al.id = n.album_id -- assuming nominations are for albums
WHERE al.release_date BETWEEN '1990-01-01' AND '1999-12-31'
AND n.award = 'MTV' -- assuming there's a column that specifies the award name
AND n.won = FALSE
GROUP BY a.id, a.artist_name -- or whatever the name column is in the 'artists' table
ORDER BY COUNT(DISTINCT n.id) DESC, a.artist_name -- ordering by the number of nominations, then by artist name
LIMIT 10;
I like Django’s ORM just fine, but that SQL isn’t too bad (it’s also slightly different than your version though, but works fine as an example). I also like PyPika sometimes for building queries when I’m not using Django or SQLAlchemy, and here’s that version:
q = (
Query
.from_(artists)
.join(albums).on(artists.id == albums.artist_id)
.join(nominations).on(albums.id == nominations.album_id)
.select(artists.id, artists.artist_name) # assuming the column is named artist_name
.where(albums.release_date.between('1990-01-01', '1999-12-31'))
.where(nominations.award == 'MTV')
.where(nominations.won == False)
.groupby(artists.id, artists.artist_name)
.orderby(fn.Count(nominations.id).desc(), artists.artist_name)
.limit(10)
)
I think PyPika answers your concerns about
What if one method wants the result of that but only wants the artists’ names, but another one wanted additional or other fields?
It’s just regular Python code, same as the Django ORM.
I’m pretty excited about PRQL. If anything has a shot at replacing SQL, it’s something like this (taken from their FAQ):
PRQL is open. It’s not designed for a specific database. PRQL will always be fully open-source. There will never be a commercial product.
There’s a long road ahead of it to get serious about replacing SQL. Many places won’t touch it until there’s an ANSI standard and all that. But something built with those goals in mind actually might just do it.
I don’t think you really have a choice TBH. Trying to do something like that sounds like a world of pain, and a bunch of unidiomatic code. If you can’t actually support 4 to 10 languages, maybe you should cut back on which ones you support?
One interesting thing you could try if you really don’t want to cut back is to try having using an LLM to take your officially supported code and transliterate it to other languages. I haven’t tried it at this scale yet, but LLMs are generally pretty good at tasks like that. I suspect that would work better than whatever templating approach you’ve used before.
If neither of those approaches works, everything speaks C FFI, and Rust is a modern language that would work well for presenting a C FFI that the other languages can use. You’re probably not hot on the idea of rewriting your Go tests into another language, but I think that’s your only real option then.
Have you used either of them before and have opinions on them vs HA?
To do it 100% probably isn’t possible, something something halting problem. However, you’d catch a lot of basic mistakes with proper typing. In your example, the first function should be typed like this: fn third_planet_from_sun() -> Planet
, where Planet
is an enum. De/serializing it still has the same problem of interpreting an arbitrary string, but at least for deserializing it, you can be loose in what you allow and just lowercase it before matching it to the enum.
For mobile with fastmail, I use fairemail. Works great with it, and provides a nice merged view with my non-fastmail work emails.
That’s true, but also trying to create first has a race condition too. The above code will panic at the unwrap if the record is deleted after the failed insert, and before the select
This is likely what OP will have to do. It actually looks like ANSI SQL now has merge, but you can scroll down a bit and see how each DB handles it slightly differently if you don’t use merge.
Did anyone ever figure out exactly what happened with the mod team stepping down? Does this leadership change help address that?
It was made to do so, but failed from the start exactly because humans got involved. semver’s ideals can only happen when tooling generates the version number, not humans.
semver is a nice way to communicate your intent to other humans, but it’s never been a great way of programmatically communicating those changes. If you want it to communicate something meaningful programmatically, you’d have to have the version generated automatically, and not rely on a human to do so.
This site is specific to AWS, but you might find it helpful:
Looks like it got bought out by someone, so might be enshittified, but it’s worked nicely for me in the past.
What advantages does that have over this?
Security is a gradient that depends on your threat model, etc, but unless you’re being targeted by a nation-state or something that should be plenty secure
Not sure how ollama integration works in general, but these are two good libraries for RAG:
https://github.com/facebookresearch/faiss
https://pypi.org/project/chromadb/