

mlua looks nice. It also does async for coroutines, which is really nice.
Mama told me not to come.
She said, that ain’t the way to have fun.
mlua looks nice. It also does async for coroutines, which is really nice.
There are a ton of options, depending on what you have. In essence, a file server is really simple, you just need a computer with network access with sufficient storage. Here are options, from simplest to fanciest:
The costs can vary from free to thousands of dollars, depending on storage and compute needs and how far down the fancy scale you go (note: 3 is more expensive than 4, and comparable to 5).
Everything is running and I’m not making many changes because work got hectic. I have a few projects I’d like to tackle once I get time:
Here are my reasons:
I certainly want more competition to Steam, but that competition needs to do something other than exist for me to use it. GOG is that, and if they properly supported Linux, they’d get most of my gaming money. But they don’t, so they only get some of it.
Yeah, this probably reads like a Linux fanboy post or something, but I’ve been using Linux longer than Steam supported it with its client, and I’ll still be here if Steam leaves. It’s my platform of choice, and a vendor needs to meet me here if they want my business. Valve did, so they get my money. I honestly don’t need much, I just need games to work properly on my system.
a way to track them
Yes, that’s what I’m suggesting. Injecting some kind of metadata that gets stripped at code gen time would probably work.
worse incremental compilation performance
Would it really be that significant?
without allocating everything on the heap
I’m talking about compile time.
Start with all of the known safe cases (basic types should be fine), then move on to more dubious options (anything that supports iteration). Then allow iterable types but don’t allow iterating over a mutable reference. And so on. If it’s a priority to loosen up the rules without sacrificing safety, surely some solutions could be found to improve ergonomics.
Or perhaps there could be some annotations to make a reference as “unsafe” or similar instead of just a block. If something is safe in practice but not verifiably safe, there should be a way to communicate that.
You want some annotations to break out of the safe subset of the language
The annotations would indicate that something unsafe is going on, so it’s like an unsafe block, but on a reference. That way it’s clear that it’s not being checked by the borrow checker, but the rest of the application can be checked.
I really liked the idea of an optional, built-in GC w/ pre-1.0 Rust where specific references could be GC’d. If that were a thing in modern Rust (and the GC would only be enabled if there’s a GC’d reference included), we could get a lot more ergonomics around things like linked lists.
I take it the 192.168.1 subnet is the family lan?
I guess. Our use case was a bit different in that it carried which features they had access to, not just that they had some access. You could probably do that with a JWT as well, but we just issued them an encrypted upgrade file that matched the serial of their device and granted all usersln that device access to the feature.
That was simple enough for us.
OP wants to build a game. When I build games, I start high level (Python, Lua, GDScript, etc), then move the slow, stable bits to something faster. That’s a really effective flow, and at the end, I get a great scripting interface for my game.
But then, given the complaints, I’m not actually sure they do want to build a game, I think they really want to build a language, and maybe an engine.
My guess, from top to bottom:
I think all three are great.
the orphan rule is not worse than what other languages allow
Sure, but that doesn’t mean it can’t be better.
Surely the compiler could delay optimizations until the entire project is built, no? Then it knows what implementations exist, and the developer could then decide how to deal with that. Perhaps the dev could decorate the trait impl as overriding all others, overriding one specific impl, etc.
The orphan rule feels like throwing the baby out with the bathwater.
You can still trivially violate memory safety without multithreading or concurrency
Sure, and ideally those cases would be accounted for, or at the very least the dev could annotate each use to turn the borrow checker off for each instance, and that could print something at build time and a linter could flag over it. Unsafe blocks aren’t feasible for everything here.
A lot of these situations are fine in practice. Give devs the ability to sidestep the rules and take responsibility for the outcome.
My brother is an accountant and uses sheets for a lot of non-work stuff, and specialized software for most business needs. He also uses Excel, sure, but there are substitutes for Excel in a lot of cases.
The twin towers made a ton of sense:
Ackshually Linux is a kernel.
If you take “Linux” broadly, you could piece together a business management stack.
Microsoft 365 Business Premium
It’s pretty convenient for an IT team to use a standard image with all their configs and whatnot, and that requires a new key.
Except second hand. That’s my point.
I’m not Brazilian, but I’m guessing importing stuff is expensive. Look at PC components elsewhere in the world, it’s typically much more expensive than the US.
Here’s my investment portfolio:
I think US stocks will take a beating during Trump’s presidency, provided he keeps messing with tariffs, but I think longer term the US will bounce back because we have a very attractive regulatory environment for businesses.
Second hand markets exist and Raspberry Pis are rarely sold second hand.
Agreed, it’s just nice to know that going in to a massive article like this. Are these reasonable complaints, or are they just justifying a new project for themselves?