I'm not so sure. Both Go and Rust seem like examples of very popular ecosystems with a set of common, "blessed" tooling. (They didn't have everything from the get-go, e.g. rust-analyzer was very popular before it became part of the Rust project, but it still demonstrates that a large ecosystem can rally around a set of common tooling.)
That's a fair point, but I don't think it's really fair to say Gleam has everything necessary included when it's brand new. Because it currently doesn't suffer from the problems of the JS ecosystem doesn't mean it won't in the future.
(As another example besides rust-analyzer, there's also all the Go dependency management tools that existed before native Go modules, e.g. Dep, Glide, Go Package Manager, etc.)
As someone who has contributed to a language server, I've wanted a language/editor agnostic way to interact with it, primarily for the purposes of black-box testing. I wonder if this could be useful for that?
What's the process for adding support for a new language?
I can see now how that line can give the wrong impression. My unit is very dear to me, to the point where I call it by name like any other housemate. It's always "honey, I'll give Bob a go at these dishes". I guess I was expecting constructive discourse on HN without having to dodge knee-jerk comments at every step.
I think someone demonstrated in the announcement thread that, adjusting for inflation, the Pi5 is going to be cheaper at release than the Pi4.
Ultimately though, at least IMO, the Pi isn't about being cheap, it's about being capable while staying a great value. I bet there's a lot of hidden complexity in the pricing, and it's very possible that they'd have to compromise significantly more than 12.5% of the functionality/performance to get a 12.5% price reduction (to $35).
A naive approach that may still work well is to simply break up the image into fixed, predetermined regions. I don't believe this would be significantly more work for the server if it's already comparing pixel-by-pixel, and the average frame will probably contain updates only in one region. Even breaking it into 4 or 6 would, I think, be a significant payload reduction.
Ehhh, a lot of high level languages support low-level interop. Python, Ruby, etc. It's not something you usually reach for as a user, but rather as a library author.
Of course everyone wants their language to be faster, but the interop story for Elixir/Erlang is very good, all things considered.
Similar issues for me. I can load github.com and my profile, but visiting a repository (or trying to git pull a repo with the https origin) returns a 500.
Same, I’ve been working on a command line tool and set up VCR to record demos (https://github.com/zachallaun/mneme/blob/main/examples/demo....). I’d be very interested if anyone could speak to the fundamental differences between VCR and the tools referenced in the OP.
Yeah, I saw; I've kept up w/ everything pretty closely. Still decently frustrating as a paying customer, but I hope they can figure it out. If they can and can show some real reliability, I'll be an even bigger fan.
Yep! More putting it out there for other folks. I’m also a somewhat frustrated paying customer, but as I’m dealing with my own growing pains, I relate to what they’re going through. I’ve personally migrated my DB to Crunchy to somewhat mitigate the risk.
That's a good point / thing that I've not thought about as much here. I would be much more frustrated if my primary datastores were hosted there. As things stand, their semi-hosted offering never really made sense to me (esp. now lol), but I do think if you get into the game of DB hosting there's almost another level of expectation even beyond basic compute (oddly enough)
