4 ms·

Author mentions Clojure a few times as an example of shiny-thing. Ironically, it's one of the few languages that I can reliably do in the browser, on the backen

by lvh 7y ago

Author mentions Clojure a few times as an example of shiny-thing. Ironically, it's one of the few languages that I can reliably do in the browser, on the backend (on real servers or say, Lambdas), and build native binaries for -- which addresses the later "many tools" problem better than a "boring" programming language like Ruby. Unless you don't care about frontend code I guess :-) (Overall this talk is fine! I think the problem/technology set illustration is particularly useful. I run Latacora's Cloud practice and we own all production infrastructure and "no, more boring, boringer than that, keep going" is a good way to describe what that looks like. We deploy half a dozen projects with exactly the same zero config storage and in ECS Fargate because I'm not managing servers.)

sydd 7y ago
But: - good luck finding a Clojure programmer if your current one quits. - good luck finding answers for your exotic bug/performance issue etc. Code is a liability, it's much more than language/VM/compiler features
- lvh 7y ago
  I've ran multiple org that are largely or almost exclusively working in Clojure(Script) and trained over a dozen folks to be proficient Clojure programmers, and have not found that any of those to be a problem. For example: you mentioned debugging serious performance problems, but the JVM has some of the most advanced instrumentation on any platform. This is actually a point subtly made in the talk: your real production problems are probably going to be a lot more subtle than "oh, it's Python's fault". It's "this table ends up getting VACUUMd a lot and a minor version change made the disk size required 3% bigger and that combined with natural growth and a logging bug suddenly caused a catastrophic failure meaning everything started swapping". Yes, one point is what tool you use (a shiny new graph database is likely to be fundamentally less operationally mature than Postgres) but more important is your collective expertise in your toolbox, because a production P0 incident is a bad time to learn what autovacuum_naptime is. For example: those fancy performance debuggers probably don't work on your Lambda runtime. I don't see that as a Clojure problem, because you would've had the same thing if you wrote it in Java+Dropwizard or Flask+Python or Go (which are presumably in the boring category). Is the flip side of that argument that you should only write things in PHP, because that is what the market has decided where programmers are the most fungible?
  - Bahamut 7y ago
    As a counterpoint, I have had a developer who had wrote production ClojureScript tell me it was the worst of all worlds - it doesn't abstract away issues of the DOM and yet you still have to debug what was happening in JS and translate it over to Clojure. Another thing I noticed is that most developers who had to touch Clojure in my org all pretty much didn't like it at all.
    - lvh 7y ago
      ClojureScript compiles down to JavaScript, so yes, it is entirely possible to spell the same buggy jQuery site you would in regular JavaScript but with the parentheses on the outside and it will solve no problems for you. I don’t think it’s reasonable to say eg reagent does not solve any DOM problems. Similarly, CLJS uses the same source map standard as every other JS targeting language, so you can debug in CLJS with the tools you already use just fine. Their negative experience is based on facts not in evidence so I can’t really comment specifically. The StackOverflow community survey results suggest their experience is at least unusual.
    - cutler 7y ago
      Did you use Clojurescript Dev Tools? https://github.com/binaryage/cljs-devtools https://github.com/binaryage/cljs-devtools Whilst Clojurescript may not solve all of your JS problems re-frame is certaily an advance over React + Redux. In fact David Nolen and Clojurescript have had a big influence on the development of React.js since Peter Hunt first introduced it.
    - Scarbutt 7y ago
      Clojurescript on its own doesn't give you much for web programming and, not worth it over Javascript. It shines when combined with a react wrapper.
      - iLemming 7y ago
        > not worth it over Javascript It absolutely is. As someone who's dealt with JS/TS/Coffeescript and a bunch of other "scripts" that compile, transpile to Javascript for very long time, I can honestly say: Clojurescript today is the only truly production-ready viable alt-js PL. and you don't have to use it with React. React with immutable data structures just makes sense. Once it stops making sense for any reasons, Clojurescript community will move on to using something else.
- jcadam 7y ago
  The supply of good Clojure developers far outstrips the demand. There are a large number of us who do Java at our day jobs, and hack Clojure on our hobby projects. I can't imagine why anyone would have any difficulty finding and hiring good Clojure (or really, any functional programming language) programmers.
- Heliosmaster 7y ago
  As the other commenters said, I think you're very wrong. My anecdotal experience with posting a Clojure job online (especially in the Clojurians slack) has been several decent applicants applying in matter of a few days.
- iLemming 7y ago
  > good luck finding a Clojure programmer Why nobody ever says: "good luck finding good Javascript developers"? Or good Java programmers. Why it became a default norm: every programmer is a Javascript expert now? In my experience: hiring Javascript developers is hard - most applicants don't even know the difference between null and undefined or can't explain how prototype chain works. And even when you find someone with good experience, there's always on-boarding period: "we're using OntagularJS 1.5, oh you heard about it, but never used it? It is similar to BrokenboneJS, but with slight differences.". And then they have to learn your conventions, debate over enabled/disabled rules in your linter, etc. Whereas if you specifically try to hire programmers who previously tried and experimented with Clojure (even if you're not using it) - chances to get better candidates increases dramatically. If I had to choose between hiring five JS/TS/PHP/Java/C#/Go/etc. developers with $100K/Y salary per each or hiring only three Clojure developers for $200K/Y - I would go with the latter. ROI in that case would be much, much higher. Yes, code is a liability - one messy, inexperienced coder can do so much damage that it may take months to fix it.
  - 1ark 7y ago
    Haha, spot on! The emphasis on learning frameworks instead of learning the ins-and-outs and quirks of Javascript can't have been good either. It's interesting being an interviewing candidate when that emphasis shines through. Knowing Javascript, getting up to speed on whatever framework is used on the job is trivial in comparison.
- manishsharan 7y ago
  I have found debugging in Clojure is much easier as you could test out each function in REPL and the fact that clojure code is stateless. Debugging/refactoring a complex business rule in Java or Javascript is painful because developer end up writing humongous methods with generous sprinkling of state .
jerf 7y ago
Generally, "shiny-things" have some sort of appeal over the "boring" technology, or nobody would choose them at all. One of the places I'd say they are appropriate are in places where you have some problem where some "shiny-thing" stands head and shoulders above the "boring technology" in some particular and you can ram home those advantages well enough to overcome the other issues. For instance, if you've got a server where you're going to have several thousand clients opening a socket connection and babbling away at each other in some custom manner, starting with Erlang/Elixir is quite possibly a very good idea, because none of the "boring" tech is anywhere near as good at that, even today. But I do agree that when doing the cost/benefit analyses of these choices, far too many developers plop an unprofessional amount of weight on the "benefit" side that amounts to "it's fun to play with the pretty-shiny". (I'm still recovering from some old "NoSQL" decisions made in a context where a relational database would have been more than adequate, at most backed by something that even at the time was tested like memcached, instead of a combination of what are now completely defunct and semi-defunct databases.)
- zzzcpan 7y ago
  > I'm still recovering from some old "NoSQL" decisions made in a context where a relational database would have been more than adequate People jumped to NoSQL because of how awful a relational database actually is to operate. I guess it's easy to forget.
  - jerf 7y ago
    True, but in this context, they had a relational database, and the relational database is still there, and isn't going anywhere, so not a big win there. Plus, the real problem is that the correct solution was something that was already boring at the time, memcached. If all you literally are using a "NoSQL" database like MongoDB for is a key-value store and literally nothing else, you don't need NoSQL, you just need a boring key-value store.
  - hobs 7y ago
    To operate? Do you mean for a developer to work with? Because most RDBMs systems I have worked with are much easier on the operator than most NoSQL systems for HA/DR.

by lvh 7y ago

sydd 7y ago

But: - good luck finding a Clojure programmer if your current one quits. - good luck finding answers for your exotic bug/performance issue etc. Code is a liability, it's much more than language/VM/compiler features

lvh 7y ago
I've ran multiple org that are largely or almost exclusively working in Clojure(Script) and trained over a dozen folks to be proficient Clojure programmers, and have not found that any of those to be a problem. For example: you mentioned debugging serious performance problems, but the JVM has some of the most advanced instrumentation on any platform. This is actually a point subtly made in the talk: your real production problems are probably going to be a lot more subtle than "oh, it's Python's fault". It's "this table ends up getting VACUUMd a lot and a minor version change made the disk size required 3% bigger and that combined with natural growth and a logging bug suddenly caused a catastrophic failure meaning everything started swapping". Yes, one point is what tool you use (a shiny new graph database is likely to be fundamentally less operationally mature than Postgres) but more important is your collective expertise in your toolbox, because a production P0 incident is a bad time to learn what autovacuum_naptime is. For example: those fancy performance debuggers probably don't work on your Lambda runtime. I don't see that as a Clojure problem, because you would've had the same thing if you wrote it in Java+Dropwizard or Flask+Python or Go (which are presumably in the boring category). Is the flip side of that argument that you should only write things in PHP, because that is what the market has decided where programmers are the most fungible?
- Bahamut 7y ago
  As a counterpoint, I have had a developer who had wrote production ClojureScript tell me it was the worst of all worlds - it doesn't abstract away issues of the DOM and yet you still have to debug what was happening in JS and translate it over to Clojure. Another thing I noticed is that most developers who had to touch Clojure in my org all pretty much didn't like it at all.
  - lvh 7y ago
    ClojureScript compiles down to JavaScript, so yes, it is entirely possible to spell the same buggy jQuery site you would in regular JavaScript but with the parentheses on the outside and it will solve no problems for you. I don’t think it’s reasonable to say eg reagent does not solve any DOM problems. Similarly, CLJS uses the same source map standard as every other JS targeting language, so you can debug in CLJS with the tools you already use just fine. Their negative experience is based on facts not in evidence so I can’t really comment specifically. The StackOverflow community survey results suggest their experience is at least unusual.
  - cutler 7y ago
    Did you use Clojurescript Dev Tools? https://github.com/binaryage/cljs-devtools https://github.com/binaryage/cljs-devtools Whilst Clojurescript may not solve all of your JS problems re-frame is certaily an advance over React + Redux. In fact David Nolen and Clojurescript have had a big influence on the development of React.js since Peter Hunt first introduced it.
  - Scarbutt 7y ago
    Clojurescript on its own doesn't give you much for web programming and, not worth it over Javascript. It shines when combined with a react wrapper.
    - iLemming 7y ago
      > not worth it over Javascript It absolutely is. As someone who's dealt with JS/TS/Coffeescript and a bunch of other "scripts" that compile, transpile to Javascript for very long time, I can honestly say: Clojurescript today is the only truly production-ready viable alt-js PL. and you don't have to use it with React. React with immutable data structures just makes sense. Once it stops making sense for any reasons, Clojurescript community will move on to using something else.
jcadam 7y ago
The supply of good Clojure developers far outstrips the demand. There are a large number of us who do Java at our day jobs, and hack Clojure on our hobby projects. I can't imagine why anyone would have any difficulty finding and hiring good Clojure (or really, any functional programming language) programmers.
Heliosmaster 7y ago
As the other commenters said, I think you're very wrong. My anecdotal experience with posting a Clojure job online (especially in the Clojurians slack) has been several decent applicants applying in matter of a few days.
iLemming 7y ago
> good luck finding a Clojure programmer Why nobody ever says: "good luck finding good Javascript developers"? Or good Java programmers. Why it became a default norm: every programmer is a Javascript expert now? In my experience: hiring Javascript developers is hard - most applicants don't even know the difference between null and undefined or can't explain how prototype chain works. And even when you find someone with good experience, there's always on-boarding period: "we're using OntagularJS 1.5, oh you heard about it, but never used it? It is similar to BrokenboneJS, but with slight differences.". And then they have to learn your conventions, debate over enabled/disabled rules in your linter, etc. Whereas if you specifically try to hire programmers who previously tried and experimented with Clojure (even if you're not using it) - chances to get better candidates increases dramatically. If I had to choose between hiring five JS/TS/PHP/Java/C#/Go/etc. developers with $100K/Y salary per each or hiring only three Clojure developers for $200K/Y - I would go with the latter. ROI in that case would be much, much higher. Yes, code is a liability - one messy, inexperienced coder can do so much damage that it may take months to fix it.
- 1ark 7y ago
  Haha, spot on! The emphasis on learning frameworks instead of learning the ins-and-outs and quirks of Javascript can't have been good either. It's interesting being an interviewing candidate when that emphasis shines through. Knowing Javascript, getting up to speed on whatever framework is used on the job is trivial in comparison.
manishsharan 7y ago
I have found debugging in Clojure is much easier as you could test out each function in REPL and the fact that clojure code is stateless. Debugging/refactoring a complex business rule in Java or Javascript is painful because developer end up writing humongous methods with generous sprinkling of state .

jerf 7y ago

Generally, "shiny-things" have some sort of appeal over the "boring" technology, or nobody would choose them at all. One of the places I'd say they are appropriate are in places where you have some problem where some "shiny-thing" stands head and shoulders above the "boring technology" in some particular and you can ram home those advantages well enough to overcome the other issues. For instance, if you've got a server where you're going to have several thousand clients opening a socket connection and babbling away at each other in some custom manner, starting with Erlang/Elixir is quite possibly a very good idea, because none of the "boring" tech is anywhere near as good at that, even today. But I do agree that when doing the cost/benefit analyses of these choices, far too many developers plop an unprofessional amount of weight on the "benefit" side that amounts to "it's fun to play with the pretty-shiny". (I'm still recovering from some old "NoSQL" decisions made in a context where a relational database would have been more than adequate, at most backed by something that even at the time was tested like memcached, instead of a combination of what are now completely defunct and semi-defunct databases.)

zzzcpan 7y ago
> I'm still recovering from some old "NoSQL" decisions made in a context where a relational database would have been more than adequate People jumped to NoSQL because of how awful a relational database actually is to operate. I guess it's easy to forget.
- jerf 7y ago
  True, but in this context, they had a relational database, and the relational database is still there, and isn't going anywhere, so not a big win there. Plus, the real problem is that the correct solution was something that was already boring at the time, memcached. If all you literally are using a "NoSQL" database like MongoDB for is a key-value store and literally nothing else, you don't need NoSQL, you just need a boring key-value store.
- hobs 7y ago
  To operate? Do you mean for a developer to work with? Because most RDBMs systems I have worked with are much easier on the operator than most NoSQL systems for HA/DR.