One of the Loki maintainers here (though I mostly work on other stuff now). I promise it's not difficult on purpose.
We've put a lot of effort into optimizing the Kubernetes experience that non-containerized installations haven't been getting as much attention. We'd be thrilled to have system packages for Loki that also set it up as a service, it's just not something we've been able to spend time doing ourselves yet.
Honestly I mostly throw out the Debian service definitions anyways - when clustering or interacting with Chef or Ansible or whatever, you end up building a lot of ‘smarts’ around a custom supervisor like Runit or skarnet or systemd
I’m deploying it (prom, alertmanager, pushgateway, grafana) on native hardware via ansible and it’s not difficult. Not Loki (yet). It’s all just go binaries you fire up with systemd with a single config file.
I find it harder to deploy reliably on kubernetes with persistent volumes etc.
Grafana Labs employee here. We've been using jsonnet-bundler as a package manager on top of our Tanka configs. As for some common packages, we open source most of ours[1]. We also provide Tanka-compatible configs for Loki[2].
Ah, yeah, I figured this would be an issue, which is why I thought having it be something you could disable could fix some of those potential headaches.
I've seen both, but I haven't spent a lot of time looking at their documentation to start making comparisons.
At the moment, I only have a vague idea of what I want Orange to be. The development has mostly been driven with what I thought at the time. It's been a bad approach, and I plan to fix it before I continue developing.
I'm going to work on figuring out Orange's specific goals and points where it differs from new languages like these. Saying I'll have this ready by the end of the weekend might be a stretch, but I will get back to you soon.
After looking more into Crystal, it seems to try to be as Ruby-like as possible. I like Ruby, but I think its more involved features are syntactically complicated. I'm also just not a fan of the "everything is an object" mantra.
On the other hand, while Orange takes some syntax as Ruby, I'm trying to keep the syntax small and simple (similarly to C), and make sure that you could write programs for target platforms like the Arduino without needing a runtime.
Any options I had planned for the language were going to be per-project settings, so at least the coding style in any given project would be consistent.
While I do strongly believe that optional typing is a feature I want to keep, I have been focusing too hard on taking a middle-of-the-road approach.
The original idea was to have a systems development language that had the same "feel" as a high level scripting language. I didn't do a lot of planning on what that meant from the technical side.
I appreciate the advice. I'll spend some time getting the answer to what Orange actually is.
