[–] 1 point 2 weeks ago* (last edited 2 weeks ago) (4 children)

It wasn't my project. Afaict it's a standard pytest setup with the Litestar framework (unused in my tests) and an in-memory mock Postgre transaction with like five records per test, so choose for yourself which part of this is 'catastrophically wrong'. However, I can indeed agree that most of it is trash.

Same approach with dozens upon dozens of tests worked snappily as heck in PHP, haven't yet tried it with my beloved Lua.

  • source
  • parent
  • context
  • [–] 3 points 2 weeks ago (1 child)

    See, this is the problem with vibe-coded projects and LLMs in general. They are fundamentally atomizing.

    I can only speak for myself, though anecdotally I would guess this is not an uncommon position, when I say that this isn't fun. To build a community around a project you need people to be excited about the project and to be willing put free time into it because of that.

    Vibecoding an app removes all the parts that made building a project fun and leaves behind only the shitty ones; the ones you specifically highlighted, the project management ones.

    Maybe you got into software because you really love Agile and Gantt charts but, for a lot of people, the appeal was the craft. Open source was awesome because they can build things with like-minded people in a way that is tactile and interactive. Not unlike woodworking or metalworking hobbyists. LLMs take that part and light it on fire.

    Sure, the bot can churn out fully functioning code for me. But I'm not excited about it, and I'm certainly not excited about someone else's.

  • source
  • parent
  • context
  • [–] 1 point 2 weeks ago* (last edited 2 weeks ago)

    It wasn't a very wrong what I did in Python. I did the obvious thing. While I do not remember details, I remember it had something to do with adding items I think. But sadly I have not documented this issue, that's on me. It was only noticeable for really huge files like 50MBytes json. Edit: Most weren't this big, but it also combined over 100 Json files into one, so a search would search them all through and be able to save as a single file.

  • source
  • parent
  • context
  • [–] 4 points 2 weeks ago

    Sure, it’s slow. Google’s landing page is 4 MB for a small graphic, a text form, and some buttons. But what are you going to do? Not use it? They won. They don’t have to fix shit.

    This neglects to include the massive amount of additional front-end code Google (and other large tech companies) toss on their webpages for things that are purely for their own benefit while being of zero or negative value to the users. Mouse tracking, analytics, fingerprinting, and all kinds of other harmful content that tech companies put out go a long way towards reaching that 4MB figure.

  • source
  • parent
  • context
  • [–] 2 points 2 weeks ago

    It’s not so much “But that’s not how you build stable software.” It’s more like “But that’s not how you build software [at all today].” Modern software is powered by loads of shared packages, that’s just how all modern languages work. This is equally true for Rust and Python.

    You're not wrong - all libraries with automated dependency packaging do have this problem. But you're downplaying the scale by a lot. Javascript dependency graphs are absolutely massive. Python has a decent standard library that reduces the number of shared packages by quite a bit. There are definitely downsides to having a large standard library like Python has, but it does significantly reduce the probability of a supply chain attack compared to Javascript.

    I can't comment on Rust personally, since I don't have much experience with the ecosystem.

  • source
  • parent
  • context
  • [–] 5 points 2 weeks ago (4 children)

    Or the fact that you can’t do concurrency especially across the language barrier from another language without multiple python runtimes orchestrated with a queue and IPC because of possible process-wide global state and similar concerns/assumptions for any python library dependency that is not all native across its own dependency chain?

    This is very out of date. I haven't written Python for over 4 years and even back then, I was using multiprocessing.Pool for pretty much all parallel processing that I ever needed. Sure, it's doesn't fit every use case for concurrency, but for simple stuff it's perfectly fine.

    Not only that, it's one of the simplest parallel processing APIs I've ever used:

    from multiprocessing import Pool
    
    def f(x):
        return x*x
    
    if __name__ == '__main__':
        with Pool(5) as p:
            print(p.map(f, [1, 2, 3]))
    
  • source
  • parent
  • context
  • [–] 3 points 2 weeks ago (3 children)

    Did you use a profiler to find the bottlenecks? Did you try using cjson to speed up the json parsing? I would also avoid using the stdlib regex library too. It's probably more of a convenience/reference implementation, not something to be intended for high performance. Maybe there's a re2 wrapper for Python or a similar regex library in C with Python bindings.

    Rewriting in Rust is fine, but good Python devs know how to find bottlenecks in their software and replace them with fast implementations. I've written plenty of performant Python code, it's not very hard to profile and optimize. Usually the performant stuff is already written in C/C++ or Fortran anyway (numpy, PyQt, etc.)

  • source
  • parent
  • context
  • [–] 3 points 2 weeks ago* (last edited 2 weeks ago) (1 child)

    I mean you're right, I don't want it to be true, but also my job is to try to use AI to make my teams more productive. And we've succeeded to a degree. We are getting more done. But it is not ask and thou shalt receive.

    I use AI a lot. Yesterday I gave up and built my own harness because if I don't I'm eventually going to be saddled with the shit my company is trying to make a thing. It was astoundingly easy, though now I'm on the treadmill of "just a few more tweaks...".

    In 8 hours I built the thing while generating about 800 LOC and another 1500 lines of tests in the actual application I'm working on. And I'd say I've largely built "the easy stuff," and the implementation classes are going to be more challenging. I'm pushing as hard as anyone to make AI development actually work — I actually enjoy the challenge and rapid iteration quite a bit. I'm not speaking out of ignorance here.

    I've vibe coded a couple of personal application things. They aren't production-ready business apps, but they do everything I need. And they really were as simple as asking for what I wanted and I can add features about as quickly. It's incredible. But it's not replacing any of my developers yet.

    My only caveat: I really haven't tried Fable due to cost. Anyway, be well, mate. Enjoying the conversation despite disagreeing.

  • source
  • parent
  • context
  • [–] 8 points 2 weeks ago* (last edited 2 weeks ago) (5 children)

    Recently had to develop a Python project, the tests took at least ten seconds to start each single time. This is while I made over a hundred tests for my module and re-ran them after every change.

    Python is dog slow, but if each of your tests are taking 10 seconds to start (not even run!), then something is catastrophically wrong with your setup. For comparison, for one of my projects, it takes a total of 12 seconds to run nox on a clean slate, which involves setting up venvs for five major versions of Python, installing the package and its dependencies in each, and finally running the 1500 test test-suite five times

  • source
  • parent
  • context
  • [–] 1 point 2 weeks ago* (2 children)

    If you need any of those things, you can just ask for it.

    I get that you really don't want it to be true that it works as well as it does. Your job depends on it.

    Mine does too, but I can face the truth even if it is unpleasant.

    Also I wouldn't necessarily have believed it either if I hadn't tried it for myself. I would encourage you to spend a bit of money and a couple of days vibe coding something non-trivial with Opus 5.5. Then at least you'll know what's coming...

  • source
  • parent
  • context
  • [–] 4 points 2 weeks ago (3 children)

    Is the login oidc and pkce compliant? Does it support SSO? Persistent login? Gdpr? How does account recovery go if Google kills a customer account? Does data get linked to crm? Does it scale horizontally? What database does it use? How does it handle attacks and spam? Does it support images? If so, how do you mitigate CSAM? How do you track usage and engagement? How do you get alerted if your forum is down?

    I ask all of this because while AI can build what you describe pretty easily, it's also completely useless from a business perspective. You're right that years ago, you'd have a small team of devs writing this buy something off the shelf.

    But when your C-suite hands you the code and tells you to deploy it, what then? Does it even support admin users and mods or is everyone going to Couchbase to edit the tables directly.

  • source
  • parent
  • context
  • [–] 19 points 2 weeks ago

    I worked at a place where a site had to show the number of members, but for some reason it didn't show the correct number. The reason was the query to the database was wrong, I corrected it in five minutes and the boss told me to put numbers manually, increasing them until we could display the correct query result because apparently the problem was there a long time before I started working there and it would make a bad image for the company if it was so easily corrected.

    On other project a friend of mine told me about things were so slow and getting slower with time. Database didn't have keys, indexes, nothing you should expect a relational database to have.

    I haven't worked in a while because of my health issues and I can assure you I'd be happier getting paid for watering plants than working with computers.

  • source
  • [–] -4 points 2 weeks ago* (10 children)

    Yeah nah, Lua runs circles around Python both at runtime and especially at startup. I've made me some desktop automation scripts in Lua to call from Alfred, I had to recheck that I didn't leave static test data in there instead of calling the script, because the results were appearing instantly.

    Recently had to develop a Python project, the tests took at least ten seconds to start each single time. This is while I made over a hundred tests for my module and re-ran them after every change.

  • source
  • parent
  • context
  • [–] 5 points 2 weeks ago* (last edited 2 weeks ago) (3 children)

    Well that's even weirder. It is in a list labeled malicious/scammer/fishing.

    It absolutely isn't any of those.

    Someone else claimed it pulls resources from a botnet but if you view source, that isn't true.

  • source
  • parent
  • context
  • [–] 4 points 2 weeks ago (5 children)

    Counterpoint, I wrote a Python program that reads a load of JSON and runs regex searches over it. It was quite slow. Rewrote it in Rust as a straight 1:1 port, no algorithmic changes. 50x speedup.

    I think you must have either done something very wrong or your Python program didn't really do anything other than call Python built-ins that are actually written in C.

  • source
  • parent
  • context
  • view more: ‹ prev next ›