For more context, I'm using a java library which returns an object of type Value, but this object does not seem to have the members I think it should have. I try to call methods on this object which I think should exist, but appear not to. I tried importing the Value class directly, and when creating the object directly, the expected methods are there. After doing trying to cast the returned object to the type that works, i see this difference in class names, one starting with an L.

List

Lovely stuff, thanks

I think it's defined here: https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.3.2

also note the [ (= array), so I think [L; is an array of objects of some class

I poked around on why it’s L recently and I think the L is a historical reference to Lvalues (references)

But yes, that’s the internal name for an array of Value

user> (class (into-array []))
[Ljava.lang.Object;
user> (class (into-array [(into-array [])]))
[[Ljava.lang.Object;

Thanks guys, I was a bit stumped but this is useful JVM knowledge for Java interop

1. While true that Clojure does not encourage framework, there are web development frameworks in Clojure such as Xiana, Biff and Kit. Xiana was developed by Flexiana (http://flexiana.com) and they did a kind of benchmark comparing the speed of development (among other things) between frameworks of different languages.

An experienced engineer with a good foundation in Clojure can deliver projects very efficiently by selecting and the most relevant libraries together and wiring them together. There is also reach into the vast JVM libraries should that be required (even jruby). There are de-facto standards (Ring, hiccup) which provide data abstractions over common protocols. As most software projects are about recieving and transforming data, then Clojure.core is the most used 'framework', with around 700 ways to work with data. Rails project ar suited to delivering projects that fit the approach and constraints for the rails framework. It is common to hit a wall when needing to move off the rails. There also seems to be a challenge in maintain rails project and manage changes from the rails project. This may be due to the limited number of people doing rails (hence high salaries from companies tied into rails)

I would not trust a random redditor claiming that a Rails developer can pull down 350k over the stack overflow developer survey. There are a fair number of staff-level and site reliability engineers who don’t make that much, and their skills are considerably rarer than knowing how to work effectively with rails.

(I'm aware this is the same-old Clojure goodness list, but what you can do) • strong emphasis on immutable data • interactive development via REPL • functional programming • strong emphasis on a stable API (for what I hear Ruby and Rails don't score well here but I might be wrong) • being a dynamic language and having a compact syntax (Ruby is great as well on this front, IMHO) The compound value on the elements above puts any other language I tried (and I pretty much tried all the mainstream ones) out of competition, hence personally I'm not looking back. The rationale pages in the official Clojure website (http://clojure.org) and many, many blogs (https://itrevolution.com/articles/love-letter-to-clojure-part-1/ is a good one) gives more detailed explanations. But there's no way around trying it for real to build something non trivial (eg, half day hacking trial might be fun, but not long enough) to sense the difference. No guaranteed you're going to be persuaded 🙂 Prospects: Clojure is a niche language. Employers tend to complain they can't find devs with it, personally I've always seen companies complaining on lack of talent for any tech stack they use. Recruiting is broken, skills building is left to the technologist themselves (I'm OK doing this myself, but I'd like companies being more proactive here) and those are problems bigger than a single language. Definitely I'd bet that with Clojure a company might receive fewer CVs but of better quality (good luck finding a good candidate in a big pile of Java or JS candidate CVs). Salary: many Clojurians are solid professionals with a good degree of seniority, and shifted to this language purposefully, I suspect this is the main reason why Clojure results often as a high salary language. Let's not forget that the same Clojurians swear to be so much productive with this particular language, it might appear expensive on the surface but it's actually a bargain! 🙂

Re: Speed to deliver to build a MVP It's going to depend on the team. Sounds like you and your team are new to Clojure so you're going to be pretty slow to build anything with it, until you all get fluent -- which can take longer than coming up to speed with other tech since most other (mainstream) tech is similar, while Clojure (and other FP languages) is very different in terms of how you think about things. As others have said, if you have a team that is fluent in Clojure, they could well outperform a Rails team. Perhaps not in the barebones "get an ugly crud app working" but certainly in anything vaguely bespoke -- which almost all apps are in reality (Rails might get you the 80% very quickly but then you'll be fighting the framework all the way for that last 20% -- and some companies have built MVPs in Rails, only to throw them away and rebuild in a different language to ensure that 20% doesn't take them 80% of their time to market 🙂 ).

Re: Salary I think a lot of the "highest paid" aspect of Clojure is that it tends to attract more senior devs and you can get a lot done with a small team, so you hire a few seniors instead of a bunch of lower paid devs. I'm not sure if there are survey results showing age/salary graphs across multiple tech stacks?

You start from zero only once and the MVP is only the beginning. With any tool set, as you work longer with similar clients or similar needs, the work gets literally easier. RoR's reputation is that it is easy-at-the-outset -- easier than Clojure, let's stipulate -- but RoR is not as flexible and does not get much easier after that; it is backbreaking toil that begs for cheap labor; while on the other hand the migration of Ruby professionals to Clojure (e.g., at Relevance) suggests that Clojure gets sufficiently easy with practice; and in particular, that Clojure saves time if the frame of scrutiny extends beyond the MVP in any dimension.

This relates to my 1st question. I know Clojure community emphasises on vast JVM libraries (to get up to speed instead of reinvent the wheel). For this one, I am still not really clear. • Does it mean for Clojure, I can call any Java libraries out there? Really true? So it also means I can use Spring Boot, Quarkus, Ktor or any Java libraries with Clojure? Though lack of documentations using these frameworks/libraries, is another challenge. • I still struggle to wrap my head. As Clojure is functional, calling an OOP library, not sure is a good or bad thing. Example, Clojure can handle concurrency really well, but somehow I rely on a Java library that doesn't handle concurrency well. Hmm, does it really work? • It also seems I need to have a good Java foundation. Otherwise, how would I know which Java library to use? I guess those who dislike Java, most likely won't pickup Clojure. I also read somewhere in reddit that we don't need to know Java to be productive in Clojure. Again, not sure it makes sense. If you don't know Java, then how to know which library to use in Clojure (assume need to use some library rather than re-invent the wheel). • How about libraries written in another JVM hosted language like Kotlin? Can Clojure call them too?

One more thing to ask and if not mistaken, Clojure main selling point is to have a stable code base. This also means Clojure 1.12 won't have any breaking changes if I upgrade Clojure 1.10 or 1.11 to it. However this is from language standpoint. Will it have any breaking on those clojure libraries using older version as some clojure libraries are quite dated. Example jwt, last update 2015. This is something I am thinking. Like Rails, seems when there is a new version, it seems to introduce new stuff and features. Not a bad thing, but need to put efforts to upgrade. Similar to Flutter 1 to Flutter 2, due to null safe. Need to put efforts to upgrade.

> I can call any Java libraries out there Yes. Some libraries are easier to work with than others but, yes, you can call any Java library from Clojure. Working with frameworks that expect to call your code can be a bit more challenging (those are not libraries) but it is mostly still possible via gen-class. > As Clojure is functional, calling an OOP library, not sure is a good or bad thing Clojure is pragmatic. If you need to use an OOP library to get the job done, you can usually make that work. > I rely on a Java library that doesn't handle concurrency well A concrete example? > I need to have a good Java foundation. Otherwise, how would I know which Java library to use Ask. Many people are productive in Clojure without knowing any Java. Some aspects of JVM knowledge can be helpful. Java != JVM. > how to know which library to use in Clojure Ask, or do your own research. That applies in any language. > How about libraries written in another JVM hosted language like Kotlin Mostly, yeah. Some languages do weird stuff at the JVM level so you have to know how to do that interop -- but that's the same as calling them from Java. Scala libraries can be a bit tricky I believe, unless they provided a nice Java API. Some JVM languages are better than others at being callable from Java or Clojure or whatever. > This also means Clojure 1.12 won't have any breaking changes if I upgrade Clojure 1.10 or 1.11 to it Mostly. The core team are very careful not to break things -- that's a core tenet of Clojure development in general. > some clojure libraries are quite dated Clojure libraries tend to be focused on a single, self-contained problem and so they can be "done". It's rare that a Clojure library is "broken" on an updated Clojure language version (but it does happen occasionally). At work, we have 145k lines of Clojure. Some of that code was written for Clojure 1.3 back in 2011 and it still runs unchanged. We have run almost every alpha and beta version of Clojure since then in production -- so, not only is it almost always 100% backward compatible, it is also stable as a rock. We're currently running Clojure 1.12 Alpha 9 in production.

Clojure is extremely unusual in terms of its stability -- and that extends to the whole community: breakage is considered extremely bad... change should only ever be purely additive or purely fixative. Immutable data at the core is what gives Clojure a lot of its power in terms of eliminating a whole class of bugs and making concurrency pleasant (I won't say "easy" but almost).

For this At work, we have 145k lines of Clojure. Some of that code was written for Clojure 1.3 back in 2011 and it still runs unchanged. We have run almost every alpha and beta version of Clojure since then in production Do you mean the code written for Clojure 1.3, will work with Clojure 1.12 Alpha 9 (with no changes)? Assume your production, you have already upgraded to latest Clojure. Or you have Clojure 1.3 codebase running together with Clojure 1.12 Alpha 9? How about the JDK side? Assume back then Clojure 1.3, maybe you used Java 6. Now using Java 21. No breaking? In Clojure, it's common to use Alpha and Beta versions? What's the basis? I assume to use latest, in case Clojure core fixes some vulnerabilities, etc? Do you also upgrade to latest Java LTS as well, assume there is a new version? I assume Clojure won't break either?

I saw this post https://www.reddit.com/r/Clojure/comments/y5kjhi/lets_build_a_list_of_clojure_unicorns/ I wonder, how come quite a number healthcare companies using Clojure? There are also banks like Nubank, Griffin, etc. Is it due to these companies heavily invested into JVM or something? As some enterpise, they tend to think JVM is like heaven sent. Assume Java has its edge especially integrating legacy systems via SOAP XML Web Services. Wonder this is the main reason to use Clojure? or they really need Clojure due to immutability, etc?

> Do you mean the code written for Clojure 1.3, will work with Clojure 1.12 Alpha 9 (with no changes)? Assume your production, you have already upgraded to latest Clojure. Correct. Some parts of that large codebase were written for Clojure 1.3 and still run unchanged on the latest Clojure version. The codebase overall has been written over 13 years and all the old code still runs unchanged. The Clojure team is very careful to preserve backward compatibility. > How about the JDK side? Assume back then Clojure 1.3, maybe you used Java 6. Now using Java 21. No breaking? The jump from Java 8 to Java 9 was quite painful -- because of 3rd party Java libraries we were using that were not compatible with Java 9 and were very slow to update (we switched from Redisson to Jedis, and wrote our own connection pooling function in Clojure because Redisson was so slow to become Java 9 compatible). The JDK version updates rarely cause problems for Clojure. As I recall we went from Java 6 to 7 to 8 pretty easily. Java 9 was a big deal. Java 11 was easy. We developed on 13, then updated everything to 14 (so dev was 11 -> 13 -> 14, prod was 11 -> 14). Then we developed on 15, 16, 17 and updated production to 17. Then we updated everything to 18, then 19 -- ran into a couple of memory leaks in that JDK and went back to 18 until 20 came out (which fixed both JDK leaks), then updated everything to 21. > In Clojure, it's common to use Alpha and Beta versions? What's the basis? I assume to use latest, in case Clojure core fixes some vulnerabilities, etc? I don't know that it's common but we've always done it with almost no problems. We do it for two reasons: 1) to help the Clojure core team with testing (e.g., 1.12 Alpha 2 introduced a bug as part of a performance update that we helped find -- so we had to skip a couple of alpha versions in production while that was being debugged and fixed) 2) to start using the new features each release provides Sometimes in the alpha versions, a feature is introduced and then changed across several alphas based on feedback from the community -- and then we have to make changes because we adopted the alpha version of the feature and then it changed before beta -- but we're fine with that (the new Java method values interop stuff is a case in point: we updated our code to take advantage of the new feature, but after further design work and feedback, the core team need to change the syntax slightly, so we will need to change 8 lines of code to adapt to the new syntax when the next alpha drops. > Do you also upgrade to latest Java LTS as well, assume there is a new version? I assume Clojure won't break either? As noted above, we use non-LTS JDK versions too. Occasionally there are changes that affect Clojure, e.g., introducing a new overload on Thread/sleep has introduced reflection in some calls that previously didn't need it, which is a "breaking" change for us only because our CI pipeline checks for reflection and fails the build if new reflection warnings appear in our code.

I can't speak to why other companies use Clojure but, for us, it provides a lot of leverage -- we manage the entire backend of our online dating platform, running 40 sites and apps, with just two developers -- and it eliminates whole classes of bugs (due to immutability). Clojure lets us think at a higher level, since it is based on abstractions at its core, and we've found that we can respond to changing business requirements faster because of that. We were already JVM-based before Clojure, so migrating to Clojure was an incremental process for us. I've been on the JVM since 1997, across all sorts of companies both large and small, and it's a great platform for any long-running processes.

Thanks for sharing @U04V70XH6 its an eye opener 🙂