[HN Gopher] Building a Startup on Clojure
___________________________________________________________________
Building a Startup on Clojure
Author : drikerf
Score : 156 points
Date : 2022-10-04 15:06 UTC (7 hours ago)
(HTM) web link (wobaka.com)
(TXT) w3m dump (wobaka.com)
| alfl wrote:
| Echoing some of the other posters here: Clojure is fantastic,
| hiring (several) Clojure developers is hard.
|
| Conversely, you can also get to the end of your roadmap quickly
| (Clojure being great) and end up overstaffed.
|
| There's a different line to walk with languages like Clojure.
|
| Source: I walked this line.
| kubb wrote:
| Why not hire good non-Clojure devs and bootcamp them in Clojure
| over a month?
|
| Ah, you probably want to pay them 70k/year.
| thih9 wrote:
| Wouldn't these two average each other out long term?
| bhanumanish wrote:
| jwr wrote:
| Having built a business on Clojure: I'd highly recommend it.
| Stable, developed in a mature way over many years, with a
| fantastic and mature community.
|
| Together with ClojureScript it's one of very few solutions for
| writing server/browser apps with shared code, which enables
| interesting economies.
| udkl wrote:
| I would love to read a little about partsbox and the clojure
| behind it. Do you have an article published ?
| jwr wrote:
| No, I don't, but I probably should write one. I write about
| my experiences in various posts/comments from time to time,
| but that is lost after several minutes, as The Internet moves
| on to the next shiny thing :-)
| iLemming wrote:
| I have not built a business with Clojure and I wouldn't
| recommend it. For the reason that I'm hoping one day to build
| one and beat the averages. Stay away from Clojure, or else...
| :)
| [deleted]
| ithrow wrote:
| Besides being fun for sure because you can use whatever you want
| for your own stuff I don't see what's special about clojure here.
| They are using react (behind a wrapper), IME, clourescript is not
| worth the hassle. On the server they are using ring/compojure
| which is similar to js/express, python/flask that can get the job
| done equally well in this case. The story would be more
| interesting if they were using something like datomic instead of
| postgres since datomic is were clojure could differentiate
| itself.
|
| Keep in mind that they have to juggle between almost four
| different languages, Java, Javascript, Clojure and Clojurescript,
| almost because there are differences between Clojure and
| Clojurescript. Instead of for example just using one language:
| JS.
| jwr wrote:
| > clourescript is not worth the hassle
|
| ClojureScript is one of the main reasons why Clojure makes
| sense in my business. I can use the same language and share the
| same business logic code between the server and the browser
| app. That's huge!
|
| Also, I avoid a load of problems related to communication and
| serialization, because the native serialization format is EDN,
| e.g. Clojure data structures. There is no need to adapt your
| data structures to the limitations of, say, JSON.
| thih9 wrote:
| If using the same business logic is one of the main reasons,
| why not JavaScript / TypeScript?
|
| Also, what are the limitations of JSON that EDN handles
| better?
| jwr wrote:
| JavaScript is one of the few languages that works well both
| in the browser and on the server side. I don't think this
| is the time or the place to explain why I didn't write my
| software in JavaScript -- let's just say that I don't think
| I could handle the incidental complexity in my team of size
| 1.
|
| As for JSON, others have replied, but my point was perhaps
| not very well made. It's not just the limitations of JSON
| itself. By using the same language on both sides, I can
| avoid adapting to the limitations of any transit format. In
| other words, I can (pretty much) pass native data
| structures through and get them out on the other side. In
| my case, that means not just maps and vectors, but also
| sets, keywords, or UUIDs. Can this be done with JSON? Sure!
| But then I'd have an entirely new bug area to deal with
| (encoding/decoding, forgetting to coerce, etc).
| kaba0 wrote:
| Arguably the JVM is a better backend platform, due to
| better performance, observability, scalability, parallelism
| (it is not even a competition, and then we haven't even
| talked about Loom), plus the least objective point of mine,
| more stable, battle tested libraries.
| ithrow wrote:
| That's like saying that C++ is a better backend platform
| than the JVM due to better performance. For 95% of
| business web apps out there it doesn't matter, I mean,
| multiple business with evaluations in the billions of
| dollars have been created with runtimes 50x slower than
| nodejs.
|
| Nodejs competes with Java in single threaded performance,
| I'll say normal JS code is faster than normal Java code.
| For web services that are IO bound, nodejs still competes
| with Java unless you go with all the batshit crazy
| complex reactive stuff in the Java world, supposedly is
| going to get better with the new green threads
| implementation.
| kaba0 wrote:
| You may have missed the other 10 reasons I listed besides
| performance.
|
| Also, no JS code will be faster than Java. While both
| have insanely good JIT compilers that can output some
| truly, often surprisingly great machine code, java is
| all-around faster, if for no other reason, due to its
| killer GCs.
| [deleted]
| ajgrover wrote:
| I don't use Clojure but based on a quick search, EDN is
| extensible so you can serialize things like datetimes and
| UUIDs with type information rather than as plain strings
| leiferik wrote:
| Some advantages of EDN:
|
| * Can represent sets `#{1 2 3 4 "foo" "bar" true false}`
| (JSON only supports arrays)
|
| * Maps/sets can contain arbitrary EDN as keys/values. `{[1
| 2] "foo", 5 :a, "5" :b, true -1, false 5}` or `#{[1 2] #{3
| 4} (5 6)}` (JSON only supports string keys on "objects")
|
| * Supports clojure types like keywords (`:foo`, `:bar/baz`)
| and symbols (`foo`, `bar/baz`), and can be extended to
| support other values as well
| kaba0 wrote:
| I could probably look it up myself, but does EDN support
| comments?
| dimitar wrote:
| Yep, two types in fact, line comments with ; and a
| discard sequence - you can tag code that is read (so it
| must be correct), but then discarded. We have edn files
| that are well documented with comments.
|
| https://github.com/edn-format/edn#comments
| kaba0 wrote:
| I thought so -- then it is strictly better than JSON.
| jdminhbg wrote:
| EDN also contains support for date and UUID literals, the
| former of which is a huge pain when using JSON and
| needing to communicate which standard you're using and
| remember to encode/decode on each side of the wire.
| thom wrote:
| Plus you can even write your own reader literals to
| enhance your data format. Aero does this well/horribly
| depending on your taste but it's a cool mechanism for
| declarative formats.
| ithrow wrote:
| 1. Objects are sets of keys
|
| 2. JS has Map/Set which allow other composite types as
| keys and can be converted to objects for JSON
| serialization then deserialize back to Map/Set.
| joshlemer wrote:
| Yeah but still you have to admit, there's quite a lot
| more friction and ambiguity in that approach. Do I
| represent a map as [ ["key",
| "value"], ["otherKey", "otherValue"] ]
|
| or [ {"key": "key", "value":
| "value"}, {"key": "otherKey",
| "value":"otherValue"} ]
|
| or something else? And how can I distinguish between
| values which just happen to look like maps but are
| actually not maps? And what if the service I'm talking to
| does it differently? What if I'm comparing or sorting two
| JSON values, don't I have to modify the
| equality/hashcode/ordering logic now to interpret
| [ ["key", "value"], ["otherKey",
| "otherValue"] ]
|
| and [ ["otherKey",
| "otherValue"], ["key", "value"] ]
|
| as being equal and implement a new hashcode/ordering
| which treats them as equal?
|
| Quite a lot easier when this is just native to the
| format.
| outworlder wrote:
| > If using the same business logic is one of the main
| reasons, why not JavaScript / TypeScript?
|
| Because Clojure is better designed. As are many other
| languages.
| ar7hur wrote:
| We built Wit.ai on Clojure and it was one of the best decisions
| we've ever made.
|
| Most engineers we hired has no prior experience but learned
| quickly. It gave us a great advantage to hire the best.
| georgeoliver wrote:
| It was interesting to me the author seems to use 'old-school'
| Clojure, for lack of a better phrase, with lein as the build
| tool, etc., rather than more recent tools/stacks; I don't use
| Clojure myself, is my impression off?
| jwr wrote:
| Something being "more recent" doesn't necessarily make it
| better :-)
|
| I use leiningen, too. I tried other approaches, but had trouble
| getting them to do everything that I need (for example, AOT
| compilation of the entire code that goes into the final .jar),
| and I couldn't really see any massive advantages.
| synthc wrote:
| deps is more flexible, but I you just want to run a repl, build
| and deploy code then lein still works fine.
|
| I usually default to leiningen: I can't be arsed to spend time
| configuring deps to do what lein does out of the box. (For
| example: building an uberjar)
| onion2k wrote:
| If I was choosing a language to base the tech stack for a startup
| on these days I'd be very reluctant to pick anything that didn't
| have a local user group. Slightly more esoteric languages that
| enable you to write better code faster are brilliant, but if
| you're successful enough to grow quickly, or you can raise
| funding, you'll need to hire devs relatively early on. If you've
| chosen a stack that's _too_ esoteric then this will be a huge
| blocker to making any real progress.
|
| When I did my last startup we switched from a Python API to Node
| for this reason. Python is a great language but there are _no_
| devs available where I live. I can 't even imagine considering
| Clojure unless I was in a major tech hub.
|
| The move to remote work is probably going to be a _massive_
| benefit to building in less mainstream languages.
| bsder wrote:
| > Python is a great language but there are no devs available
| where I live.
|
| Wow. Where on Earth do you live? Real question, not being
| sarcastic.
|
| Presumably not the US. I've found Python developers even in
| some fairly small towns (approx 25K people).
| mradek wrote:
| Also a point for node: in the time people have argued about how
| node sucks (some valid points, all easily mitigated) and how X
| is better, they could have already shipped a bunch of nice
| features.
|
| Focusing only on web stuff.. If you have a good grasp of design
| patterns and you can build out your system in a modular way, I
| think node is a great starting point.
|
| I love starting with node because typescript is awesome, the
| performance is nice, the community support is tremendous, the
| scaling is easy, and finally it's easy to move off it. If some
| part of the system starts becoming a bottleneck, just swap that
| piece out for something more suitable. One thing I like about
| this time right now is that most things are built just fine to
| be used in creating something new and useful products.
| outworlder wrote:
| > If you've chosen a stack that's too esoteric then this will
| be a huge blocker to making any real progress.
|
| Clojure is... esoteric now? I would understand if we were
| talking about, I don't know, INTERCAL. But Clojure? Is Scala
| 'esoteric' too?
|
| > Python is a great language but there are no devs available
| where I live.
|
| Ah, I see. Yeah, by that measure Clojure will be esoteric
| indeed. Python developers being rare is very surprising.
| kaba0 wrote:
| Maybe exotic is a better word? It is certainly not seen as
| often as Java is, but it is no Malbolge.
| AyyWS wrote:
| last 6 months job listings from itjobswatch.co.uk
|
| Python - 23,146
|
| Java - 19,800
|
| Scala - 2,274
|
| Clojure - 291
| DrBenCarson wrote:
| Counterpoint: building in esoteric languages can serve as a
| filtering mechanism in and of itself. Given how broad the
| swaths of JavaScript and Java developers are, they can be much
| more hit-or-miss.
| Huh1337 wrote:
| Counterpoint counterpoint: Esoteric languages attract PL
| nerds, who are much more interested in using every
| new/different "expressive" feature of the language than in
| getting business done using clear code understandable by
| anyone on almost any level.
| jmfldn wrote:
| Counterpoint X 3
|
| True. But if you have a good well-enforced, sane style
| guide, then expressive powerful languages can be a good
| thing. If you hire devs who care more about playing with
| the language than delivering value then you're hiring the
| wrong people. You can't ditch these languages because some
| people are sometimes attracted to them for the wrong
| reasons.
| tensor wrote:
| I actually did start a company using Clojure. All these
| points are true. Yes, it helped filter candidates in the
| early days, and also helped attract people to jobs that
| might otherwise not be that interesting or competitive.
| It's difficult for pre-funded companies to compete with
| the FANG companies.
|
| However, there were negatives. At the time the Clojure
| library landscape was less mature. Clojure developers
| would also tend to abandon projects to create "the next
| best version" which made migrating and keeping up with
| the libraries of the day difficult. Most of the libraries
| were very rough around the edges too. On the other hand
| we could use any Java library which was a boon.
|
| As the team grew, it became harder and harder to hire
| people in larger numbers. Especially in a single
| timezone. Also it became apparent that many of the people
| who were very happy in the early days, were increasingly
| less happy as we added standardization and protocol to
| our dev process. As some commenters pointed out many of
| the people attracted to Clojure liked playing with the
| latest and greatest, and things were "boring" when they
| couldn't work with whatever the latest fast changing
| trend in the community was. Trying to teach people
| Clojure also an issue. For some it was challenging, and
| for others, they were not really interested in using it.
|
| It was a good learning experience, but I don't think I'd
| do it again. There is something to be said for using
| "boring" technology for the majority of your tech stack.
| kochb wrote:
| I also founded a company which built a large portion of
| our backend on Clojure, using it through Series C. Your
| experience matches ours verbatim.
| brokenkebab2 wrote:
| I must note switching from novelty to boring phase is a
| crisis which every growing project will come through once
| it starts to expand its workforce. I saw it in teams with
| very average tech stack many times.
| WFHRenaissance wrote:
| Counterpoint Part 4:
|
| Esoteric languages by-nature have smaller populations of
| devs. They demand higher salaries for their specialist
| work. This can hurt you as you scale - salaries continue
| to increase (secularly), and the pool of possible
| engineers begins to shrink within your locale.
| jmfldn wrote:
| Yep. This is also true.
|
| Hopefully WFH helps there. In my niche Scala it does. We
| can hire more broadly. We also hire ppl with an aptitude
| for Scala and keep our style simple. That helps.
| closeparen wrote:
| If you hire developers based on the languages they know /
| think of languages and stacks as part of the long-term
| identity of a developer, then you should not use esoteric
| ones. This is well known! On the other hand significant
| parts of the industry don't do the former, so they are
| free to do the latter.
|
| As an example, nobody knows Go when we hire them to write
| it.
| rr888 wrote:
| > building in esoteric languages can serve as a filtering
| mechanism in and of itself.
|
| Yes, definitely in growth periods you get the best developers
| migrating to it. I'd say Rust is like this now. The problem
| is a few years time they'll move on to the next big thing
| leaving you stuck. I'd think Clojure is in this spot right
| now.
| vikeri wrote:
| Having been at a Clojure startup I can second this, despite
| our non existent brand we found great candidates. And
| teaching a smart junior developer Clojure wasn't harder than
| teaching people Ruby or Java. As soon as the initial lisp
| shock is over learning is much faster due to the simplicity
| (it's just data).
| jwr wrote:
| Good point! In my experience, you don't need to hire
| "Clojure developers". Look for good candidates that have
| worked with functional programming languages and you'll be
| fine. They'll get up to speed in a matter of weeks. Any
| flexible and educated developer can use Clojure, it's not
| magic.
|
| In other words, it's not about hiring a "Clojure
| developer", it's about hiring a good developer.
| onion2k wrote:
| Countercounterpoint: People can be terrible at Clojure. The
| distribution of ability probably doesn't vary much between
| languages.
| masklinn wrote:
| It absolutely does, because there's a self-selection in
| being interested in an esoteric langage (assuming it's not
| a corporate oddball or legacy langage) which raises the
| average above the background of targeting "employable"
| langages: people going through this process show more
| interest in the field.
|
| Though that doesn't mean they'll be more productive, and
| then adds hiring challenges. So the break-even is not
| simple.
|
| One of pg's early essays was on exactly that subject ("the
| python paradox).
| kagakuninja wrote:
| As a Scala dev, I had a similar belief as you: Scala
| using companies seemed to have higher calibre
| programmers. Until my current job at a major Telecom.
|
| The code is all Scala, but written by a bunch of ex-Java
| devs. I have made attempts at education, and the code is
| improving, but the fundamental structure of the services
| are bad, and there is still a lot of bad code. I am not
| saying this as a FP purist, some of the code would be bad
| by the standards of Java programming.
|
| Bad programmers then hire other bad programmers. Because
| it is hard to find experienced Scala developers, they
| have brought in people with java experience, or big data
| Python programmers who claim to have some experience
| using Scala with Spark. I am now involved in the hiring
| process, and it is slow and dismal. To be fair, the kind
| of contractors this company hires are mediocre,
| regardless of language.
|
| The features of Scala create novel ways for confused
| programmers to screw up, and we aren't even doing
| anything esoteric, like pure FP. I suspect there are some
| similar traps in Clojure.
| bcrosby95 wrote:
| Scala's problem here is largely historical.
|
| When it was released, there were two camps to adopt it:
| people that wanted an FP, and people that wanted a better
| Java. Since Java went through a long period of
| stagnation, most of the Scala code out there is written
| by Java developers that just wanted a better Java.
|
| Kotlin has stepped in and replaced Scala for "better
| Java" role. But this history has left a pile of crap code
| written by people who didn't want to use Scala.
|
| Clojure doesn't have this problem because you couldn't
| ever use it as just a better version of Java.
| throwaway5959 wrote:
| Had this exact experience trying to hire at startups for
| Scala/Spark. There's only so many Scala devs to go
| around. It also doesn't help that "good" Scala is highly
| subjective, with different levels of Scala from better
| Java to functional paradise.
|
| I've been happily coding (and hiring) in Python for the
| last four years or so. Still doing Rust and some Scala at
| home where deadlines don't exist and hiring is a non-
| issue.
| [deleted]
| drikerf wrote:
| I haven't gotten to that stage yet. But I think it's difficult
| to hire good devs for all stacks, be it Python, Ruby, JS.
| Clojure community is super friendly and full of very talented
| developers and I'd love to pay someone to write Clojure :).
|
| Yes, remote work for sure is an edge when hiring!
|
| Also reminds me of the essay "The Python Paradox" by Paul
| Graham (http://www.paulgraham.com/pypar.html)
| heneryville wrote:
| 2 years ago I was hired into a Clojure based start-up with no
| experience in Clojure. It is easy to learn, and I love it
| now. One of my duties is hiring, and we don't look for
| developers with Clojure experience. Instead we look for
| developers with good skills in any language, and trust
| they'll be able to figure out Clojure. In a way, it has
| actually widened our hiring pool since we can't be shackled
| to the XXX years of experience in YYY approach.
| gdsdfe wrote:
| Still hiring? :)
| zerr wrote:
| How long does it take for some non-Python dev to become a
| Python dev? One week? Two?
| ducktective wrote:
| While we are at it, anyone knows what's the Common Lisp story in
| webdev? Both backend and frontend?
| mejutoco wrote:
| Not an expert, but I would expect hunchentoot
| https://edicl.github.io/hunchentoot/ for the backend and a
| Common Lisp "dsl" generating javascript for the frontend.
| aidenn0 wrote:
| I am a hobbyist lisp developer and have written webapps in CL.
|
| I use cl-who[1] for generating html and parenscript for
| javascript. I use clack on the backend, but hunchentoot is
| probably more popular. Both backends have plenty of routing
| libraries available (hunchentoot comes with a decent one baked
| in, clack does not).
|
| postmodern is a Postgres specific sql backend that is great.
| There are database-agnostic SQL libraries as well (clsql and
| cl-dbi I believe are the two big ones) but I haven't tried
| them.
|
| 1: People whose opinions I trust have told me that spinneret is
| a better choice. It did not exist when I learned cl-who. cl-who
| is "good enough" for me that I haven't switched.
| ldite wrote:
| Ah clojure. It's all fun and games until five years down the
| line, you've had 100% dev churn, and you have a 100kloc codebase
| that nobody understands, full of functions that don't give the
| slightest hint of the shape of the data they're processing (it's
| all lists!) yet down the bottom of the callstack there's some
| function that'll explode if the map doesn't have whatever magical
| key it expects.
|
| If you're really lucky, someone will have thrown in a bunch of
| 'specs' that make a bunch of assertions about the data, put them
| on the API entry points, and then scattered some slightly
| different specs with slightly more restrictive assertions on
| various 'internal APIs', resulting in random explosions in
| production!
|
| And the joy of working with an esoteric language is that it
| attracts esoteric developers, who often get frustrated by the
| requirements of being a software engineer in a large company
| (i.e. everything that's not writing code), which leads to the
| aforementioned 100% dev churn (after a lot of shouting).
| tasubotadas wrote:
| > And the joy of working with an esoteric language is that it
| attracts esoteric developers, who often get frustrated by the
| requirements of being a software engineer in a large company
| (i.e. everything that's not writing code), which leads to the
| aforementioned 100% dev churn (after a lot of shouting).
|
| Wow. Pretty insightful :)
| kbuchanan wrote:
| Oh man, this is not my experience. We may be different because
| we are a small company, and Clojure is our main language. But,
| we have a Clojure codebase of 90K lines, and is 10 years old.
| It has its problems, and while your points about an opaque data
| model resonate, for us, tests, specs, and assertions provide
| enough hints to help newcomers. And... where I disagree the
| most: the quality and professionalism of the developers who
| work on it are unparalleled. New, senior-level developers,
| quickly catch on to the system. I am grateful to Clojure
| __because__ it attracts this caliber of developer.
| CyberDildonics wrote:
| What worries me the most about clojure and languages like it,
| is that seems to be for people who want to be clever with how
| they write programs, when that is the opposite of what I want
| from people I work with.
| christophilus wrote:
| Yeah. Personally, I really love writing Clojure. But I've
| never run it in production because I have the same
| reservations. I'd be the overly clever dev in this scenario.
| dustingetz wrote:
| OK but that's a 500k LOC codebase in javascript/python that
| nobody understands, maybe the project doesn't even get there
|
| everybody hates their language when they have 100k LOC of tech
| debt from 8 years ago
|
| You're right that Clojure's sequence soup problem is painful at
| that scale (really any scale) but have you ever debugged Java?
| It's barely even possible, the project needs to drive $10M+/yr
| revenue to just not collapse once it reaches 500k+ LOC Java,
| 500k XML, 300k SQL ...
| ldite wrote:
| I should have added that I've had similar experiences with
| (old school, untyped) python codebases - absent the esoteric
| programmers, which is not a small difference - although with
| python you tend to hit performance issues if your call stacks
| get too deep. Ironically the JVM performance lets you dig
| yourself into a gnarlier pit before you have to face up to
| it.
| synthc wrote:
| Disagree about Java, I've worked on several large Spring
| applications and making small changes was not a problem at
| all.
| zmmmmm wrote:
| > have you ever debugged Java? It's barely even possible
|
| hard disagree ... Java is a dream to debug. I've hacked into
| complex applications countless times by remote attaching the
| debugger and setting breakpoints to step through what they
| are doing. You don't even need source code in many cases. I'd
| pick Java ahead of any other language on that front.
| seer-zig wrote:
| Java is one of the very few languages out there that is
| manageable and debuggable at the large scales you're talking
| about. The tooling around it is second to none, and because
| it is statically typed with a decent type system, you can
| refactor quite safely in general.
|
| And let's be frank, XML, other than for Maven (where it can
| make sense), is not really a thing in modern Java.
| gered wrote:
| This is my experience exactly. I love the language and
| ecosystem in a lot of ways. I also believe that REPL-driven-
| development is a ridiculously productive way to work.
|
| But I absolutely _hate_ maintaining an old Clojure codebase
| (unless it 's tiny).
|
| The REPL helps a lot with discovering what the proper way is to
| call any random function you have in your code, but this is
| still really super annoying. I really hate to get into a
| dynamic-versus-static-typing debate, but I've long since come
| to the conclusion that -- all other things being equal (hah!)
| -- if I have to dig into a large and old project, I'd much
| rather have types by my side than not. Code will not ever be
| adequately documented or commented (and even if it _seems_ to
| be at first glance, you will always have nagging doubts about
| how up to date that info really is). This is where type
| definitions help to figure out the shape of the data that any
| piece of code is working with. People talk about adding
| spec/schema definitions but that doesn't solve all the problems
| with not having type definitions unless you add these
| spec/schema definitions _everywhere_ ... and let's face it, you
| just aren't going to do that in any Clojure project. So, best
| case scenario is you still have a large collection of functions
| in your project that are calling each other, etc that you are
| left having to deduce yourself what this random map or list
| actually contains.
| strikelaserclaw wrote:
| i'm starting to feel that REPL driven development can be bad
| for maintenance, when you have a REPL, you can write
| ridiculously compact and abstract code that is hard to
| understand just by reading it.
| synthc wrote:
| With great power comes great responsibility.
|
| When using the REPL you can quickly experiment until it
| does what you want, but you need the discipline to distill
| something maintainable from it afterwards.
| gered wrote:
| That's an interesting point I'd not thought of. I guess I'm
| more looking at it through the lens of "interacting with
| and modifying a running system" which kinda gives you a
| debugger (ish), compiler and execution environment all
| rolled into one. It's kind of nice to work in this kind of
| "scratch pad"-like environment while you figure something
| out versus the more traditional edit-compile-run cycle. But
| I have definitely seen what you describe as well, so I
| think that aspect is worth considering too, for sure.
| zmmmmm wrote:
| It's almost by definition in some sense ... if it was
| obvious how to write the code you wouldn't need the REPL so
| by definition if it is uesful it must be producing non-
| obvious code.
|
| That is a slightly shallow take though because its not
| really symmetrical like that. You _can_ use a REPL as a way
| to arrive at the most easily understood rendition of
| something. But that is very prone to subjective bias as
| lots of things seem obvious in retrospect that are not at
| the start.
|
| To the extent that the answer you eventually arrived at is
| a result of learning a mental model of the data and
| functions surround it, it will leave a significant residual
| gap for the next person who comes a long to bridge.
| z9znz wrote:
| As a Clojure admirer who has learned it enough to get things
| done (and subsequently forgotten it) twice, I recently had
| the positive REPL experience that people talk about. Or at
| least I think I did. I was able to write a web scraping tool
| almost entirely in the REPL.
|
| However, I find myself running Ruby/Rails (console) in debug
| mode in RubyMine (Jetbrains IDE). The REPL-like experience
| seems quite close to that of Clojure, with the added benefit
| of being able to easily enable and disable breakpoints and
| see my local data (and snapshots of all previous local data
| up the call stack).
|
| And honestly, the Clojure thing that always stops me from
| actually getting a full anything built is the lack of
| frameworks and approaches which have critical mass. It's
| always the same answer, "We like to choose our own
| libraries." That's lovely once you know what you're doing,
| but the ramp-up time is just SO much slower than with other
| languages.
|
| Considering the time to working proof of concept is critical
| quite often, few beginners have time to figure out all the
| libraries and tooling and integrations to build something in
| Clojure.
|
| I think despite still wishing I had a Clojure backend with
| Clojurescript/React frontend, I'll step from my Rails PoC to
| a Phoenix/Elixir product and be successful and happy (and
| have a lot of people doing something similar, with similar
| tools and libraries).
| gered wrote:
| Yeah the (what I personally call it) "choose your own
| adventure" style approach to Clojure projects, where you
| don't use a framework like Rails, but just string together
| your own project from separate libraries, is really both a
| "pro" AND a "con".
|
| It's great when you know what you're doing, and indeed, I
| have my own personal Leiningen templates to set up a
| Clojure project the way I like it and to save myself some
| time. Bigger project templates, like Luminus, I often find
| personally aggravating because I often feel like it just
| barfs a whole bunch of unnecessary and semi-complicated (in
| my opinion anyway) code in a new project even with the most
| minimal options chosen. But that's the power of the
| ecosystem ... you can create your own project templates to
| meet your own needs.
|
| But a new developer getting their feet wet in this
| ecosystem? Yeah, it is hard. And even if they use an
| existing project template like Luminus to bootstrap their
| project ... well, the project template only helps generate
| the initial project. Ongoing maintenance for updating
| dependency versions and keeping a working integration of
| the libraries it initially set up for you (with respect to
| newer versions and any API/config changes, etc) ... well,
| those responsibilities are all on you! Kit (another newer
| successor to Luminus) _may_ provide some better
| alternatives here, but it'll still be limited with exactly
| how much it can help here. But I think it's still much too
| early to say one way or the other with Kit, so who knows.
|
| (Also thanks for sharing your Ruby/Rails perspective on
| REPLs. A colleague of mine made some similar comments to me
| when we were discussing REPLs a while back, and I've not
| spent any time with Ruby so couldn't comment. It's
| interesting to hear! Most other REPLs I've used outside
| Clojure were not too useful as anything other than quick
| toys for trying short snippets outside of the context of a
| full project.)
| Mikeb85 wrote:
| Of course everything you're complaining about means that the
| company has been successful enough to get to that point...
|
| Startups that act too much like big companies just don't ever
| get product out the door and fail before you can bitch about
| technical debt...
| synthc wrote:
| I'd say 100% developer churn is the real problem here, no
| inherited 100kloc codebase is going to be a walk in the park if
| the original devs are not around.
|
| However, I do think that it harder to keep a large code base
| understandable when using a dynamic language v.s. a statically
| typed language.
|
| Having problems with understanding the shape of expected data
| is certainly a problem experienced in larger Clojure code
| bases, I guess this is just a disadvantage of using Clojure.
|
| Documentation, tests, spec/schema and good naming conventions
| can mitigate this disadvantage to some extent.
|
| I found some the advice in this blog post useful:
| https://tech.redplanetlabs.com/2021/06/03/tour-of-our-250k-l...
| invalidOrTaken wrote:
| My company (as in "I work there," not "I own it") is I think
| unique in that it started as an Elixir/TypeScript shop, things
| went seriously downhill, they brought in a new engineering team
| (I'm on it), we switched to Clojure, and we're doing fine.
|
| If I were to start a new company I'd _absolutely_ run it on
| clojure. Even without frontend /backend code reuse, REPL-driven
| dev--- _paredit_ is the killer app for me. It just makes editing
| text files, which is what we 're doing if we admit it, so much
| easier.
|
| It's a data point.
| hypersoar wrote:
| For me, the killer feature of Clojure is "REPL driven
| development". The ability to get rapid feedback as you build
| things up is incredible. I'll make a comment form and evaluate
| expressions within it to try things out as I go. By the time I've
| written any reasonably complex function, all of the pieces have
| been tested on various examples. Once I'm done, the comment form
| leaves a helpful record of my thought process.
|
| If you're wondering what's so great about the Clojure repl (and
| other lisp repls) in particular, the thing is that you never have
| to actually type something into it. You can run evaluations from
| the code file itself. The structure of lisps makes it clear
| exactly which code you want to evaluate. To do this, I use the
| excellent CIDER package for emacs. I understand Calva for VS Code
| and Cursive for IntellJ offer similar functionality.
|
| Here's a good talk on what this looks like:
|
| https://www.youtube.com/watch?v=gIoadGfm5T8
| staticelf wrote:
| I don't understand, doesn't most languages these days have a
| REPL?
| [deleted]
| pedrodelfino wrote:
| I kind of agree with you. I used to work with Common Lisp in a
| Desktop App (Nyxt browser). I had some fun playing with Racket.
| And I love Emacs. So, I am already into the Lisp idea. But, I
| was kind of disappointed with Clojure which is new in my life
| and has been used in my current job. Maybe you have a backend
| bias in your testimony?
|
| I have been working with ClojureScript (re-frame and reagent)
| on front-end stuff and, unfortunately, the REPL does not seem
| to help me that much on my workflow. I miss the REPL driven
| development, by the way... The real "interactive programming"
| seems to happen on Chrome Dev Tools + Browser's reactions to
| Chrome Dev Tools tweaks on the UI + (lastly) changes on the
| source code via the editor (Emacs in my case).
|
| Namespaces as prefix of invocations on the REPL are not that
| trustworthy on ClojureScript, apparently. It could also be that
| I am a noob and I missed something, so... How do you feel about
| ClojureScript?
| jdminhbg wrote:
| Have you tried Figwheel[0]? This is how I maintain a REPL
| into a browser-based CLJS application under development.
|
| [0]: https://figwheel.org
| drikerf wrote:
| Don't know about your exact environment but I've structured
| my code so most of it is in .cljc files which can be
| evaluated in browser and on server. This allows me to
| evaluate/test/run things easily in the emacs repl.
|
| For view code I think hot reloading has been a great thing
| with Clojure/Script too. Everything is reloaded properly and
| the state remains.
| seer-zig wrote:
| Java has `jshell`.
| bcrosby95 wrote:
| Just like C++ has automatic memory management because of the
| existence of smart pointers.
| fredrikholm wrote:
| Greenspun's tenth rule, adopted for 2022: > Any
| sufficiently complicated TypeScript or Java program contains an
| ad hoc, > informally-specified, bug-ridden, slow
| implementation of half of Clojure.
|
| Once you grokk the approach and workflow Clojure takes in solving
| problems, the distance between having an idea and writing a rock
| solid implementation of that idea is the shortest I've
| experienced in my ~20 years of programming.
|
| If you want to write succinct, transparent code whilst minimizing
| the future potential of introducing bugs, Clojure is as good as
| it gets.
| xapata wrote:
| But it doesn't have reader macros!
| synthc wrote:
| Cute, but i'll counter with this one:
|
| > Any sufficiently complicated Clojure program contains an ad
| hoc, > informally-specified, bug-ridden, slow implementation of
| half of Spring.
| bcrosby95 wrote:
| Ah, Spring - freeing Java developers from the horror of
| typing "new" since 2002.
| xapata wrote:
| Including Spring itself?
|
| Jokes aside, can't Clojure simply call whatever you want from
| the JVM?
| meerita wrote:
| Question for Clojure's pros: as a designer I started programming
| javascript for a long time, now I can do my own APIs on Node
| easily, would it be hard to do APIs in Clojure? Can you recommend
| me a video course for learn it?
| heneryville wrote:
| I learned by reading through a book, then working through
| problems on https://4clojure.oxal.org/. If you've got JS
| experience it won't take too much effort to pick up. Don't get
| too carried away with forming the perfect tail recursive pure
| functional monad or whatever. Get into just doing what you're
| trying to do quickly, then after you're competent, read other
| people's code to correct your style.
| drikerf wrote:
| Clojure is great for writing backends. Checkout Ring and
| Compojure. Simple libraries for making an API :).
| meerita wrote:
| Will check those, thanks.
| ghufran_syed wrote:
| fyi @drikerf, newsletter signup is not working, the error says
| "magic link failed to send"
| drikerf wrote:
| Wow, thanks! Recently migrated and seems something went wrong.
| Fixed now :)!
| as4hretret wrote:
| drfuzzy89 wrote:
| Always great to see more start ups being built on Clojure! For
| folks interested, this is a great talk on the same subject:
| https://youtu.be/L9KcoRZcdbc
|
| Full disclojure: I work for the company in the talk, though I'm
| not one of the presenters.
| pedrodelfino wrote:
| The pun is nice (the lecture also seems interest)! I can't
| believe I never use this pun on my Clojure job...
| marrone12 wrote:
| One thing to note about coding in Clojure -- if you never learned
| Java, you hit a wall at a certain point. I only know scripting
| languages and I had fun writing little scripts in clojure, but at
| a certain point the lack of java knowledge and it's class system
| / standard libraries held me back from doing more serious things.
| beiller wrote:
| I worked at a startup that was built on Clojure. It had trouble
| finding developers for reasonable salaries at the early mid
| stage. They decided to switch the stack to python at that point.
| Just an anecdote!
| silentsea90 wrote:
| Building a company in Python feels like a bet against yourself
| ie the company/codebase will never get big enough that using
| Python (lack of static typing etc) will ever be a problem
| throwaway5959 wrote:
| In monoliths sure, but if you're building services that are
| compact and tested it's less of an issue.
| keithasaurus wrote:
| It's pretty easy to enforce static typing in python these
| days. mypy and pyright are both pretty mature.
| ajgrover wrote:
| The problem is that coverage of typing in third party
| libraries is not that high yet, so it's not really possible
| to enforce typing in a thorough manner.
| outworlder wrote:
| If you use Python and you aren't aware of its tradeoffs, yes
| it is going to bite you.
|
| Dynamic typing and the lack of a formal compilation step are
| great for productivity, but they come at a cost. You need a
| proper CI pipeline to run linters (granted, you need that in
| statically typed languages too) and, most importantly, you
| need to write tests. Sure, you need to write tests for any
| language, but not having them for languages like Python is
| going to bite you that much harder.
|
| I've seen pretty large Python codebases that worked just
| fine. And smaller Java codebases that were unmaintainable.
| throwaway5959 wrote:
| With GitHub Actions building a solid CI pipeline has never
| been easier. I built one with linting, tests, coverage and
| packaging to ghcr in an hour this weekend for Go. Python
| would have been very similar.
| aidenn0 wrote:
| I don't know how any non-FAANG companies in the bay area hire
| non-junior developers. I have 4 kids and the difference in
| mortgage payments alone for relocating there is well into 5
| figures per year.
| jwr wrote:
| > for reasonable salaries
|
| I think this is the key here. Clojure developers are expensive
| (see the Stack Overflow charts for how being a Clojure dev
| essentially guarantees a great salary) -- but that's not
| because of them being Clojure developers, but rather because of
| them being more experienced, knowledgeable, and flexible than
| your "average" developer.
|
| If you start a business and use Clojure, you should expect to
| hire more expensive developers. You will, however, need fewer
| of them, so this might all balance out in the end, especially
| as we all know that teams don't scale infinitely.
| mylons wrote:
| re-iterating what onion2k said, hard pass on building a company
| around an esoteric language. enjoy attempting to hire people to
| work on this. best case you get an eager programmer wanting to
| learn the language. worst case you get zero experienced hires
| unless you're a massive success.
| haolez wrote:
| The real worst case scenario is facing a competitor that's much
| faster than you on implementing new features and testing
| hypothesis. Using an esoteric language might be one of the
| leverages that this competitor has against your tight
| mainstream stack.
| Scarbutt wrote:
| In 2022 thinking that your esoteric language is going to help
| you implement new features faster than with a mainstream
| language is just plain language zealotry.
| haolez wrote:
| I disagree.
| mylons wrote:
| love the substance in your comment
| mylons wrote:
| i've worked with people like you in the past. they all write
| books for their language now. none of them correct. it's
| almost never the language that holds you back. it's the
| organization and it's priorities. an easy example is
| instagram and their use of python. they crushed with a
| language that clojure folx look down on.
| capableweb wrote:
| That "best case" seems dishonest at best. How is the best case
| not "Best case you get awesome programmers with lots of
| experience and knowledge about what Clojure is all about, being
| able to ship software better than anyone else" or similar?
|
| Clojure has pitfalls for sure, but no need to be dishonest in
| order to flag them.
___________________________________________________________________
(page generated 2022-10-04 23:00 UTC)