Comment on Nextcloud (PHP) vs OpenCloud (Rust)

phoenixz@lemmy.ca ⁨11⁩ ⁨months⁩ ago

• null_dot@lemmy.dbzer0.com ⁨11⁩ ⁨months⁩ ago

  PHP apps always feel old.

  source

  • phoenixz@lemmy.ca ⁨11⁩ ⁨months⁩ ago

    So does your comment, what’s your point? Are you really trying to tell me that an app developed in PHP 15 years ago still feels old? Because doh.

    Next cloud feels old to you?

    source

    • null_dot@lemmy.dbzer0.com ⁨11⁩ ⁨months⁩ ago

      Nextcloud really does feel old.

      source

      • phoenixz@lemmy.ca ⁨11⁩ ⁨months⁩ ago

        Care to elaborate?

        Like seriously, with the PHP extension gone from the URL you wouldn’t know it’s PHP but somehow it’s old because…?

        source

        • -> View More Comments
• sugar_in_your_tea@sh.itjust.works ⁨11⁩ ⁨months⁩ ago

  I’m not OP, but here are my reasons:

  • needs a webserver to be configured properly, in addition to the application itself - most other projects handle the server itself, so I can simply reverse proxy to it
  • recent security audit found a variety of vulnerabilities - PHP has been known to have a lot of security vulnerabilities, and it’s commonly targeted due to popularity and the prevalence of these vulnerabilities; using literally anything else reduces the likelihood that you’ll be targeted by script kiddies
  • since it doesn’t run an active server, things like WebSockets are wonky - AFAICT, Nextcloud solves this by using a separate Rust binary, which is weird
  • using the templating feature (i.e. the whole point of PHP) takes a lot of resources vs client-side rendering, so the main sell of PHP is architecturally suspect
  • I don’t use it, so if I needed to fix a bug, it would be a lot of work; I’m a lot more familiar with other languages, like Go, Rust, and Python

  There are a bunch of other reasons I strongly dislike PHP, but hopefully this is enough to show why I generally prefer to avoid it. In fact, Nextcloud is my only PHP-based app, and I’m testing out OCIS now (will probably try OpenCloud soon).

  source

  • phoenixz@lemmy.ca ⁨11⁩ ⁨months⁩ ago

    • PHP doesn’t have a built in web server because it doesn’t need one, makes development a whole lot easier as each page is it’s independent process. No worries about memory loss, state corruption, or other issues. IMHO it adds to its security and ease of handling

    • It’s super fast and easy to setup and get going

    • Web sockets work just fine, I use them daily on dozens of servers doing hundreds of requests / sec all day every day

    • They did an audit and found issues? Great, I applaud people searching and finding issues. Shall we do the same for Rust, go, or chuckle JavaScript?

    • You’re unfamiliar.with the language. <<< Yeah, that is the standard reason for hating PHP, it’s not <insert my personal favorite language>

    source

    • sugar_in_your_tea@sh.itjust.works ⁨11⁩ ⁨months⁩ ago

      adds to its security and ease of handling

      PHP… security?

      Any security you get from running as a separate process/thread is undermined by sloppy language semantics and standard library. The built-in “mysql_” library was atrocious and stayed in the standard library for years (removed in 7.0, ~10 years after the previous release). Errors at least used to be really inconsistently communicated (sometimes need to call another function to check error status, sometimes returns 0 or - 1, sometimes raises exceptions). Types are pretty loose and subtly change type (e.g. when an int overflows, it becomes a float?). Variables spring into existence when you use them, so no warning about typos, shadowing, etc.

      The language wasn’t really designed, it evolved from a simple templating engine to a full fledged language, and it cleaned up a little along the way. But a lot of the old cruft still remains.

      super fast and easy to setup and get going

      Yeah, that was always the goal. All you need is a webserver and a directory of scripts and you’re golden.

      But lowering the barrier to entry comes with costs. It encourages people to just copy and paste crap until it works, I know because that’s exactly what I did when I first used PHP (JS w/ jQuery is the same way). This encourages a “just get it working” mindset instead of actually understanding what’s going on.

      You can certainly write good PHP code, my point is that it actively encourages cludgy code, which means security holes, and the best example is the language and standard library themselves.

      Web sockets work just fine

      Do they? I assume they hog a whole process/thread for themselves instead of being efficiently managed in something with proper async tooling, so it sounds like it would scale horribly. What happens if you have a million open websockets?

      They did an audit and found issues? Great, I applaud people searching and finding issues. Shall we do the same for Rust, go, or chuckle JavaScript?

      Yes. I would be very surprised if Go or Rust yield even a fraction of the vulnerabilities as PHP. Even if we expand the scope a bit to a full-fledged web server framework. And that’s with all the server bits, while PHP only worries about its standard library.

      I’ve used each of those languages. I’ve built sites in PHP, Go, and Rust, as well as Python and JavaScript (nodejs). PHP is by far the jankiest, and that’s including all the footguns w/ Go’s concurrency model.

      source