scmeta
rewrite in Clojure
#96
niklas-heer
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have tried to rewrite the
scmeta
tool from Crystal to Clojure, and personally, I find the Clojure code to be much more simple and beautiful, but I have one question and one challenge.I did this because I wondered how a functional approach to the
scmeta
tool would look like, and since I'm handling mainly data Clojure seemed like a good fit. The second reason was just curiosity on my end if it would be hard to do or not, and it was actually pretty straightforward to do.Both source codes as a comparison
Clojure code
speed-comparison/scmeta/scmeta.clj
Lines 3 to 105 in 310f79c
Crystal code
speed-comparison/scmeta/src/scmeta.cr
Lines 1 to 155 in ad10524
Crystal downsides
Preface: I'm new to Crystal and Ruby.
While there seems to be some support for functional programming, I've seen some discussions on the Crystal language like adding support for more functional language features similar to Elixir, but it seems that not many have made it in yet. It feels to me like Crystal is primarily an Object-Oriented programming language (OOP).
That is not a bad thing in itself, but I would like to do more functional code to get better at it.
The question
If I were to choose the Clojure implementation, would it make it less accessible for contributions?
The challenge
I have chosen Go (in the past) and Crystal for the speed-comparison tooling because they are both languages capable of producing portable static binaries. Meaning that I can build them in a first step with earthly and copy the binary into each language container with no additional installation requirements. Which is a pattern which works great.
Solution one: build a native Clojure binary using GraalVM (seems hard)
For Clojure, I either would have to build a native binary with GraalVM which from the brief look I took seems quite challenging to do.
Solution two: rework how the result JSON is built
The other option would be to use the filesystem, let every run write the results into a file, and then generate the combined JSON afterwards. The version command could also just output the stdout into a file, same goes for the language name.
But that would render having a separate language besides Python somewhat pointless because the analysis step in the end could just do that as well.
Final thoughts
I feel that what I gain in simplicity on the implementation side of
scmeta
would be eaten up by making the build or comparison execution more complex. 🤔Maybe another solution could be to just use the analysis step with Python and write functional Python code.
I'm genuinely interested what others think of this.
Beta Was this translation helpful? Give feedback.
All reactions