rfratto

I'm one of the developers working on Grafana Alloy. Happy to answer any questions people may have!

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.

Congrats to the team at Grafana! I've been working here for a little over a year and I'm really excited to see how far we can go with this.

Great job Cortex team!

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].

[1]: https://github.com/grafana/jsonnet-libs

[2]: https://github.com/grafana/loki/tree/master/production/ksonn...

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.

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.

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.

You're absolutely right.

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.

When a standard library is introduced, Orange will be garbage-collected.

Each parameter in a function without a type identifier is a unique generic type. This means any function with two typeless parameters already accepts two different kinds of generic types.

I was more inspired by Ruby's syntax, which I always thought was very clean to read.

I struggled coming up with a lot of examples since I don't have a standard library to work with (yet), but the most diverse group of existing programs would probably be at https://github.com/orange-lang/orange/tree/master/test.

That's a good point; I updated the README to note that the language is still under development.

And yeah, as for https://github.com/orange-lang/orange/tree/master/lib/libor, it only contains bootstrap code for the linker at the moment.