[-] FizzyOrange@programming.dev 3 points 1 week ago

You're still missing the point. We all understand that definition. We're just saying that it is incorrect use of the word "concurrent". Does that make sense? The word "concurrent" means things happening at the same time. It's stupid for programmers to redefine it to mean things not happening at the same time.

[-] FizzyOrange@programming.dev 3 points 1 month ago
  1. If your alternative is C++ then it removes the enormous burden of manually tracking lifetimes and doing manual memory management. C++ does have RAII which helps with that enormously but even then there are a gazillion footguns that Rust just doesn't have - especially with the newer stuff like rvalue references, std::move, coroutines etc. It also saves you from C++'s dreaded undefined behaviour which is everywhere.

  2. It has a very strong (and nicely designed) type system which gives an "if it compiles it works" kind of feel, similar to FP languages like Haskell (so they say anyway; I've not used it enough to know). The borrow checker strongly pushes you to write code in a style that somehow leads to less buggy code. More compiler errors, but much less debugging and fixing bugs.

  3. The libraries and APIs are generally very well designed and nice to use. If you've ever used Dart or Go think how nice the standard library is compared to JavaScript or PHP. It took C++ like 2 decades to get string::starts_with but Rust started with it (and much more!).

  4. Fast by default.

  5. Modern tooling. No project setup hassle.

  6. It's a value based language, not reference based. References are explicit unlike JavaScript, Java, C#, etc. This is much nicer and makes things like e.g. copying values a lot easier. JavaScript's answer for ages was "serialise to JSON and back" which is crazy.

Downsides:

  1. Slow compilation sometimes. I'd say it's on par with C++ these days.

  2. Async Rust is kind of a mess. They shipped an MVP and it's still kind of hard to use and has unexpected footguns, which is a shame because sync Rust avoids footguns so well. Avoid async Rust if you can. Unfortunately sometimes you can't.

  3. Interop with C++ is somewhat painful because Rust doesn't have move constructors.

Great language overall. Probably the best at the moment.

[-] FizzyOrange@programming.dev 4 points 2 months ago

I dunno maybe once a week or so? We don't actually have a system that detects if your pip install is out of sync with pyproject.toml yet so I run it occasionally just to make sure.

And it runs in CI around a dozen times for each PR. Yeah not ideal but there are goodish reasons which I can explain if you want.

[-] FizzyOrange@programming.dev 3 points 2 months ago

you generally use a SAT solver for dependency resolution (unless you don’t care for correctness)

Actually Go's dependency system is specifically designed to avoid the need for global constraint solvers. Go has the most modern and elegant dependency versioning system that I'm aware of. Python was designed before people realised that it's dependency style was a mistake.

https://research.swtch.com/vgo-principles

[-] FizzyOrange@programming.dev 3 points 3 months ago

no need for flatpack/appimage/snap ect

No matter how large their repo is you're always going to find some software they haven't packaged. Trying to convince the entire world to use your repo isn't scalable.

[-] FizzyOrange@programming.dev 3 points 3 months ago

That's not at all the conclusion you should draw. xz was linked into systemd but that was just a convenient target. Once xz was compromised it could have targeted literally anything that loaded it. Your only real defence would have been not to install it at all.

[-] FizzyOrange@programming.dev 4 points 3 months ago

Neat hack, but IMO this just loses waaay too many features and UX that Github et al. have. Only masochists will use this. Here are a few I can think of:

  1. From a user perspective it's "simpler" in that it saves maybe 1 command... git push (I've still going to want to make a branch), and clicking on the "create a PR" link. But you've also made updating a PR way more of a pain - it was git push, now it's... I dunno some long command I don't remember and looking up a PR number in the web interface?
  2. Can't request reviews from people.
  3. Can't enforce review requirements.
  4. Can't require review comments to be resolved (I bet it's easy to miss review comments!)
  5. Can't easily tell who wrote review comments. Are you really supposed to have a conversation by adding // Dave: I agree under comments?
  6. Can't add comments to code that doesn't support comments (e.g. packages.json)
  7. No CI integration.

I guess some of those are fixable, but overall this seems like a clever hack but very clunky.

I guess it's better than a mailing list at least.

[-] FizzyOrange@programming.dev 4 points 4 months ago

This should work out of the box!

[-] FizzyOrange@programming.dev 4 points 4 months ago

How do you expect the system to know what program is important to you and which isn’t?

Hmm

The windows solution is to switch tasks very often and to do a lot of accounting to ensure fair distribution.

Sounds like you have a good idea already!

[-] FizzyOrange@programming.dev 3 points 4 months ago

Microsoft doesn't have a vetting process for publishing extensions in the store. Maybe the failure is that people assume they do?

[-] FizzyOrange@programming.dev 3 points 6 months ago

Honestly twice as slow as CPython is probably quite an achievement. Even so I can't imagine many people can tolerate their code running that slow. I'm not really seeing the use case for this. On the web you can use Typescript, which is a better language and far more mature for that use case.

[-] FizzyOrange@programming.dev 3 points 6 months ago

Yes I understood that. My point is how often do you know you need to move a line exactly 17 lines? Do you count them? Clearly much slower than doing it interactively by holding down ctrl-shift-down for a bit.

view more: ‹ prev next ›

FizzyOrange

joined 1 year ago