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

191–200 of 215 posts

Re: Building a Startup on Clojure

#191

Post by kbuchanan »

yogthos wrote: post #135
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 a…

I offered a counter example to the comment author too (Clojure has been wonderful for us), but I do wonder if there is one area where OO languages excel above functional: the shape of the code hints at the shape of the data.

In Lisp, function names describe actions. In OO, classes, inheritance, static properties, and getters and setters give at-a-glance hints as to the shape of the application's data model. In Clojure, we compensate, as you pointed out, with forms of documentation. I'll take that trade-off any day—I never want to go back to classes! But it's perhaps one reason for which Clojure has a reputation of being hard to read by other devs.

Re: Building a Startup on Clojure

#192

Post by heneryville »

gdsdfe wrote: post #111
heneryville wrote: post #24

Earlier quoted context omitted.

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

Still hiring? :)

We're paused right now since we're prepping for a funding round. However, have you checked out the Clojurians slack? They have a #jobs channel which is pretty good.

Re: Building a Startup on Clojure

#193

Post by [deleted] »

yogthos wrote: post #135
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 a…

[deleted]

Re: Building a Startup on Clojure

#194

Post by beiller »

silentsea90 wrote: post #20
beiller wrote: post #8

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!

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

The only code base that wound up being unmaintainable in that particular startup was the Clojure code base. I guess my point is no matter which language you are using, they all suffer from aging as they grow in size and addition of maintainers over time. The python code base was all incorporating mypy into the build / deploy pipelines and it worked quite well in my opinion. I am a huge fan of the recent additions to python and the work done there for static typing like mypy, pydantic, etc.

Re: Building a Startup on Clojure

#195

Post by solarmist »

staticelf wrote: post #90
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 don't understand, doesn't most languages these days have a REPL?

If you haven't used a lisp or lisp clone, it's hard to describe fully. Still, the fact that you can trivially replace and reload modules in running code or being able to fix a bug in a function and resubmit the input to the function from the stack trace is amazing ergonomically.

In the same way that most languages have lambdas, it's very different from being able to trivially compose functions into new functions. (This one I can't even describe well, but if you try and write SICP exercises in a lisp vs. python, the difference is obvious.

Re: Building a Startup on Clojure

#196

Post by lispm »

kbuchanan wrote: post #191
yogthos wrote: post #135

Earlier quoted context omitted.

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

I offered a counter example to the comment author too (Clojure has been wonderful for us), but I do wonder if there is one area where OO languages excel above functional: the shape of the code hints at the shape of the data. In Lisp, function names describe actions. In OO, classes, inheritance, static properties, and getters and setters give at-a-glance hints as to the shape of the application's data model. In Clojur…

since around the early 80s it was common to write large Lisp software using class-oriented or even class-based OOP (a few used also prototype-based OOP). For example Flavors for the MIT Lisp Machine was class-based: multiple-inheritance, mixins, message sending with single dispatch, ... CLOS (the Common Lisp Object System) then changed OOP such that it better fits into Lisp: generic functions with multiple dispatch, classes, multiple-inheritance, meta object protocol, ... One of the drawbacks of those systems is that the code gets assembled at runtime (though cached) and thus to read and understand code one might need support from class/function browsers.

Re: Building a Startup on Clojure

#197

Post by preseinger »

dkersten wrote: post #178
preseinger wrote: post #147

Earlier quoted context omitted.

You can make a mess in any language, yes. But some languages tend to produce more messes than others. If your tool is mis-used more than other tools, at some point, it's not the fault of the users.

I’ve personally had to deal with far more and worse messes in Python, Java and Javascript than I ever did in Clojure. (Started using Clojure ~13 years ago, but have been in jobs that use the other languages I’ve mentioned in that time too, not always exclusively using Clojure, although there were periods where I was). I have mentioned a few times in the past, on HN and Reddit and elsewhere, that my biggest personal d…

YMMV, but "messes" are for me things that manifest in projects spanning both multiple contributors and non-trivial periods of time. And in that framing, in my experience, the most effective individual proxy for "is this project a mess" is whether or not it's implemented in a dynamically typed language. Python, Javascript, Clojure, Ruby, my experience is that they all break down at scale, far more than equivalent projects in statically typed languages.

Re: Building a Startup on Clojure

#198

Post by dkersten »

xmcqdpt2 wrote: post #179
dkersten wrote: post #178

Earlier quoted context omitted.

I’ve personally had to deal with far more and worse messes in Python, Java and Javascript than I ever did in Clojure. (Started using Clojure ~13 years ago, but have been in jobs that use the other languages I’ve mentioned in that time too, not always exclusively using Clojure, although there were periods where I was). I have mentioned a few times in the past, on HN and Reddit and elsewhere, that my biggest personal d…

> I have mentioned a few times in the past, on HN and Reddit and elsewhere, that my biggest personal dream language wishlist item is “Clojure but with static types”, however, while that’s something I dream of having, it hasn’t held me or the language back in any meaningful way. Sadly, Rich Hickey has always been pretty opposed to typing in Clojure. Enforcing values to be not null is basically table stakes for typed s…

Yeah. By dream of I mean “if I had a on of free time, it’s something I’d love to make because I want it” while knowing it will never happen. I know that Clojure itself will never support it, outside of external projects like Typed Clojure

Re: Building a Startup on Clojure

#199

Post by dkersten »

preseinger wrote: post #197
dkersten wrote: post #178

Earlier quoted context omitted.

I’ve personally had to deal with far more and worse messes in Python, Java and Javascript than I ever did in Clojure. (Started using Clojure ~13 years ago, but have been in jobs that use the other languages I’ve mentioned in that time too, not always exclusively using Clojure, although there were periods where I was). I have mentioned a few times in the past, on HN and Reddit and elsewhere, that my biggest personal d…

YMMV, but "messes" are for me things that manifest in projects spanning both multiple contributors and non-trivial periods of time. And in that framing, in my experience, the most effective individual proxy for "is this project a mess" is whether or not it's implemented in a dynamically typed language. Python, Javascript, Clojure, Ruby, my experience is that they all break down at scale, far more than equivalent proj…

I’ve seen what I would consider messes in C++ and Java too, so it’s not exclusive to dynamically typed languages, but I’ve certainly seen enough in Python and Javascript to understand what you’re saying. It’s also a reason why I dream of a Clojure-like language with first class static typing, but, alas…

Re: Building a Startup on Clojure

#200

Post by throwaway5959 »

guhidalg wrote: post #132
throwaway5959 wrote: post #25

Earlier quoted context omitted.

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.

I’m aware. Before Python I wrote primarily in Scala and I do Rust on the side. Good luck hiring at scale for those without either offering a really interesting product to work on or lots of $$$. Even then, still easier to hire for Python.
Post reply on HN