• 1 Post
  • 576 Comments
Joined 4 years ago
cake
Cake day: May 31st, 2020

help-circle






  • Problem is that none of the algorithms actually care about showing you things you like.

    Ads try to sell you on things that you wouldn’t otherwise buy. Occasionally, they may just inform you about a good product that you simply didn’t know about, but there’s more money behind manipulating you into buying bad products, because it’s got a brand symbol.

    And content recommendation algorithms don’t care about you either. They care about keeping you on the platform for longer, to look at more ads.
    To some degree, that may mean showing you things you like. But it also means showing you things that aggravate you, that shock you. And the latter is considered more effective at keeping users engaged.










  • Personally, I’ve found Poetry somewhat painful for developing medium-sized or larger applications (which I guess Python really isn’t made for to begin with, but yeah).

    Big problem is that its dependency resolution is probably a magnitude slower than it should be. Anytime we changed something about the dependencies, you’d wait for more than a minute on its verdict. Which is particularly painful, when you have to resolve version conflicts.

    Other big pain point is that it doesn’t support workspaces or multi-project builds or whatever you want to call them, so where you can have multiple related applications or libraries in the same repo and directly depending on each other, without needing to publish a version of the libraries each time you make a change.

    When we started our last big Python project, none of the Python tooling supported workspaces out of the box. Now, there’s Rye, which does so. But yeah, I don’t have experience yet, with how well it works.



  • We’ve got a WebAssembly web-UI at $DAYJOB. Implementation language is Rust, we use the Leptos framework (although other mature frameworks are available for Rust).

    Pros:

    • Same language and similar tooling as in the backend. Most libraries work the same way (obviously excluding libraries that read from the filesystem, for example). This is especially good, if you’ve got lots of “full stack” devs.
    • Same model classes as in the backend. If you change a field, the compiler will force you to fix it on both sides. It is compile-time guaranteed that backend and frontend are compatible.
    • Rust is a nicer language than JS/TS. I find especially Rust’s error handling via Result and Option types + pattern-matching works really well for UI stuff. You just hand the Result value over to your rendering stack and that displays either the value or the error. No unset/null variables, no separate error variable, no ternaries.
    • Having a strict compiler makes it less bad when you’re lax on testing, and frontend code is a pain to test.

    Cons:

    • If you’ve got pure frontend folks, or people who are deep into React or Angular or whatever, those are not going to be as productive.
    • The JS ecosystem is massive, you just won’t find as many component libraries for Rust, which can definitely also reduce productivity.

    With me being in a team with few frontend folks, I would definitely opt for it again.


  • Well, for reasons, I happen to know that this person is a student, who has effectively no experience dealing with real-world codebases.

    It’s possible that the LLM produced good results for the small codebases and well-known exercises that they had to deal with so far.

    I’m also guessing, they’re learning what a PR is for the first time just now. And then being taught by Microsoft that you can just fire off PRs without a care in the world, like, yeah, how should they know any better?