Live data from Hacker News

Building a Startup on Clojure

wobaka.com

161–170 of 215 posts

Re: Building a Startup on Clojure

#161

Earlier quoted context omitted.

Ah, Spring - freeing Java developers from the horror of typing "new" since 2002.

If you did a Spring tutorial, I can see that this might be the takeaway. For me, I was thrown at a large project with a couple of large Spring codebases, I concluded that it's about structuring your code around an object graph with independent, testable, loosely coupled components.

I use both Spring and Java professionally. For a pretty long time now. I was being somewhat sarcastic.

I mostly use Spring because it's pretty widespread and I figure - why fight the current. But I still think the benefit is minor for most projects. And the existence of Spring Boot makes me chuckle a bit.

Re: Building a Startup on Clojure

#162

Earlier 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…

I have no commercial Scala or Java experience.

However I wouldn't mind coding in Scala. I like OO, I like FP, I'm comfortable with expression based programming and immutability. Based on that alone - and playing with Scala in my spare time - I feel like someone with my background may be more suited than someone with a commercial Java "mutate every variable" background.

But I'd never get through your filters.

Re: Building a Startup on Clojure

#163
post #79

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.

I would also argue that the productivity delta between something like Clojure vs Python or Javascript or Kotlin is not as high as it was between Common Lisp vs C++/Java 10-15 years ago. So the payoff for a risky bet is not as high. That said I would love to work in a lisp full time. There's just something appealingly elegant about it.

[deleted]

Re: Building a Startup on Clojure

#164

Earlier quoted context omitted.

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 coll…

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.

> The tooling around it is second to none

I feel like you've never looked at C's tooling.

Admittedly, some of it is stuff you just don't need in Java, but things like Valgrind are crazy impressive.

Re: Building a Startup on Clojure

#165
post #89

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…

> 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)

And to the article's title, "building a startup on Clojure," you're better off building a startup on a customer base.

Re: Building a Startup on Clojure

#166
post #62
post #59

Earlier quoted context omitted.

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.

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 ar…

>That's like saying that C++ is a better backend platform

C++ isn't even a platform, period. It provides no runtime or anything else other than the language. If you build on top of the JVM ecosystem, similar to NET you get a cross platform, extremely performant ecosystem with millions if not billions invested into it basically for free.

And of course you can build a billion dollar company on a crappy tech stack, but if you had built it on a good one you'd still be a billion dollar company and be even better off. What a strange argument, you ought to make the best technical choice you can, it's a core part of anything you built. And getting a 10x performance on the JVM vs say Python, or smooth, non error prone concurrency in Clojure is a significant benefit.

In particular in business applications were you usually deal with data transformations, the single-threaded, mutable state type of design of some languages is awful. Clojure in particular was exactly made for this practical use case.

Re: Building a Startup on Clojure

#167

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 mak…

[deleted]

Re: Building a Startup on Clojure

#168
Our experience building a business with Clojure has been amazing. It has helped us to attract extremely strong engineers, and churn has not been a concern in the slightest. We've taught people (from code beginners to experienced engineers) Clojure, and all of them are able to start adding value in a very short space of time. We're six years in and there are no signs of increased maintenance difficulty due to the language. We follow the Polylith Architecture (https://polylith.gitbook.io/polylith/), which has given us yet another boost in developer happiness, speed of delivery, and ease of maintenance. There are many extremely large Clojure code bases out there (Ladder life, Lemonade, Simply life, Wallmart, Nubank, Atlassian) not suffering from the maintainability issues that some people here have described.

After six years, I would absolutely (without hesitation) start another business with Clojure as the core.

Re: Building a Startup on Clojure

#169

Earlier quoted context omitted.

If you did a Spring tutorial, I can see that this might be the takeaway. For me, I was thrown at a large project with a couple of large Spring codebases, I concluded that it's about structuring your code around an object graph with independent, testable, loosely coupled components.

I use both Spring and Java professionally. For a pretty long time now. I was being somewhat sarcastic. I mostly use Spring because it's pretty widespread and I figure - why fight the current. But I still think the benefit is minor for most projects. And the existence of Spring Boot makes me chuckle a bit.

I get you. I think it encourages a certain application structure that is at least recognizable across projects. There's a pretty big benefit to that, even if at the detail level it's just a way to avoid new.

Re: Building a Startup on Clojure

#170
post #112

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?

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)

I was lost when I moved to deps from lein, but just forking and cloning https://github.com/practicalli/clojure-deps-edn as $HOME/.clojure solved the problem - this base deps.edn contained all the aliases I needed - creating a new project, searching and adding dependencies, hooking up data inspectors like portal or reveal, testing, code coverage, benchmarking, building uberjar etc. Moving to deps also introduced me to polylith [1], which has been very useful for building large multi-component projects

[1] https://polylith.gitbook.io/polylith/

Post reply on HN