With pkg [1][2] and nexe [3] you can package ClojureScript on Node.js applications as a static binary. Of course, Go would be better in terms of size/performance, so it's now a matter of making tradeoffs between relative size/performance and team productivity. But at least for teams using Clojure/ClojureScript, this gives you that an additional option, where none existed.
With nexe [1][2] and pkg [3] you can now package ClojureScript on Node.js as a static binary, and startup time is now a lot better compared to Clojure on JVM. Go would definitely be better in terms of speed and performance. So it's a tradeoff to make between relative size, performance and having a single language stack, increased team productivity and reduced team overhead.
A fairly high percentage. I guess filtering for candidates who are polyglot developers comfortable in more than one language helps. The fact that Clojure is used acts as a filter for self-driven and "better programmers" [1].
Well, I found it found it hard to hire Clojure developers too. But I addressed it by hiring good to competent developers, asking if they are willing to learn Clojure and then getting them to implement a test project in Clojure as part of the interview process. Since Clojure is syntactically not huge, it is easy to pickup, for good developers. That's my hiring pipeline. ;)
Is this the only big success story for Clojure or other companies using the Lisp family of programming languages? I know there is Paul Graham's Viaweb. [1] Does anyone know of other examples?
I like the fact that they are a practical company, using Go when needed where "static dependency compilation and fast start-up are more important". I wonder if the ClojureScript's annoucement on integration of NodeJS modules [2] changes that? Also, Lumo [3] is definitely a move in the right direction for this, addressing the slow start-up times for Clojure/ClojureScript, making it suitable for shell scripts and CLI binaries.
> Having a lingua franca also helps reduce overhead when engineers want to move between layers of the stack.
The way I see it, Clojure allows you to use a single language and syntax from the super heavy backend stuffs, to the front end and now to small, fast CLI tools and scripts. A candidate for the "Business English" of the technical world as it were.
Depends whether you learn best by reading [1], answering some interactive questions/koans [2], or downloading and playing around with a ToDoMVC app example [3][4][5] or a mixture of the above. Feel free to join the #clojurian Slack channel [6] if you need help.
As a beginner, I recommend you looking at the Reagent [7] or Rum [8] React library first, than you can look at something more complex and full-featured like Om [9] later (whose author is also a ClojureScript core contributor @swannodette).
PS: You can also learn by implementing a Dashboard like this [10]. Disclaimer: I am the author of this library.
That's very true, one of the key aspects that I use for picking a language is the huge ecosystem. Enough cannot be mentioned about the ecosystem of libraries and tools. With Clojure, you can leverage it to lift the heavy server-side stuff like Spark, Hadoop, and use the same syntax basically for the browser UI and mobile.
One thing I really like about Clojure is how the language has basically stayed the same, but I can use it on the heavy server-side stuffs like working with Hadoop, Spark, ElasticSearch to the front-end stuff like React, React Native, to CLR and now into nodejs, while staying sane [1] in the process. It feels like comparing a nice tropical island paradise to a crowded, hectic, mutating market, where everyone is competing for your attention and selling their newest wares.
Thanks for sharing your experiences in such an open manner. It certainly takes much courage and bravery to shutting down your service and even more so, writing honestly about it.
Could I ask you a few questions:
- Is it true to say that if this product required less maintenance (in terms of uptime, server administration, future migration), you would not have abandoned it?
- Secondly, assuming that you are not against raising external funding (which you are not in favour of, as mentioned in your blog post) and hiring the right team for it, would it be fair to say that you would be willing to continue with Charm?
- Lastly, and hypothetically, if Freckle and your other opportunities were not around, would you have continued with Charm? Would it be fair to propose that because of the high maintenance required by Charm upon you and your team, the opportunity cost is simply too high, relative to the other options that you have?