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

181–190 of 215 posts

Re: Building a Startup on Clojure

#181

Post by s-zeng »

seer-zig wrote: post #104
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…

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.

> decent type system

I'd call it a bare minimum type system, not "decent"

Re: Building a Startup on Clojure

#182

Post by seer-zig »

s-zeng wrote: post #181
seer-zig wrote: post #104

Earlier quoted context omitted.

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.

> decent type system I'd call it a bare minimum type system, not "decent"

golang and C would take that spot :-)

Records, pattern matching, string templates, and more to come for Java for which the other two have nothing equivalent.

Re: Building a Startup on Clojure

#183

Post by seer-zig »

Kamq wrote: post #164
seer-zig wrote: post #104

Earlier quoted context omitted.

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.

The issues that C faces in terms of memory correctness do not occur in Java. You can use tools like `perf` on a Java program, and I don't see why you couldn't use valgrind for natively compiled Java programs.

For debugging and observability, tell me if C (or any other platform) has anything resembling JFR for the JVM.

Re: Building a Startup on Clojure

#184

Post by domparry »

kubb wrote: post #69
alfl wrote: post #29

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.

Why not hire good non-Clojure devs and bootcamp them in Clojure over a month? Ah, you probably want to pay them 70k/year.

We've done a lot of this too. Works very well. Hire curious, teach Clojure.

Re: Building a Startup on Clojure

#185

Post by ParetoOptimal »

strikelaserclaw wrote: post #100
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…

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.

> ridiculously compact and abstract code that is hard to understand just by reading it.

For a maintenance provrammer against learning anything, abstract and compact are always bad.

Typically though, if you understand a few core concepts abstract and compact can be more readable towards the end goal of a high level understanding.

Re: Building a Startup on Clojure

#186

Post by lukashrb »

seer-zig wrote: post #104
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…

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.

> and because it is statically typed with a decent type system, you can refactor quite safely in general.

I wish that would be true. Would make my current job a lot easier.

Re: Building a Startup on Clojure

#187

Post by CyberDildonics »

freilanzer wrote: post #177
CyberDildonics wrote: post #94

Earlier quoted context omitted.

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.

As opposed to the paradigms of beautiful design that are Java codebases.

What does a bad java program have to do with a language who's advantage and use case is to be clever on an expression level?

Re: Building a Startup on Clojure

#188

Post by freilanzer »

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…

> but there are no devs available where I live

If only there was a worldwide information technology network allowing people to work together remotely.

Re: Building a Startup on Clojure

#189

Post by silentsea90 »

keithasaurus wrote: post #33
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

It's pretty easy to enforce static typing in python these days. mypy and pyright are both pretty mature.

I used mypy in 2019, and it felt like duct tape on python at best.

Re: Building a Startup on Clojure

#190

Post by silentsea90 »

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.

Just as the other commenter says, types are half the testing done for free which is a massive improvement.
Post reply on HN