The link-aggregator part of the fediverse has grown, with the launch of PieFed’s beta test. PieFed joins platforms like Lemmy and Kbin who all have the ability to share links, and comment and vote on them. PieFed focuses on making the platform easy to manage, maintain and develop for, and uses Python. Developer Rimu is […]
  • fenndev@leminal.spaceEnglish
    8·
    10 months ago

    Always happy to see a new Fediverse service!

    My only concern is Python. Wonderful for AI and scripting, but I’m not sure how well it works as a web server. Although, I’d assume that a lot of the web server code is actually C under the hood…

    • Rimu@piefed.social
      17·
      10 months ago

      PieFed dev here.

      It’ll be interesting to see how Python performs.

      There’s some fun stuff you can do with compiling Python into C. e.g. https://cython.org/ or https://docs.exaloop.io/codon/. But I don’t see a need for it as PieFed doesn’t really crunch numbers much. Mastodon has a Ruby backend. Kbin uses PHP. Until you get really massive the choice of language doesn’t really make a huge difference to performance as most of the work in most web apps is done by the database.

      I am a little bit concerned about the limited support for asynchronous I/O in the Flask framework, which could limit scalability at some point. But there are options for the future. Quart claims to be a drop-in replacement for Flask.

      In any case, performance is just one factor. For a FOSS project to be successful long term it needs contributions from other developers and with the massive pool of Python developers there are, hopefully I’ll be getting some help soon. Also along those lines I have deliberately chosen:

      • to code as simply and stupidly as possible, to make it accessible to most skill levels.
      • No complicated frameworks, fancy algorithms, or esoteric design patterns. Model View Controller, baby.
      • No frontend build process or tool chain (vanilla JS only. No npm).
      • Few third party dependencies, only Redis and Postgresql. Mostly.

      All this makes setting up an initial development environment, finding the bit you want to change and testing it out fairly quick and easy.

      I hope it’s these choices that lead to an absolute blizzard of contributions from many people and that’s where the true strength of the project will come from.

      • Spzi@lemm.eeEnglish
        4·
        10 months ago

        In any case, performance is just one factor. For a FOSS project to be successful long term it needs contributions from other developers and with the massive pool of Python developers there are, hopefully I’ll be getting some help soon. Also along those lines I have deliberately chosen:

        to code as simply and stupidly as possible, to make it accessible to most skill levels.
No complicated frameworks, fancy algorithms, or esoteric design patterns. Model View Controller, baby.
No frontend build process or tool chain (vanilla JS only. No npm).
Few third party dependencies, only Redis and Postgresql. Mostly.

        All this makes setting up an initial development environment, finding the bit you want to change and testing it out fairly quick and easy.

        Sounds very wise to make it as accessible as possible. And you basically get super maintainable code as a side product!

      • fenndev@leminal.spaceEnglish
        1·
        10 months ago

        Thanks for the in-depth response! I definitely understand choosing Python for a fledgling project like this and trying to attract a developer community.

        As for my musing about C and Python, I wasn’t really talking about Cython or anything like that; I actually meant that I figured the specific code in the Python standard library and various frameworks for server applications were written under the hood with C and heavily optimized.

    • shrugal@lemmy.worldEnglish
      5·
      10 months ago

      The database, storage and network are usually the bottlenecks in these kinds of websites, not the programming language. It might add a few ms of latency, but the big lags come from congestion or bad db queries.