Well yeah the second comment didn't really had to be, but hey it's certainly not really reason enough to ban someone from the repo. The first comment I think is totally ok (as well as marking it off-topic, but optimally with an answer, probably marked as off-topic as well). Just keep an issue (it's not a PR) open, until the issue is resolved in one way or the other i.e. either solved reasonably via a third-party client (with links to it) or directly in the repo, asking the community (when it's not obvious that the issue is resolved), whether this is resolved, wait for reactions, and close it after some time based on that. Banning someone, or quickly closing or not reopening after a carefully written argument, that the issue is not solved etc. is just childish behaviour, especially for a community focused project (I'm watching a few lemmy issues on GH).
$0.7k annually? Is it anyhow possible to live with that low salary in India? I can't even live a month with that here, even if I don't buy anything but the cheapest food and live in the smallest apartments here...
Yes
Yeah works well, as long as the code is rather simple and it occurred rather often in the training set. But I seldom use it currently (got a little bit more complex stuff going on). It's good though to find new stuff (as it often introduces a new library I haven't known yet). But actual code... I'm writing myself (tried it often, and the quality just isn't there... and I think it even got worse over the last couple of months as also studies suggest)
Yeah the whole situation is a little bit fucked, Google has too much power (over Mozilla) and browser engines in general. But I'm optimistic about the open source community, e.g. brave integrates their own ublock compatible rewrite (in Rust ^^) into chromium. So I think sooner or later there are patched/forked chromiums and if Mozilla indeed makes the move towards WebDRM then also Firefox forks.
I really hope servo under the umbrella of the Linux Foundation proves to be a viable alternative in the future, that's a little bit more independent than Firefox.
yeah as nice as it is what you can achieve with trait-bounds there are definitely trade-offs, being compile time and error messages, and sometimes mental complexity, understanding what the trait-bounds exactly mean... I really hope, that this area gets improvement on at least the error-messages and compile time (incremental cached type-checking via something like salsa)
Yet it still feels sloppy (and I couldn't find why to the defense of Jerboa, I skimmed through the relevant code but couldn't find immediate issues and there's an open issue: https://github.com/dessalines/jerboa/issues/445)
I don't get why, with so much hardware power we still have these issues...
I agree with the other comment. It's Open source after all, they could've just crawled the web otherwise.
Private repos on the other hand is a different story.
Yep it's like maintaining a codebase that's getting increasingly better. It's a rabbit-hole and a timesink (kind of because you're trying to get the best out of it, and thus configure likely more) but I think it's worth it. It gets better overtime as well
I don't know I really hate when jumping to definitions in libraries, I often just land in the "typings" file. I also think that the type-system is often incoherent, has some weird side-effects and often leads to overengineering your typings... I just generally avoid Javascript based languages (which unfortunately is not really possible in frontend...)
Haha very accurate representation of me xD
Although I'm fully in camp functional, I doubt that. There are problems that are inherently stateful and rely on mutability. Modelling that in Haskell often results in unnecessary abstractions. I think Rust hits a sweet spot here (when you're that experienced to write idiomatic Rust, whatever that exactly is). Also being lazy by default has its own (performance) implications, strict + lazy iterators (like Rust) is a good default IMO.