At this point, wouldn’t it be cheaper to buy a GPU and burn the electricity yourself? At least you can do a closed water cooling loop and limit the impact to 1-2 KW off the grid. Sure you lose Claude, and that’ll have a huge impact, but I don’t personally know anyone who can afford that much usage just to play around with some LLMs.
By default, doesn’t tsc just output the source TS files with type info stripped? Worst case you run a formatter on that output and you’re done.
There’s some nonstandard TS features like the iterator shim and decorators and such, but you don’t get those by default from what I remember.
Is a database handle you can write to not … basically mutable state, the arch-nemesis of functional languages?
Access to an external database is a kind of effect. In functional terms, you’d use a monad to represent this, though in Koka you’d define an effect for it. In either case, it becomes part of the function signature.
A “pure” function could instead work around it by returning (without executing) a query, accepting a state and returning a new, modified state, or otherwise returning some kind of commands to the caller without directly querying the database.
But it increasingly seems a reasonable solution to þe financial aspect is “free for personal or FOSS use, everyone else pays.” Which isn’t quite GPL, but I’m sure þere’s a license for it.
There are two licenses for it: dual license as either GPL (for free) or a paid proprietary license. Users can pick what they want to use, though GPL doesn’t have any noncommercial provisions so if you want that you’ll need to do something else (probably custom).
This puts far too much control on the LLMs. A LLM can provide suggestions for a PR, but those suggestions are not a sufficient replacement for a real review.
If the rate of PRs is too high to review, the solution isn’t to sacrifice the reviews. It’s to ensure that the PRs are of sufficiently high quality that the reviews are quick. Small PRs are faster to review, and readable code is easier to review. Tests can validate correctness to the reviewer. Make the review process as easy as possible for a proper code review.
The hybrid approach seems to me like it’d be the most successful here. Generate your PR suggestions, and let the PR owner resolve them how they like. Then, do a proper review on the PR. Where I disagree with the author here is the reviewer shouldn’t review the suggestions and resolutions, but the final diff instead.
tsc
And now you’re back to pure JavaScript.
I took a peek out of curiosity and MoltHub… wow. Sorting is all done locally and only sorts skills that have been loaded onto the client, so scrolling down inserts skills into their sorted positions rather than at the bottom of the list. Scrolling down to the bottom of what’s been loaded (infinite scroll) can therefore insert stuff to the top of the list.
Also, from what it looks like, skills just execute arbitrary code on your machine. While I’m not surprised, considering one of the most popular skills (from what I can tell) is a Polymarket trader, I’m gonna nope out of that one.
or even go see a local sports event in person.
Usually doing this can also get you close to people, even if only spatially. Occasionally it does get you close to people figuratively, though. If there’s nobody in your life that you would want to get dinner with, then I’d recommend the sports event, or something similar to it anyway. You can always invite people you meet there to your next month’s fancy dinner.
Or, hear me out, and I know this is crazy, but you buy a cheap, used TCL for a couple hundred pounds. Then, with the money you’re saving every month, you get a nice dinner with someone you’re close to, or even go see a local sports event in person.
Ok, I don’t know what they cost in the UK, but they’re sub-$500 new here in the US for a decent size TV. You have to put up with the TCL bullshit, especially if it’s a Roku one, but you were probably getting a smart TV anyway, and they all have this bullshit.
On top of this not linking to anything, it takes a special kind of person to invest into something as volatile as crypto.
This does seem like an issue with the library you’re using. Your second solution, using RawValue, is likely what I would have gone with, bundled with a self-referential type (wrapping the Pin in another nicer-looking type though). This is assuming I want to pass around a 'static type with the partially-deserialized data. In fact, I’ve done something like this in the past to pass around raw log data next to that same data in a parsed format (where the parsed data borrows from the raw logs).
Alternatively, I’d have deferred the lifetime problem to someone else (library user for example) since the source data is probably provided at a higher level. This is how the libraries you’re using do it from what I can tell. They make the LT the user’s problem since the user will know what they want to do with the data.
If I had chosen to write this code in Go I never would have had to think about any of this and I expect it would have been fine.
Well the article is about zero-copy deserialization in Rust. If you just slap #[derive(Deserialize)] on a bunch of 'static types and let it copy the strings, then you don’t have this issue in Rust either.
Also, you’d be using Go, not Rust. That’s fine, but not really relevant when you want to do JSON deserialization in Rust, is it?
What a wild conclusion to come to.
Do you want to? Go for it.
Does your game crawl? Have you identified this code as the bottleneck? Are you certain that asm will give you a meaningful performance increase, and that your issue doesn’t lie with your approach to the problem? Sure, I guess. You said your game runs fine though, so this probably doesn’t apply.
Is your game fast already? If you don’t want to do it, don’t.
Writing asm by hand is almost always a waste of time. There are only a few times where it’s actually necessary, and unless you’re writing a bootloader and running your game on bare metal, I can’t imagine why it’d be necessary. But you know your code better than anyone else here, so you should know whether it’s needed or not more than any of us do.
To begin with, you’re apparently targeting the Z80, which I haven’t seen used for games in the wild… probably in my entire life? Maybe an arcade machine I played on once used it, but I can’t think of any other times. If your targets need custom assembly, then you should already know that. We don’t know your targets.
I don’t disagree that running random scripts off the internet is a bad idea, and I even made that clear. I was just pointing out that these specific scripts are verifiable entirely by the URL (which is just the raw GH file URL for the file in that repo).
I agree that signing the scripts would be a good idea though. I’m not sure how hard (or expensive) it is to do so though. If it’s anything like TLS certs, it’s probably just not worth it to them (though LE exists for TLS).
You shouldn’t trust random scripts off the internet of course, but…
You do realize these scripts all come from this GitHub repo, right? It’s possible to verify them all, unless I’m missing a script here I guess. Even the registry files are plain text and readable directly in GH.
Not a lawyer, but if this isn’t a clear case of duress, then nothing is. Nobody with a functioning brain would say that someone begging a service to stop publishing generated sexual imagery of them is doing so under anything other than duress. That claim would be equivalent to saying someone agreed to your TOS when they begged you to stop stabbing their mother on your service.
to be specific, when you refer to “that all” happening, you mean Biden signing the bill that banned TikTok in April 2024, I think?
Yes. Biden happened to be president, but any president would have signed that into law because of the support, and even if it hadn’t become law, we’d still be in this position. Trump wants to control the media. He’ll do it however he needs to.
your timeline is jumping around a bit here, because now you’re referring to “that period” and linking to a source from January 2025, the time of Trump’s inauguration.
The period in question went on for quite a while (a yearish if I remember correctly). Anyway, your comment doesn’t actually say anything to contradict my point of ByteDance spreading their cheeks for Trump.
this ban only passed because Democrats were bamboozled into supporting a proposal that has its roots in Republican “omg China scary” bullshit. I don’t know how to explain it any more clearly.
You don’t need to. The ban is irrelevant. Without the ban, we’d be in the same place, with Trump attacking all forms of media to gain control.
ahh yes, “criticizing Democrats is the same thing as supporting Republicans”, the free square on the bingo board.
You’re not criticizing lawmakers here. You’re criticizing the common person, the people actually affected by the purchase. What you’re doing is essentially victim blaming.
Your entire analogy is irrelevant. The people you’re criticizing are the people who reviewed the exterminator, not the exterminator.
The ban had bipartisan support, and even if that all never happened, you’d still be in the same situation. They would have sold off their US business anyway whether they were forced to or just got a big offer.
Keep in mind that TikTok also put out messages during that period practically deep throating Trump and sent it out to all their users. This was going to happen either way.
Ironically, a ban could have prevented this from happening entirely by making TikTok no longer relevant to the US. Not that banning it wouldn’t come with other issues as well, of course.
Maybe rather than blaming those in search of a solution, you could try blaming those who created the problem. Friendly fire doesn’t do a whole lot of good, but does support Trump, which I’m assuming isn’t your goal here.
Breaking down what async fn in trait does, it converts it to a fn method() -> impl Future<Output=T>, which breaks further down into fn method() -> Self::__MethodRet where the generated associated type implements Future.
This doesn’t work for dyn Trait because of the associated type (and the fact method() needs a dyn-safe self parameter).
Instead, your methods need to return dyn Future in some capacity since that return type doesn’t rely on associated types. That’s where async_trait comes in. Box<dyn Future<...>> is a dyn-safe boxed future, then it’s pinned because async usually generates a self-referential type, and you need to pin it anyway to .poll() the resulting future.
Edit: also, being pedantic, associated types are fine in dyn traits, but you need to specify the type for it (like dyn Blah<Foo=i32>. Even if you could name the return type from an async fn, it’d be different for every impl block, so that’s not realistic here.
The solution is project dependent but sometimes both are used. For example, on Azure, you can use a private network and managed identities to lock away the microservices. It depends on how much security you need/want.