4 ms·

Isn't Fluentd in Ruby though? It's 2015 and we need something like this in Go [0] [1] or Rust [2]. [0] Heka: https://hekad.readthedocs.org/ https://hekad.readt

by kolev 11y ago

Isn't Fluentd in Ruby though? It's 2015 and we need something like this in Go [0] [1] or Rust [2]. [0] Heka: https://hekad.readthedocs.org/ https://hekad.readthedocs.org/ [1] Chainsd: https://github.com/mikeszltd/chainsd https://github.com/mikeszltd/chainsd [2] Flogger: https://github.com/jedisct1/flowgger https://github.com/jedisct1/flowgger

jedisct1 11y ago
Fluentd is pretty fast, with the critical parts being written in C. It's fast enough for most applications while providing a lot of flexibility.
- kolev 11y ago
  Well, written in Go or Rust, it could have both the readability of Ruby, the performance of C/C++. Having critical parts in C and the rest in Ruby is worse.
allengeorge 11y ago
Why does the language it's written in matter? If it has the features you want, the reliability you want, and performs well given the load you're applying - that should be enough, no? It's not like we're embedding it into an app we're writing.
- 102030485868 11y ago
  Well, in terms of maintenance it's a little bit more work. Sure, it has the features and reliability. But does that really justify having to maintain a completely new environment? Maybe it does, maybe it doesn't; it depends. No you may not be embedding it in your app, but it's now a part of your stack. You'll need to keep an eye on updates, etc for a completely different environment. Plus there are other factors, like approved languages. Certain companies only allow using languages X and Y. Don't even think about language Z. I had to re-write an 80loc Python script to a much larger Perl one because I just didn't grok Perl all too well at the time. It didn't matter that Python was installed on the system. All that mattered was that Perl was approved and Python was not.
  - allengeorge 11y ago
    Valid points. I'd like to address the "completely new environment" issue though. That should only be considered if you're thinking of owning and modifying the component. There are many software packages that you're going to use as-is, and interact with only via an API or CLI. In those cases the depth of the API/CLI, the quality of its documentation and the strength of its community matter way more than implementation language. (For example - who cares if nginx is written in C although your entire stack is Python or Java?) If you're thinking of continually making changes in a package however - that's a different matter.

by kolev 11y ago

jedisct1 11y ago

Fluentd is pretty fast, with the critical parts being written in C. It's fast enough for most applications while providing a lot of flexibility.

kolev 11y ago
Well, written in Go or Rust, it could have both the readability of Ruby, the performance of C/C++. Having critical parts in C and the rest in Ruby is worse.

allengeorge 11y ago

Why does the language it's written in matter? If it has the features you want, the reliability you want, and performs well given the load you're applying - that should be enough, no? It's not like we're embedding it into an app we're writing.

102030485868 11y ago
Well, in terms of maintenance it's a little bit more work. Sure, it has the features and reliability. But does that really justify having to maintain a completely new environment? Maybe it does, maybe it doesn't; it depends. No you may not be embedding it in your app, but it's now a part of your stack. You'll need to keep an eye on updates, etc for a completely different environment. Plus there are other factors, like approved languages. Certain companies only allow using languages X and Y. Don't even think about language Z. I had to re-write an 80loc Python script to a much larger Perl one because I just didn't grok Perl all too well at the time. It didn't matter that Python was installed on the system. All that mattered was that Perl was approved and Python was not.
- allengeorge 11y ago
  Valid points. I'd like to address the "completely new environment" issue though. That should only be considered if you're thinking of owning and modifying the component. There are many software packages that you're going to use as-is, and interact with only via an API or CLI. In those cases the depth of the API/CLI, the quality of its documentation and the strength of its community matter way more than implementation language. (For example - who cares if nginx is written in C although your entire stack is Python or Java?) If you're thinking of continually making changes in a package however - that's a different matter.