9 ms·

Would be interested to hear their experiences with Clojure at Netflix for the 5 years that have followed since then. Did they keep writing more Clojure? If so,

Would be interested to hear their experiences with Clojure at Netflix for the 5 years that have followed since then. Did they keep writing more Clojure? If so, how much of their code is now in Clojure compared to Java? How much more did they rewrite from Java to Clojure? Do they use Clojure rather than Java for new code? What other languages do they use? Python? Erlang? Rust? How much, in terms of functionality, is written in each language they use? How many lines of code do they have in each language? To what extent did they find existing libraries for the different languages usable for what they are doing? Among the things that seemed great with Clojure in 2013, did they find that some of these were not so great after all once the codebase grew? Any other problems?

Scarbutt 8y ago
Did they keep writing more Clojure? Since Netflix likes to constantly write about their tech (videos, blog), my guess would be no, but interested in an official answer too. They are now heavy users of nodejs though. I personally ran out of reasons to prefer another dynamically-typed language over Javascript on the server (not a hard rule of course).
- abritinthebay 8y ago
  We’re heavy users of LOTS of languages at Netflix to be fair. Clojure included.
- Scarbutt 8y ago
  To clarify, the reason I prefer nodejs (for web apps) over clojure these days is the vast amount of libs and documentation for almost all your needs. Clojure has the java ecosystem, but it was very tedious (more cognitive load) investing lots of time doing interop instead of just focusing on the problem at hand. Interop is both a feature and a curse. Of course, as a language I find Clojure superior in almost every way compared to JS.
  - paulie_a 8y ago
    Honestly the vast amount of libs is the reason I don't like nodejs. It's a lot of shoddy duplicates.
    - deleted 8y ago
      [deleted]
  - yogthos 8y ago
    You can use ClojureScript on top of Node. My team started using Node for some services, and I published Macchiato based on that https://macchiato-framework.github.io/ https://macchiato-framework.github.io/
    - cutler 8y ago
      I like the idea behind Macchiato but unlike it's Clojure cousin, Luminus, there doesn't seem to be any documentation on database access. I especially like HugSQL in Luminus. Is it possible to use it with Macchiato?
      - yogthos 8y ago
        There is macchiato-sql [1] which is modeled on HugSQL. I've used it for a couple of projects, but YMMV. I tend to use sequelizejs since it works with most databases and it's well documented. [1] https://github.com/macchiato-framework/macchiato-sql https://github.com/macchiato-framework/macchiato-sql
        cutler 8y ago
        Bejesus, Sequelize.js is a LOT more work than HugSQL. I keep looking at Macchiato but without a Clojurescript database layer I can't see it being useful.
        yogthos 8y ago
        I mean if you're on Node, it's not going to be any better with plain Js either. Stuff like this is precisely why I prefer the JVM ecosystem myself.
diab0lic 8y ago
I am very glad you asked! I wrote and deployed (to production) some Clojure code at Netflix just yesterday. Among other things at Netflix the Mantis Query Language (MQL an SQL for streaming data) which ferries around approximately 2 trillion events every day for operational analysis (SPS alerting, quality of experience metrics, debugging production, etc) is written entirely in Clojure. This runs in nearly every critical service, ~3000 ASGs and easily > 100k servers and Clojure allows us to also compile it for our NodeJS services as well.
- shadowmint 8y ago
  Thats an interesting point that doesn’t answer any of the questions the parent asked. :) Perhaps you can answer this simpler one: Netflix has been using clojure for a long time now; has that been a positive experience broadly speaking, that means clojure is still being used for new projects, or not? Having a large successful project in clojure is lovely, but much of the community’s concern around it is that its hard to maintain, and falling in popularity, broadly speaking. It would be very nice indeed to see those points addressed by a large scale user of clojure.
  - davidwparker 8y ago
    > Did they keep writing more Clojure? > I wrote and deployed (to production) some Clojure code at Netflix just yesterday. Seems like he answered at least one.
  - diab0lic 8y ago
    Hey, sorry I saw that and typed a quick response just as I woke up. I'm not usually at a computer so early in the day. I'll address these now that I'm in front of a machine. :) > Did they keep writing more Clojure? Yes but it has never been the primary language at Netflix. > How much more did they rewrite from Java to Clojure? Very little, if any was rewritten from Java. > If so, how much of their code is now in Clojure compared to Java? A very small amount given that it isn't the primary language and Clojure code bases tend to be much smaller than Java. > Do they use Clojure rather than Java for new code? This is a personal choice each engineer makes when they write new code. Those who like Clojure might reach for it more often. Clojure is also easy to use within the environment at Netflix since everything was JVM based. > What other languages do they use? Python? Erlang? Rust? NodeJS and Javascript, Python, Ruby all have a seat at the table but the majority of back-end code at Netflix is on the JVM, the majority of that is Java. > Among the things that seemed great with Clojure in 2013, did they find that some of these were not so great after all once the codebase grew? Any other problems? I've always found larger Clojure code bases to be a bit unwieldy. Fortunately you can usually continue to abstract and keep the size small. If you choose your abstractions carefully you can get a lot of mileage out of this. I've found the lack of static typing to be a bit of a pain at times especially when refactoring. My safety net for this in the project mentioned in the GP post is to have comprehensive unit tests. If I were to initiate this project today I'd likely explore using Spec to make type assertions.
saosebastiao 8y ago
I noticed a lot of clojure codebases at amazon in 2013 (I was looking because I was learning clojure at the time). It took a look about three years later and most of them were either ported to java or scala, or dead. There were a few still running, but it looked like they were not actively developed or maintained. In my experience at amazon that likely meant they were zombie services (running but nobody used them and nobody thought to take them down), which is surprisingly prevalent at amazon. But I guess it could also mean that they were running and were so amazingly stable that they didn't need maintenance, which would be a good thing.
- jatins 8y ago
  > running but nobody used them and nobody thought to take them down Experienced the same, and these services just kept hoping through the teams. And why is it so hard in Amazon to know if someone is using a service? At one point our manager asked us to shut down a service to see if someone was using it.
  - jhall1468 8y ago
    > And why is it so hard in Amazon to know if someone is using a service? At one point our manager asked us to shut down a service to see if someone was using it. Don't collect any usage statistics works. In our org we're switching a lot of smaller services to lambda and using fewer and fewer EC2 instances to do our work. But then, we actually track usage on every service so there's that.
  - CyberSun 8y ago
    Don't know how long it has been that you've left, but this is no longer an issue. There's a discovery mechanism now that keeps track of all service to service interactions. Also, that's a strange suggestion, couldn't you have just looked at request count metrics?
- CyberSun 8y ago
  Our team has been using it pretty consistently for the last three years. There's a few other teams I know of that uses it, but I wouldn't say it's common. We rewrote more than half our systems from Java to it. We've kept the Java code that was already in good shape, moved the rest to Clojure. Most of the new systems we've built in the last three years were done in Clojure. Though it's up to the engineer in charge of the project, eventually most everyone on the team has embraced Clojure, and willfully chooses it as their JVM language of choice when starting a new project. Maintenance wise it has been way better then Java. Even with our team being around 10 devs, which is pretty big. We've had no issues extending our systems, adding features or fixing bugs. We have more stable systems actually, and our tickets count has drastically gone down. Though it's a little unfair, in that some of those systems are rewrites from Java to Clojure, thus our second attempt, and so we might have learned some things from that also. Most everyone eventually seems to come around to loving it. Like once they are familiar with it enough. At least with regards to Java they like it better, and some who've had Scala experience also seem to prefer it. All in all, I don't think anyone on the team has any regrets in choosing Clojure, and are actually quite pleased. We're planning to continue to use it, and hopefully have the whole code base be in Clojure. The weird thing is, you always feel like you wish you had types to help a little with the data flow, and knowing what part to update if you ever change the data model. As well as miss a bit of the auto refactoring tools java provided. But, when we retrospect, it's never really because it's causing us issues like the code base being unmanageable, or refactoring taking us longer to do. It is much more of a feeling, than an actual practical issue. Akin to how driving without your seat-bell on gives you that constant unease of not having it there just in case. That said, we love not having types everywhere adding noise to the code, and the ease of interactivity it offers from the REPL, and being able to focus more on our data model in terms of data (as opposed to types), and focus on our code's behavior (as opposed to types). So its a trade off, that for the last three years, hasn't caused us any issues.

Scarbutt 8y ago

Did they keep writing more Clojure? Since Netflix likes to constantly write about their tech (videos, blog), my guess would be no, but interested in an official answer too. They are now heavy users of nodejs though. I personally ran out of reasons to prefer another dynamically-typed language over Javascript on the server (not a hard rule of course).

abritinthebay 8y ago
We’re heavy users of LOTS of languages at Netflix to be fair. Clojure included.
Scarbutt 8y ago
To clarify, the reason I prefer nodejs (for web apps) over clojure these days is the vast amount of libs and documentation for almost all your needs. Clojure has the java ecosystem, but it was very tedious (more cognitive load) investing lots of time doing interop instead of just focusing on the problem at hand. Interop is both a feature and a curse. Of course, as a language I find Clojure superior in almost every way compared to JS.
- paulie_a 8y ago
  Honestly the vast amount of libs is the reason I don't like nodejs. It's a lot of shoddy duplicates.
  - deleted 8y ago
    [deleted]
- yogthos 8y ago
  You can use ClojureScript on top of Node. My team started using Node for some services, and I published Macchiato based on that https://macchiato-framework.github.io/ https://macchiato-framework.github.io/
  - cutler 8y ago
    I like the idea behind Macchiato but unlike it's Clojure cousin, Luminus, there doesn't seem to be any documentation on database access. I especially like HugSQL in Luminus. Is it possible to use it with Macchiato?
    - yogthos 8y ago
      There is macchiato-sql [1] which is modeled on HugSQL. I've used it for a couple of projects, but YMMV. I tend to use sequelizejs since it works with most databases and it's well documented. [1] https://github.com/macchiato-framework/macchiato-sql https://github.com/macchiato-framework/macchiato-sql
      - cutler 8y ago
        Bejesus, Sequelize.js is a LOT more work than HugSQL. I keep looking at Macchiato but without a Clojurescript database layer I can't see it being useful.
        yogthos 8y ago
        I mean if you're on Node, it's not going to be any better with plain Js either. Stuff like this is precisely why I prefer the JVM ecosystem myself.

diab0lic 8y ago

I am very glad you asked! I wrote and deployed (to production) some Clojure code at Netflix just yesterday. Among other things at Netflix the Mantis Query Language (MQL an SQL for streaming data) which ferries around approximately 2 trillion events every day for operational analysis (SPS alerting, quality of experience metrics, debugging production, etc) is written entirely in Clojure. This runs in nearly every critical service, ~3000 ASGs and easily > 100k servers and Clojure allows us to also compile it for our NodeJS services as well.

shadowmint 8y ago
Thats an interesting point that doesn’t answer any of the questions the parent asked. :) Perhaps you can answer this simpler one: Netflix has been using clojure for a long time now; has that been a positive experience broadly speaking, that means clojure is still being used for new projects, or not? Having a large successful project in clojure is lovely, but much of the community’s concern around it is that its hard to maintain, and falling in popularity, broadly speaking. It would be very nice indeed to see those points addressed by a large scale user of clojure.
- davidwparker 8y ago
  > Did they keep writing more Clojure? > I wrote and deployed (to production) some Clojure code at Netflix just yesterday. Seems like he answered at least one.
- diab0lic 8y ago
  Hey, sorry I saw that and typed a quick response just as I woke up. I'm not usually at a computer so early in the day. I'll address these now that I'm in front of a machine. :) > Did they keep writing more Clojure? Yes but it has never been the primary language at Netflix. > How much more did they rewrite from Java to Clojure? Very little, if any was rewritten from Java. > If so, how much of their code is now in Clojure compared to Java? A very small amount given that it isn't the primary language and Clojure code bases tend to be much smaller than Java. > Do they use Clojure rather than Java for new code? This is a personal choice each engineer makes when they write new code. Those who like Clojure might reach for it more often. Clojure is also easy to use within the environment at Netflix since everything was JVM based. > What other languages do they use? Python? Erlang? Rust? NodeJS and Javascript, Python, Ruby all have a seat at the table but the majority of back-end code at Netflix is on the JVM, the majority of that is Java. > Among the things that seemed great with Clojure in 2013, did they find that some of these were not so great after all once the codebase grew? Any other problems? I've always found larger Clojure code bases to be a bit unwieldy. Fortunately you can usually continue to abstract and keep the size small. If you choose your abstractions carefully you can get a lot of mileage out of this. I've found the lack of static typing to be a bit of a pain at times especially when refactoring. My safety net for this in the project mentioned in the GP post is to have comprehensive unit tests. If I were to initiate this project today I'd likely explore using Spec to make type assertions.

saosebastiao 8y ago

I noticed a lot of clojure codebases at amazon in 2013 (I was looking because I was learning clojure at the time). It took a look about three years later and most of them were either ported to java or scala, or dead. There were a few still running, but it looked like they were not actively developed or maintained. In my experience at amazon that likely meant they were zombie services (running but nobody used them and nobody thought to take them down), which is surprisingly prevalent at amazon. But I guess it could also mean that they were running and were so amazingly stable that they didn't need maintenance, which would be a good thing.

jatins 8y ago
> running but nobody used them and nobody thought to take them down Experienced the same, and these services just kept hoping through the teams. And why is it so hard in Amazon to know if someone is using a service? At one point our manager asked us to shut down a service to see if someone was using it.
- jhall1468 8y ago
  > And why is it so hard in Amazon to know if someone is using a service? At one point our manager asked us to shut down a service to see if someone was using it. Don't collect any usage statistics works. In our org we're switching a lot of smaller services to lambda and using fewer and fewer EC2 instances to do our work. But then, we actually track usage on every service so there's that.
- CyberSun 8y ago
  Don't know how long it has been that you've left, but this is no longer an issue. There's a discovery mechanism now that keeps track of all service to service interactions. Also, that's a strange suggestion, couldn't you have just looked at request count metrics?
CyberSun 8y ago
Our team has been using it pretty consistently for the last three years. There's a few other teams I know of that uses it, but I wouldn't say it's common. We rewrote more than half our systems from Java to it. We've kept the Java code that was already in good shape, moved the rest to Clojure. Most of the new systems we've built in the last three years were done in Clojure. Though it's up to the engineer in charge of the project, eventually most everyone on the team has embraced Clojure, and willfully chooses it as their JVM language of choice when starting a new project. Maintenance wise it has been way better then Java. Even with our team being around 10 devs, which is pretty big. We've had no issues extending our systems, adding features or fixing bugs. We have more stable systems actually, and our tickets count has drastically gone down. Though it's a little unfair, in that some of those systems are rewrites from Java to Clojure, thus our second attempt, and so we might have learned some things from that also. Most everyone eventually seems to come around to loving it. Like once they are familiar with it enough. At least with regards to Java they like it better, and some who've had Scala experience also seem to prefer it. All in all, I don't think anyone on the team has any regrets in choosing Clojure, and are actually quite pleased. We're planning to continue to use it, and hopefully have the whole code base be in Clojure. The weird thing is, you always feel like you wish you had types to help a little with the data flow, and knowing what part to update if you ever change the data model. As well as miss a bit of the auto refactoring tools java provided. But, when we retrospect, it's never really because it's causing us issues like the code base being unmanageable, or refactoring taking us longer to do. It is much more of a feeling, than an actual practical issue. Akin to how driving without your seat-bell on gives you that constant unease of not having it there just in case. That said, we love not having types everywhere adding noise to the code, and the ease of interactivity it offers from the REPL, and being able to focus more on our data model in terms of data (as opposed to types), and focus on our code's behavior (as opposed to types). So its a trade off, that for the last three years, hasn't caused us any issues.