No post body was provided.
Building a Startup on Clojure
51–60 of 215 posts
Re: Building a Startup on Clojure
#52We 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.
Re: Building a Startup on Clojure
#53Greenspun'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.
If you want to write succinct, transparent code whilst minimizing the future potential of introducing bugs, Clojure is as good as it gets.
Re: Building a Startup on Clojure
#54Earlier quoted context omitted.
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…
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…
[deleted]
Re: Building a Startup on Clojure
#55While we are at it, anyone knows what's the Common Lisp story in webdev? Both backend and frontend?
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.
Re: Building a Startup on Clojure
#56Earlier quoted context omitted.
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?
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…
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.
Re: Building a Startup on Clojure
#57If 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 t…
> 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 ver…
Maybe exotic is a better word? It is certainly not seen as often as Java is, but it is no Malbolge.
Re: Building a Startup on Clojure
#58Earlier quoted context omitted.
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…
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…
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.
Re: Building a Startup on Clojure
#59Earlier quoted context omitted.
> 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…
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?
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.
Re: Building a Startup on Clojure
#60Earlier quoted context omitted.
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?
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…
I could probably look it up myself, but does EDN support comments?