Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a Startup on Clojure

wobaka.com

Post reply on HN
Print view View original

131–140 of 215 posts

Re: Building a Startup on Clojure

#131

Post by hypersoar »

pedrodelfino wrote: post #40
hypersoar wrote: post #38

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

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

I don't want to overstate my experience--I've used neither professionally. But I think it's true that the repl is better with Clojure than with Clojurescript. Cider with shadow-cljs is very nice but not quite as well-supported as vanilla. Plus, the very fact that you're producing code to be rendered by a browser pushes the work you do on the pure data level, where the repl really shines, towards the background.

Re: Building a Startup on Clojure

#132

Post by guhidalg »

throwaway5959 wrote: post #25
silentsea90 wrote: post #20

Earlier quoted context omitted.

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

In monoliths sure, but if you’re building services that are compact and tested it’s less of an issue.

Types are tests run by the compiler. You shouldn't avoid testing, just let the compiler do it for you.

Re: Building a Startup on Clojure

#133

Post by jaxr »

DrBenCarson wrote: post #3
onion2k wrote: post #2

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

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.

Probably worth bringing to attention the python paradox essay: http://www.paulgraham.com/pypar.html

Re: Building a Startup on Clojure

#134

Post by dekelpilli »

xapata wrote: post #118
synthc wrote: post #114

Earlier quoted context omitted.

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.

Including Spring itself? Jokes aside, can't Clojure simply call whatever you want from the JVM?

Maybe theoretically true (I'm not sure about the extent of the completeness), but definitely not practically true when it comes to annotation-driven-development frameworks such as Spring.

Re: Building a Startup on Clojure

#135

Post by yogthos »

ldite wrote: 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…

As the saying goes, a bad workman always blames his tools. You can make a mess in any language, and Clojure is no exception.

There are plenty of ways to mitigate the problems the author describes. A few of these things would be having coding standards to ensure that code is written in a way everyone is comfortable with. This also covers things like adding schemas and documentation for maintainability. Doing pairing and code reviews so that multiple developers are familiar with different parts of the codebase. Having good tests so that you can have confidence that the code does what's intended when you make changes.

I'm also not sure what makes Clojure esoteric. It's a clean and well designed language that embodies good principles. It's a niche language, but far from being esoteric. I've been using Clojure for over a decade now, and I've seen the opposite of developer churn. Most people are pretty happy to stay at a company using Clojure. The fact that there is high churn is suggestive of a toxic environment that drives people away.

Finally, here's [1] a talk from a founder of a Clojure startup that grew into a large successful company. Clojure didn't get in the way of that.

[1] https://www.youtube.com/watch?v=u-4FiFpkPlQ

Re: Building a Startup on Clojure

#136

Post by newlisp »

z9znz wrote: post #106
gered wrote: post #99

Earlier quoted context omitted.

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…

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

Don't know about Ruby but agree that languages(think Java/C#/Javascript/C++) with really good debuggers don't have anything to envy from the Clojure REPL. But to be fair, companies have invested who knows how many millions to get that level of tooling while in Clojure and the nature of lisps you get it for free and low effort.

Re: Building a Startup on Clojure

#137

Post by logistark »

Well, i have to add having developing in a Clojure shop that starting to develop a new feature with Clojure is easier than Kotlin, you don't have to care almost about of the shape of the data. But later, this is a pain, you need a lot of discipline to document because you would look back at this code a who knows what data are you receiving.

In addition i have to say, that a lot of libraries are falling into clj-commons because the original developers no longer works on the project, other like compojure, that is mentioned in the blog post last stable release is from 2016 and version 2 is in alpha since then.

I am curious why are you using c3p0 on 2022 when hikaricp is being maintained, and last release of c3p0 is from 2019. Also no support for R2DBC.

My impression is that in the last 2 years, the ecosystem has shrink, less talks, less new libraries, new libraries that are no longer maintained.

Others problems arise is that Clojure lag a bit with compatibility with new Java features, still i think Clojure cannot pass Clojure functions as parameter to Java functions. It results in awkwardly having to reify Java function interface to pass function when using a Java library. No conversion from Java 8 CompletableFuture to clojure async primitives in 2022. And i think they not going to support it in the near future.

What i am saying is that Java is in the future, and Clojure is in the past. They just cannot catch with new Java features and i doubt they are going to support it ever. You can still run it on modern jvm because they update the bytecode but that is all.

Re: Building a Startup on Clojure

#138

Post by newlisp »

ldite wrote: 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…

The same could be said about Ruby/Python/JS except for them not being esoteric. And they are wildly successful, even for new projects today.

Re: Building a Startup on Clojure

#139

Post by newlisp »

logistark wrote: post #137

Well, i have to add having developing in a Clojure shop that starting to develop a new feature with Clojure is easier than Kotlin, you don't have to care almost about of the shape of the data. But later, this is a pain, you need a lot of discipline to document because you would look back at this code a who knows what data are you receiving. In addition i have to say, that a lot of libraries are falling into clj-commo…

Others problems arise is that Clojure lag a bit with compatibility with new Java features, still i think Clojure cannot pass Clojure functions as parameter to Java functions. It results in awkwardly having to reify Java function interface to pass function when using a Java library

Ouch, Java 8 was released in 2014. To be fair, Clojure was never a community project though.

Re: Building a Startup on Clojure

#140

Post by dustingetz »

zmmmmm wrote: post #113
dustingetz wrote: post #98

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…

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

clojure inherits the exact same debug tooling you describe
Post reply on HN