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

71–80 of 215 posts

Re: Building a Startup on Clojure

#72

Post by iLemming »

jwr wrote: post #30

Having built a business on Clojure: I'd highly recommend it. Stable, developed in a mature way over many years, with a fantastic and mature community. Together with ClojureScript it's one of very few solutions for writing server/browser apps with shared code, which enables interesting economies.

I have not built a business with Clojure and I wouldn't recommend it. For the reason that I'm hoping one day to build one and beat the averages. Stay away from Clojure, or else... :)

Re: Building a Startup on Clojure

#73

Post by thom »

jdminhbg wrote: post #67
leiferik wrote: post #45

Earlier quoted context omitted.

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…

EDN also contains support for date and UUID literals, the former of which is a huge pain when using JSON and needing to communicate which standard you're using and remember to encode/decode on each side of the wire.

Plus you can even write your own reader literals to enhance your data format. Aero does this well/horribly depending on your taste but it's a cool mechanism for declarative formats.

Re: Building a Startup on Clojure

#74

Post by kaba0 »

dimitar wrote: post #64
kaba0 wrote: post #60

Earlier quoted context omitted.

I could probably look it up myself, but does EDN support comments?

Yep, two types in fact, line comments with ; and a discard sequence - you can tag code that is read (so it must be correct), but then discarded. We have edn files that are well documented with comments. https://github.com/edn-format/edn#comments

I thought so — then it is strictly better than JSON.

Re: Building a Startup on Clojure

#75

Post by jwr »

thih9 wrote: post #37
jwr wrote: post #34

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

JavaScript is one of the few languages that works well both in the browser and on the server side. I don't think this is the time or the place to explain why I didn't write my software in JavaScript — let's just say that I don't think I could handle the incidental complexity in my team of size 1.

As for JSON, others have replied, but my point was perhaps not very well made. It's not just the limitations of JSON itself. By using the same language on both sides, I can avoid adapting to the limitations of any transit format. In other words, I can (pretty much) pass native data structures through and get them out on the other side. In my case, that means not just maps and vectors, but also sets, keywords, or UUIDs. Can this be done with JSON? Sure! But then I'd have an entirely new bug area to deal with (encoding/decoding, forgetting to coerce, etc).

Re: Building a Startup on Clojure

#76

Post by jwr »

georgeoliver wrote: post #71

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?

Something being "more recent" doesn't necessarily make it better :-)

I use leiningen, too. I tried other approaches, but had trouble getting them to do everything that I need (for example, AOT compilation of the entire code that goes into the final .jar), and I couldn't really see any massive advantages.

Re: Building a Startup on Clojure

#77

Post by joshlemer »

ithrow wrote: post #56
leiferik wrote: post #45

Earlier quoted context omitted.

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.

Yeah but still you have to admit, there's quite a lot more friction and ambiguity in that approach. Do I represent a map as

    [
      ["key", "value"],
      ["otherKey", "otherValue"]
    ]
or

    [
      {"key": "key", "value": "value"},
      {"key": "otherKey", "value":"otherValue"}
    ]
or something else? And how can I distinguish between values which just happen to look like maps but are actually not maps? And what if the service I'm talking to does it differently? What if I'm comparing or sorting two JSON values, don't I have to modify the equality/hashcode/ordering logic now to interpret

    [
      ["key", "value"],
      ["otherKey", "otherValue"]
    ]
and

    [
      ["otherKey", "otherValue"],
      ["key", "value"]
    ]
as being equal and implement a new hashcode/ordering which treats them as equal?

Quite a lot easier when this is just native to the format.

Re: Building a Startup on Clojure

#78

Post by AyyWS »

outworlder wrote: post #47
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…

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

last 6 months job listings from itjobswatch.co.uk

Python - 23,146

Java - 19,800

Scala - 2,274

Clojure - 291

Re: Building a Startup on Clojure

#79

Post by mylons »

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.

Re: Building a Startup on Clojure

#80

Post by haolez »

mylons wrote: 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.

The real worst case scenario is facing a competitor that's much faster than you on implementing new features and testing hypothesis. Using an esoteric language might be one of the leverages that this competitor has against your tight mainstream stack.
Post reply on HN