12 ms·

I'd love to see clojure take a bigger role in the financial services sector. The fact that it runs on the JVM, gives it a nice foot in the door. Ideally, it w

by tharne 6y ago

I'd love to see clojure take a bigger role in the financial services sector. The fact that it runs on the JVM, gives it a nice foot in the door. Ideally, it would be great if clojure replaced Python and Scala as the defacto language used to interact with Apache Spark. That's probably not likely, though. It's hard enough to get a lot of folks past spark's weirdness without throwing a lisp into the mix. But it does seem like a functional JVM language that's not Scala would be the optimal way to use spark.

lmilcin 6y ago
See... I work for one of the largest banks in the world and in vicinity of me there is a Clojure project. The guys are trying to figure out how to get rid of it. Original developers left the company or advanced to management roles and now nobody is able to figure out what this convoluted, obfuscated, undefined, unstructured mass of code does or how to modify it so that it doesn't blow up more that it already is. As much as I love Clojure I see the problem is you need really good (not just intelligent but also wise) developers to reap benefits. Otherwise you can run into huge problems. "With great power..." Clojure has so bad rep here that even I think I made a mistake that I let on that I use it for my projects.
- tharne 6y ago
  That's unfortunate, but I see your point. It's a real catch-22. If you build everything in Java it's harder to attract good devs, but if you use something like Clojure you need to attract those good devs.
  - Pet_Ant 6y ago
    > Clojure you need to [keep] attract[ing] those good devs. This isn't one and don, people move on even from the best jobs. You know need to keep replacing them, explain to HR why this "req" (requisition - aka job opening) needs them to look at resumes differently. Why they can't pull from their Java pool of resumes, explain to your director why you aren't like all the other teams. It's a lot of friction.
  - jjtheblunt 6y ago
    perfectly said
- sambe 6y ago
  I have noticed that people often use such criticisms against anything they aren't familiar with. If you can find an enthusiastic polyglot who says the same then it becomes a bit more believable. And - of course - the fact that it is so unfamiliar to most is probably a valid criticism anyway.
  - lmilcin 6y ago
    The truth is that the candidates we are receiving are barely able to code in Java. Not all know differences between linked lists and arrays and if they know what a breakpoint is they are hired. Now, imagine giving the people environment that imposes no structure on your project and gives hyper powerful tools like macros and you are in a big problem. At least with Java you get Spring and this is how you do endpoint, this is how you connect to the database, and so on. The structure is suboptimal and redundant but at least they are getting some guidance which are most likely already familiar with. In Clojure, as a lead of the project, you would have to do the same but now it would be up to you to define all of that guidance. The question is, are you better at this than entire organization that supports Spring? The only situation I see where Clojure would realistically be beneficial is when you only get like world class developers who know what they are doing and can work together. I can't work on a Clojure project with a person that is unable to go through something like Let over Lambda with full understanding of the code examples and trust they will be able to make good decisions when building abstractions with macros.
    - Bootvis 6y ago
      I don’t understand why you can’t get better candidates. I understand that things go wrong with bad developers but how is it that you can’t get those folks that can write somewhat good Clojure independently?
      - lgessler 6y ago
        I don't know what sector GP is in but there are plenty of programming jobs (maybe even most?) where the company (usually one where tech generally is incidental to their operations) really isn't in a position to offer a salary that's competitive enough to hire this way. I'd say most programming jobs at US hospitals are this way, for instance.
- pinchhit 6y ago
  This absolutely matches my experience as a full time Clojure dev at multiple companies. Leadership is desperate to replace the code with something more maintainable. It's gotten bad enough that I will switch languages for my next job, the headaches are not worth it.
  - deleted 6y ago
    [deleted]
  - burnthrow 6y ago
    Clojure is quite maintainable, a well-written Clojure program is small and clear, easy to modify. Pervasive immutability is a huge win; Clojure programs are big on referential integrity. There's some doublespeak going on here. When "leadership" says "maintainable" what they mean is that the project is recoverable after they frog march the project lead out the door, or lay off the team, or the team quits because the job blows. Their view of maintainability is dominated by Bus Factor and similar existential concerns, rather than agility experienced by the project's authors. They actually want the opposite of maintainable: Rigid and heavily specified.
    - pinchhit 6y ago
      This is not what I meant by maintainable. The companies I've programmed clojure in were sizable and bet on it for their entire stack, and hired very sharp senior people to work on them. Even there, the projects suffered so much to hit release dates and stay understandable as the system grew that velocity suffered relative to peers doing experiments in traditional OO languages. In fact, the maintenance burden (for code composed by smart senior people!) is so high that it's actually convinced me on the virtue of regular OO/procedural languages over lisp.
      - kazinator 6y ago
        > it's actually convinced me on the virtue of regular OO/procedural languages over lisp. This is an example of the problem of Clojure being promoted as Lisp. There are now people whose idea of what is "Lisp" is represented by Clojure. You might like coding in a normal, procedural Lisp with OOP, but due to a bias induced by Clojure, you don't suspect that's even a thing.
- hotcrossbunny 6y ago
  Maybe if you make it known that you have some Clojure projects and that it might have even a possibility of a future with you, you might be able to attract and hire some good devs
  - lmilcin 6y ago
    But we do. There are publicly advertised open Clojure positions and I have been cold called or contacted on LinkedIn because I let on that I know Clojure. To which I must politely say I am already working for this company.
    - hotcrossbunny 6y ago
      Yep, I guess that is pretty ironic. If your roles are open to London/remote, I would be happy to take a look
      - deckeraa 6y ago
        Same here. I've got current availability to do contract work and could take on some Clojure dev if that's what they need.
- dustingetz 6y ago
  What % of Java projects fail again? With Java, your convoluted mess is 100k to millions LOC. With Clojure, the same devs make the same convoluted mess but in 10k to 100k LOC, and you've left the door open for an inspired "true Scotsman" to come in and do the whole thing in 5k. But management has to understand that, and of course the principle agent problem, peter principle, politics, conways law ... Java is great for middle managers, it makes their department headcount grow, and they get to pretend the project is succeeding because nobody can tell otherwise.
  - lmilcin 6y ago
    With Java, your convoluted mess can be parsed by IDE and you can figure out what it is doing. Also, most of it looks the same and is Ctrl+c, Ctrl+v of something else. With Clojure the mess is still 100k to millions LOC because the guys did not know how to make worthwhile abstractions, but now it can't be parsed by IDE and you are screwed trying to figure out what happens at runtime. ALso, if you think if there is less code then it is easier to understand, go and read any advanced Common Lisp book (like Let over Lambda) and try to really understand what some of the more advanced macros do, exactly. It is definitely not the same as reading pages upon pages of redundant code.
    - taeric 6y ago
      This doesn't match my experience. I've had to deal with some Java code that the ide was useless to help figure out. Usually made worse by some over optimized build system that was non Google friendly to see what was supposed to happen. Worse, the abstractions made it so that even a simple feature would require about six files. Not counting the tests. Not to say that clojure has been a breeze. Worst I see there is developers refusing to use libraries it external programs and instead taking a ridiculous "first principals" approach. Even if they get it working, it is typically not search friendly, as everyone else is using some other tool. Basically, the same trap I see in build systems,
      - jimbokun 6y ago
        > I've had to deal with some Java code that the ide was useless to help figure out. Spring annotations, maybe?
- clusterhacks 6y ago
  I am also a long-time Clojure user and have production projects built in Clojure. I think your observation that you need really good developers is the key insight to problems that come about from using Clojure. Stu Halloway even mentions it in the interview: "And what we would quite often see is that people would write a Java app in Clojure, or people would write a Ruby on Rails app in Clojure. And not surprisingly, it would have weaknesses that you associate with idiomatic Java apps or idiomatic Ruby on Rails apps" Clojure, as a language, makes it very easy to do stuff and sometimes that stuff means making code look like code that only makes sense in other languages. This is a terrible mistake but one that is easy to understand. Very few developers have any real background in functional programming and it is too easy to start hacking things together. As a longtime Clojure user (dating back to attending the very first Clojure conference in Durham, North Carolina), I think there has been a little bit of "ego-driven" developer syndrome with projects in the language. There is definitely a tendency for new Clojure programmers to get too fancy. This is not a problem with Clojure the language though. I made the mistake myself in early projects. The more I have used Clojure, the more I have realized that when I am doing it right, I am spending significantly more time understanding the problem I am solving than throwing code together . . .
- didibus 6y ago
  > and now nobody is able to figure out Ok, but how much of that is just them not knowing Clojure? I've found people that get handed down a code base in a different language tend to hack their way around it, instead of like, pausing for a minute, take some time to learn the language, and then come back to it. Maybe in your case it was a terrible code base of low quality, but I'm just curious.
  - lmilcin 6y ago
    The problem isn't knowing or not knowing Clojure. The worst codebases (and that is true of other languages just as for Clojure) that I have seen are ones done by people who are intelligent enough to learn every feature of their language and any little trick available on the internet but haven't yet had the chance to acquire the wisdom on when to use them or what to use them for.
    - thisiszilff 6y ago
      I guess the appeal of clojure in that case is that the language is a lot simpler than other languages.
- nnp7000 6y ago
  Citi?
  - deleted 6y ago
    [deleted]
- dustingetz 6y ago
  Re any large Clojure projects needing modernization or migration to new stack – I would be happy to take care of projects like this, tech debt is not a problem for us, email me dustin@hyperfiddle.net
- appletrotter 6y ago
  I also work at a large bank, I can see why clojure wouldn't work for a bank. I would blame the bank for being incompatible with clojure more than the other way around though.
naringas 6y ago
Nubank (a Brazilian based startup-style fintech company) does everything with clojure (on AWS). They bought Plataformatec makers of the Elxir lang.
- mst 6y ago
  The entire interview is with a Nubank employee, who talked about more clojure in finance as a result. I think OP was riffing on that.
- Scarbutt 6y ago
  Yep,and they were forced to buy Cognitect too to deal's with their Clojure/Datomic mess.
  - dgb23 6y ago
    Can you substantiate that claim?
    - tincholio 6y ago
      If you look at his post history, you can see he has a thing for trolling in any thread about Clojure.
  - simongray 6y ago
    Why this obvious bait?
wokwokwok 6y ago
? You can already use clojure with spark[1]. ...but just as pyspark is not “pythonic”, clojure spark is super unidomatic to use. ...which is why its languished unused. I mean, an idiomatic library isn’t impossible; see how databricks has wrapped the pandas api up with its koalas project; you just have invest the time and effort and actually make it.... for what, fundamentally, is a total absence of demand. or do you mean like first party support for clojure? Thats never going to happen... [1] https://github.com/gorillalabs/sparkling/ https://github.com/gorillalabs/sparkling/
- hotcrossbunny 6y ago
  Does this framework speak to the mismatch in idiomatics? https://github.com/zero-one-group/geni https://github.com/zero-one-group/geni Not asking from any point of expertise mind you, having only stumbled across this literally this morning
ashtonkem 6y ago
I used Clojure in financial services, specifically at a trading firm. When I left we’d stopped writing new Clojure services, and had started to replace existing ones with Java. Finance, at least in our area, turned out to be a pretty tough place for Clojure’s style of dynamic typing. For those that don’t know, Rich Hickey (and by extension, Clojure) is really big on data-first dynamic typing. So idiomatically you’re supposed to do most of your work in Clojure using their first-rate immutable collections library, primarily maps and their sequence abstraction. Clojure provides some mechanisms for specialized domain objects, but it’s fair to say that this is typically considered non-idiomatic. This works great if one of the following conditions are true: 1) All data flows through your system on separate tracks. Foo’s come in from foo endpoints and go to the foo database, and very rarely do data sets cross paths. Differences in business logic can be separated by API endpoint, kafka topic, or some other difference that lets you separate the call paths thoroughly. 2) Every type of data in your system looks different, so that you can easily determine whether or not a given piece of data is a foo or a bar once and send it down the right call path in one place. 3) In any case where similar types of data must be treated differently, it’s possible to organize your code in such a way that you only have to build up the cond-tree once, and you can use different call paths to treat the data differently. All of these were often false for us. We ended up in situations where we had lots of data that looked very similar entering from common endpoints that required different business logic at multiple points in the pipeline. If you’re writing idiomatic Clojure this is the toughest case possible, as you end up littering your code with extremely similar cond-trees, which makes extension and verification unnecessarily hard. In most other languages, even dynamic ones, you’d solve this via sub-classing to both group common behavior and allow specialization. Clojure provided some tools to make this work, but they were both maintenance nightmares in their own separate ways. My favorite is how the results of defrecord (which makes class-like maps in Clojure) could be treated like a map, except certain map operations could accidentally turn it back from a record to a regular map. That’s quite the foot gun, trust me. For our team, we decided that pure Java was the way to go. Java by that point had started adding a lot of boilerplate eliminating niceness, including lambdas and streams, and the ability to make honest-to-god subclasses really helped out in our specific domain.
- raspasov 6y ago

by tharne 6y ago

lmilcin 6y ago

See... I work for one of the largest banks in the world and in vicinity of me there is a Clojure project. The guys are trying to figure out how to get rid of it. Original developers left the company or advanced to management roles and now nobody is able to figure out what this convoluted, obfuscated, undefined, unstructured mass of code does or how to modify it so that it doesn't blow up more that it already is. As much as I love Clojure I see the problem is you need really good (not just intelligent but also wise) developers to reap benefits. Otherwise you can run into huge problems. "With great power..." Clojure has so bad rep here that even I think I made a mistake that I let on that I use it for my projects.

tharne 6y ago
That's unfortunate, but I see your point. It's a real catch-22. If you build everything in Java it's harder to attract good devs, but if you use something like Clojure you need to attract those good devs.
- Pet_Ant 6y ago
  > Clojure you need to [keep] attract[ing] those good devs. This isn't one and don, people move on even from the best jobs. You know need to keep replacing them, explain to HR why this "req" (requisition - aka job opening) needs them to look at resumes differently. Why they can't pull from their Java pool of resumes, explain to your director why you aren't like all the other teams. It's a lot of friction.
- jjtheblunt 6y ago
  perfectly said
sambe 6y ago
I have noticed that people often use such criticisms against anything they aren't familiar with. If you can find an enthusiastic polyglot who says the same then it becomes a bit more believable. And - of course - the fact that it is so unfamiliar to most is probably a valid criticism anyway.
- lmilcin 6y ago
  The truth is that the candidates we are receiving are barely able to code in Java. Not all know differences between linked lists and arrays and if they know what a breakpoint is they are hired. Now, imagine giving the people environment that imposes no structure on your project and gives hyper powerful tools like macros and you are in a big problem. At least with Java you get Spring and this is how you do endpoint, this is how you connect to the database, and so on. The structure is suboptimal and redundant but at least they are getting some guidance which are most likely already familiar with. In Clojure, as a lead of the project, you would have to do the same but now it would be up to you to define all of that guidance. The question is, are you better at this than entire organization that supports Spring? The only situation I see where Clojure would realistically be beneficial is when you only get like world class developers who know what they are doing and can work together. I can't work on a Clojure project with a person that is unable to go through something like Let over Lambda with full understanding of the code examples and trust they will be able to make good decisions when building abstractions with macros.
  - Bootvis 6y ago
    I don’t understand why you can’t get better candidates. I understand that things go wrong with bad developers but how is it that you can’t get those folks that can write somewhat good Clojure independently?
    - lgessler 6y ago
      I don't know what sector GP is in but there are plenty of programming jobs (maybe even most?) where the company (usually one where tech generally is incidental to their operations) really isn't in a position to offer a salary that's competitive enough to hire this way. I'd say most programming jobs at US hospitals are this way, for instance.
pinchhit 6y ago
This absolutely matches my experience as a full time Clojure dev at multiple companies. Leadership is desperate to replace the code with something more maintainable. It's gotten bad enough that I will switch languages for my next job, the headaches are not worth it.
- deleted 6y ago
  [deleted]
- burnthrow 6y ago
  Clojure is quite maintainable, a well-written Clojure program is small and clear, easy to modify. Pervasive immutability is a huge win; Clojure programs are big on referential integrity. There's some doublespeak going on here. When "leadership" says "maintainable" what they mean is that the project is recoverable after they frog march the project lead out the door, or lay off the team, or the team quits because the job blows. Their view of maintainability is dominated by Bus Factor and similar existential concerns, rather than agility experienced by the project's authors. They actually want the opposite of maintainable: Rigid and heavily specified.
  - pinchhit 6y ago
    This is not what I meant by maintainable. The companies I've programmed clojure in were sizable and bet on it for their entire stack, and hired very sharp senior people to work on them. Even there, the projects suffered so much to hit release dates and stay understandable as the system grew that velocity suffered relative to peers doing experiments in traditional OO languages. In fact, the maintenance burden (for code composed by smart senior people!) is so high that it's actually convinced me on the virtue of regular OO/procedural languages over lisp.
    - kazinator 6y ago
      > it's actually convinced me on the virtue of regular OO/procedural languages over lisp. This is an example of the problem of Clojure being promoted as Lisp. There are now people whose idea of what is "Lisp" is represented by Clojure. You might like coding in a normal, procedural Lisp with OOP, but due to a bias induced by Clojure, you don't suspect that's even a thing.
hotcrossbunny 6y ago
Maybe if you make it known that you have some Clojure projects and that it might have even a possibility of a future with you, you might be able to attract and hire some good devs
- lmilcin 6y ago
  But we do. There are publicly advertised open Clojure positions and I have been cold called or contacted on LinkedIn because I let on that I know Clojure. To which I must politely say I am already working for this company.
  - hotcrossbunny 6y ago
    Yep, I guess that is pretty ironic. If your roles are open to London/remote, I would be happy to take a look
    - deckeraa 6y ago
      Same here. I've got current availability to do contract work and could take on some Clojure dev if that's what they need.
dustingetz 6y ago
What % of Java projects fail again? With Java, your convoluted mess is 100k to millions LOC. With Clojure, the same devs make the same convoluted mess but in 10k to 100k LOC, and you've left the door open for an inspired "true Scotsman" to come in and do the whole thing in 5k. But management has to understand that, and of course the principle agent problem, peter principle, politics, conways law ... Java is great for middle managers, it makes their department headcount grow, and they get to pretend the project is succeeding because nobody can tell otherwise.
- lmilcin 6y ago
  With Java, your convoluted mess can be parsed by IDE and you can figure out what it is doing. Also, most of it looks the same and is Ctrl+c, Ctrl+v of something else. With Clojure the mess is still 100k to millions LOC because the guys did not know how to make worthwhile abstractions, but now it can't be parsed by IDE and you are screwed trying to figure out what happens at runtime. ALso, if you think if there is less code then it is easier to understand, go and read any advanced Common Lisp book (like Let over Lambda) and try to really understand what some of the more advanced macros do, exactly. It is definitely not the same as reading pages upon pages of redundant code.
  - taeric 6y ago
    This doesn't match my experience. I've had to deal with some Java code that the ide was useless to help figure out. Usually made worse by some over optimized build system that was non Google friendly to see what was supposed to happen. Worse, the abstractions made it so that even a simple feature would require about six files. Not counting the tests. Not to say that clojure has been a breeze. Worst I see there is developers refusing to use libraries it external programs and instead taking a ridiculous "first principals" approach. Even if they get it working, it is typically not search friendly, as everyone else is using some other tool. Basically, the same trap I see in build systems,
    - jimbokun 6y ago
      > I've had to deal with some Java code that the ide was useless to help figure out. Spring annotations, maybe?
clusterhacks 6y ago
I am also a long-time Clojure user and have production projects built in Clojure. I think your observation that you need really good developers is the key insight to problems that come about from using Clojure. Stu Halloway even mentions it in the interview: "And what we would quite often see is that people would write a Java app in Clojure, or people would write a Ruby on Rails app in Clojure. And not surprisingly, it would have weaknesses that you associate with idiomatic Java apps or idiomatic Ruby on Rails apps" Clojure, as a language, makes it very easy to do stuff and sometimes that stuff means making code look like code that only makes sense in other languages. This is a terrible mistake but one that is easy to understand. Very few developers have any real background in functional programming and it is too easy to start hacking things together. As a longtime Clojure user (dating back to attending the very first Clojure conference in Durham, North Carolina), I think there has been a little bit of "ego-driven" developer syndrome with projects in the language. There is definitely a tendency for new Clojure programmers to get too fancy. This is not a problem with Clojure the language though. I made the mistake myself in early projects. The more I have used Clojure, the more I have realized that when I am doing it right, I am spending significantly more time understanding the problem I am solving than throwing code together . . .
didibus 6y ago
> and now nobody is able to figure out Ok, but how much of that is just them not knowing Clojure? I've found people that get handed down a code base in a different language tend to hack their way around it, instead of like, pausing for a minute, take some time to learn the language, and then come back to it. Maybe in your case it was a terrible code base of low quality, but I'm just curious.
- lmilcin 6y ago
  The problem isn't knowing or not knowing Clojure. The worst codebases (and that is true of other languages just as for Clojure) that I have seen are ones done by people who are intelligent enough to learn every feature of their language and any little trick available on the internet but haven't yet had the chance to acquire the wisdom on when to use them or what to use them for.
  - thisiszilff 6y ago
    I guess the appeal of clojure in that case is that the language is a lot simpler than other languages.
nnp7000 6y ago
Citi?
- deleted 6y ago
  [deleted]
dustingetz 6y ago
Re any large Clojure projects needing modernization or migration to new stack – I would be happy to take care of projects like this, tech debt is not a problem for us, email me dustin@hyperfiddle.net
appletrotter 6y ago
I also work at a large bank, I can see why clojure wouldn't work for a bank. I would blame the bank for being incompatible with clojure more than the other way around though.

naringas 6y ago

Nubank (a Brazilian based startup-style fintech company) does everything with clojure (on AWS). They bought Plataformatec makers of the Elxir lang.

mst 6y ago
The entire interview is with a Nubank employee, who talked about more clojure in finance as a result. I think OP was riffing on that.
Scarbutt 6y ago
Yep,and they were forced to buy Cognitect too to deal's with their Clojure/Datomic mess.
- dgb23 6y ago
  Can you substantiate that claim?
  - tincholio 6y ago
    If you look at his post history, you can see he has a thing for trolling in any thread about Clojure.
- simongray 6y ago
  Why this obvious bait?

wokwokwok 6y ago

? You can already use clojure with spark[1]. ...but just as pyspark is not “pythonic”, clojure spark is super unidomatic to use. ...which is why its languished unused. I mean, an idiomatic library isn’t impossible; see how databricks has wrapped the pandas api up with its koalas project; you just have invest the time and effort and actually make it.... for what, fundamentally, is a total absence of demand. or do you mean like first party support for clojure? Thats never going to happen... [1] https://github.com/gorillalabs/sparkling/ https://github.com/gorillalabs/sparkling/

hotcrossbunny 6y ago
Does this framework speak to the mismatch in idiomatics? https://github.com/zero-one-group/geni https://github.com/zero-one-group/geni Not asking from any point of expertise mind you, having only stumbled across this literally this morning

ashtonkem 6y ago

I used Clojure in financial services, specifically at a trading firm. When I left we’d stopped writing new Clojure services, and had started to replace existing ones with Java. Finance, at least in our area, turned out to be a pretty tough place for Clojure’s style of dynamic typing. For those that don’t know, Rich Hickey (and by extension, Clojure) is really big on data-first dynamic typing. So idiomatically you’re supposed to do most of your work in Clojure using their first-rate immutable collections library, primarily maps and their sequence abstraction. Clojure provides some mechanisms for specialized domain objects, but it’s fair to say that this is typically considered non-idiomatic. This works great if one of the following conditions are true: 1) All data flows through your system on separate tracks. Foo’s come in from foo endpoints and go to the foo database, and very rarely do data sets cross paths. Differences in business logic can be separated by API endpoint, kafka topic, or some other difference that lets you separate the call paths thoroughly. 2) Every type of data in your system looks different, so that you can easily determine whether or not a given piece of data is a foo or a bar once and send it down the right call path in one place. 3) In any case where similar types of data must be treated differently, it’s possible to organize your code in such a way that you only have to build up the cond-tree once, and you can use different call paths to treat the data differently. All of these were often false for us. We ended up in situations where we had lots of data that looked very similar entering from common endpoints that required different business logic at multiple points in the pipeline. If you’re writing idiomatic Clojure this is the toughest case possible, as you end up littering your code with extremely similar cond-trees, which makes extension and verification unnecessarily hard. In most other languages, even dynamic ones, you’d solve this via sub-classing to both group common behavior and allow specialization. Clojure provided some tools to make this work, but they were both maintenance nightmares in their own separate ways. My favorite is how the results of defrecord (which makes class-like maps in Clojure) could be treated like a map, except certain map operations could accidentally turn it back from a record to a regular map. That’s quite the foot gun, trust me. For our team, we decided that pure Java was the way to go. Java by that point had started adding a lot of boilerplate eliminating niceness, including lambdas and streams, and the ability to make honest-to-god subclasses really helped out in our specific domain.

raspasov 6y ago