The site has performed more or less the same after the staff cuts as it did before. I say this as somebody who has used it nearly daily for ten-ish years now. Most users I know have the same experience. Maybe you noticed something if you're parked on Twitter for hours at a time, but I try to limit my exposure to people that do that.
I get that Musk is a dipshit and that there are other problems with the site since the change of ownership, but the griping about stability seems to come from people that don't actually use it.
It's becomming slower and slower over time. Feeds often don't load properly. Refresh only works properly manually since the feed often disconnects. Dragscroll (or whoever it is called when you press a button and you can scroll by dragging the mouse up/down) is broken and results in 100% cpu load and a stalled site until you cancel it. But these are just my annoyances, maybe it's just me. I'm switching it out for alternatives as much as possible anyway.
Hm? This is news to me. As far as I know, you can just publish pure javascript. I know that it's going to give you a worse 'score' if you don't have types, and it may require explicit typing of TS (but, strictly, so does TS), but I wasn't aware that there was not any way to publish to JSR without types. I'll have to look in to that, thanks!
Curious what the issue you were running into was? I’ve been using stow for my dotfiles for at least 8 years now and have been loving it the whole time.
Basically, the --dotfiles option was not working with directories so you had to have things that look like this: lazygit/.config/lazygit and now it looks like: lazygit/dot-config/lazygit.
Really a small issue that bugged me forever - shouldn't have made it seem like it was core a problem with stow!
Using the GNU stow utility makes this super easy. It even has a --dotfiles flag so you can author your dotfiles as dot-zshrc and when the utility symlinks it, it will be .zshrc. Makes it nice so your source files are not hidden but the actual dotfiles are (as expected).
Although GNU stow is very interesting, I like this simple script because it has no external dependencies. Stow is not available on macos by default, for example.
It is available though in every package manager for macOS except the App Store, and any user of a script like this on macOS is probably also using Homebrew, macports, Nix, or srcpkg.
You should check out mise (https://github.com/jdx/mise), it is very similar to ASDF (multi langs) but written in Rust instead of Bash, and doesnt use the shim technique that ASDF does. My shell startup went from a couple hundred ms to a couple dozen ms.
People so eager to defend Apple from "monopoly" that they completely ignore the point, which is equally valid when you are not a monopoly but have a extremely sturdy market penetration.
For your blog, jquery is totally fine and reasonable. Jquery for a web application? That is going to be way more of a headache. It all depends on what you’re trying to accomplish.
the list would merit its own dedicated blog post but to highlight a few nice parts, ecto lets me write sql code in elixir. it does not try to wrap it all into objects but I do get schemas. so for instance I can create a schema `Player` which maps to a table "players"
I can then get them via
```
from(p in Player)
|> where([p], p.id in ^player_ids)
|> select([p], p)
|> Repo.all()
```
need to join with an association?
```
from(p in Player)
|> join([p], s in assoc(p, :scores), as: :score)
|> where([p], p.id in ^player_ids)
|> preload([p, score: s], [score: s])
|> select([p], p)
|> Repo.all()
```
this gets me all players with their scores.
need to get the sum of scores for all players?
```
from(p in Player)
|> join([p], s in assoc(p, :scores), as: :score)
|> where([p], p.id in ^player_ids)
|> select([p], %{
player_id: p.id,
score: sum(score.value)
})
|> group_by([p, score: s], [p.id])
|> Repo.all()
```
as you can see, you can unwind this pretty fast to sql in your head. but you can also let the system just grab the kitchen sink when you jsut need to get somethign working fast. and its all very easy to modify and decuple.
this is hardly exhaustive though, I could spend a day talking about ecto. I spent 8 years developing in nodejs but now I work exclusively in elixir. unless what you're doing is 90% done by existing libraries, its juts a better tool for building highly performant backends.
This is probably great to use, but it also highlights in comparison the beautiful simplicity of SQL. Doing something simple is hard, and SQL is so simple that I think most people find little value to abstractions built on it.
Their migrations tool is proprietary and not open-source. The project is basically an open source bait and switch riding off the edge computing hype (since prisma and other major JS ORMs have poor support for edge environments).
There's One Weird Trick™ in managing joins in this case -- create views that implement the joins and then just treat it as yet another table. Bonus feature is creating a consistent way of working with that relation using native DB tools. ;-)
that works great till your database gets big. Then you will watch your memory use skyrocket to perform joins into that view and it will F@#$@# your shit up. eventually it will take so much time to construct your view table that you'll tiemout your connection pool.
to be clear, dont' use views in production queries. you WILL regret it.
