6 ms·

This. I find open source projects written in Go or Rust are usually more pleasant to work with than Java, Django or Rails, etc. They have less clunky dependenci

This. I find open source projects written in Go or Rust are usually more pleasant to work with than Java, Django or Rails, etc. They have less clunky dependencies, are less resource-hungry, and can ship with single executables which make people's life much easier. Just think about Gitea vs GitLab.

matsemann 4y ago
Not sure why you include java in that, as you mostly get a standalone file. No such thing as a jre in modern java deployment. As for python, at least getting a dockerfile helps a lot. Otherwise it's a huge mess to get running, yes. Python is still a hassle anyways, since the lack of true multithreading means that you often need multiple deployments, which the Celery usage here for instance shows.
- FridgeSeal 4y ago
  Python application deployments are all fun and games until suddenly the documentation starts unironically suggesting that you should “write your configuration as a Python script” that should get mounted to some random specific directory within the app as if that could ever be a sane and rational idea.
- Volundr 4y ago
  > Not sure why you include java in that, as you mostly get a standalone file. No such thing as a jre in modern java deployment. Maybe I'm behind the times, but I can't figure out what you mean here. As far as I know 'java -jar' or servlets are still the most common ways of running a Java app. Are you talking graal and native image?
  - matsemann 4y ago
    For deploying your own stuff, most people do as before, yes. But even then, it's at least still only a single jar file, containing all dependencies. Not like a typical python project where they ask you to run some command to fetch dependencies and you have to pray it will work on your system. But using jlink for java, one can package everything to a smaller runtime distributed together with the application. So then I feel it will be not much different than a Go executable. > The generated JRE with your sample application does not have any other dependencies... > You can distribute your application bundled with the custom runtime in custom-runtime. It includes your application. From the guide here https://access.redhat.com/documentation/en-us/openjdk/11/html-single/using_jlink_to_customize_java_runtime_environment/index https://access.redhat.com/documentation/en-us/openjdk/11/htm...
eeZah7Ux 4y ago
Hell no, I want stuff like OnCall packaged into Linux distribution. I need something stable and reliable and that receive security fixes. Maintaining tenths of binaries pulled from random github projects over the years is a nightmare. (Not to mention all the issues around supply chain management, licensing issues, homecalling and so on)
- morelisp 4y ago
  At this point I trust the Go modules supply chain considerably more than any free distro's packaging, which is ultimately pulling from GitHub anyway.
  - dijit 4y ago
    > At this point I trust the Go modules supply chain considerably more than any free distro's packaging What has happened in the package ecosystem to make you believe this? Is it velocity of updates or actual trust? I haven’t heard of any malicious package maintainers.
    - morelisp 4y ago
      Better automation ensuring packages are immutable, fewer humans in the packaging loop.
      - dijit 4y ago
        generally I prefer humans in the loop, someone to actually test things. This is why distros are stable compared to other distros which are more bleeding edge.
        morelisp 4y ago
        For SC security, the fewer points of attack between me and the source the better. For other kinds of quality, I have my own tests which are much more relevant to my use cases than whatever the distro maintainers are doing. I've been a DD and while distros do work to integrate disparate upstreams as well as possible, they rarely reject packages for being fundamentally low quality or make significant quality judgements qua their role as maintainer (only when they're a maintainer because they're also a direct user). Other distributions do even less than Debian.

matsemann 4y ago

Not sure why you include java in that, as you mostly get a standalone file. No such thing as a jre in modern java deployment. As for python, at least getting a dockerfile helps a lot. Otherwise it's a huge mess to get running, yes. Python is still a hassle anyways, since the lack of true multithreading means that you often need multiple deployments, which the Celery usage here for instance shows.

FridgeSeal 4y ago
Python application deployments are all fun and games until suddenly the documentation starts unironically suggesting that you should “write your configuration as a Python script” that should get mounted to some random specific directory within the app as if that could ever be a sane and rational idea.
Volundr 4y ago
> Not sure why you include java in that, as you mostly get a standalone file. No such thing as a jre in modern java deployment. Maybe I'm behind the times, but I can't figure out what you mean here. As far as I know 'java -jar' or servlets are still the most common ways of running a Java app. Are you talking graal and native image?
- matsemann 4y ago
  For deploying your own stuff, most people do as before, yes. But even then, it's at least still only a single jar file, containing all dependencies. Not like a typical python project where they ask you to run some command to fetch dependencies and you have to pray it will work on your system. But using jlink for java, one can package everything to a smaller runtime distributed together with the application. So then I feel it will be not much different than a Go executable. > The generated JRE with your sample application does not have any other dependencies... > You can distribute your application bundled with the custom runtime in custom-runtime. It includes your application. From the guide here https://access.redhat.com/documentation/en-us/openjdk/11/html-single/using_jlink_to_customize_java_runtime_environment/index https://access.redhat.com/documentation/en-us/openjdk/11/htm...

eeZah7Ux 4y ago

Hell no, I want stuff like OnCall packaged into Linux distribution. I need something stable and reliable and that receive security fixes. Maintaining tenths of binaries pulled from random github projects over the years is a nightmare. (Not to mention all the issues around supply chain management, licensing issues, homecalling and so on)

morelisp 4y ago
At this point I trust the Go modules supply chain considerably more than any free distro's packaging, which is ultimately pulling from GitHub anyway.
- dijit 4y ago
  > At this point I trust the Go modules supply chain considerably more than any free distro's packaging What has happened in the package ecosystem to make you believe this? Is it velocity of updates or actual trust? I haven’t heard of any malicious package maintainers.
  - morelisp 4y ago
    Better automation ensuring packages are immutable, fewer humans in the packaging loop.
    - dijit 4y ago
      generally I prefer humans in the loop, someone to actually test things. This is why distros are stable compared to other distros which are more bleeding edge.
      - morelisp 4y ago
        For SC security, the fewer points of attack between me and the source the better. For other kinds of quality, I have my own tests which are much more relevant to my use cases than whatever the distro maintainers are doing. I've been a DD and while distros do work to integrate disparate upstreams as well as possible, they rarely reject packages for being fundamentally low quality or make significant quality judgements qua their role as maintainer (only when they're a maintainer because they're also a direct user). Other distributions do even less than Debian.