11 ms·

What technology should your startup use?

83 points by mattetti 13y ago

wes-exp 13y ago
Clojure seems to get a lot of attention, but don't forget Common Lisp. If you're tired of the reinvention treadmill and want a great language that is actually mature, CL can be excellent. CL also has great runtime support: SBCL (for super performance) and ABCL (if you need the JVM).
DanielBMarkham 13y ago
Asking this question for many readers is like asking "What kinds of shoes should your startup use?" Value is important. Say that about a thousand times. Once you are creating value, then you can write long blog posts about various tool choices -- or spend time reading them. Until then? These issues are so trivial as to almost not be worthy of discussion. The interesting thing is that this is exactly backwards from the way most folks are taught programming. You pick the tool first, learn it's secrets, then set about making someone happy. This is a great paradigm if you want to be a corporate programmer, but if you're looking to form a startup you've got the cart in front of the horse. Sure, bring the skills to use all kinds of tech. But don't spend a millisecond focusing on that crap when nobody wants what you're offering. A lot of guys who say they're in startups are like a severely overweight and out of shape guy who sits around reading running magazines and ordering expensive gear. Yeah sure, that stuff can be dreadfully important. But only in the context of actually doing something. Otherwise it's just bike shedding.
untog 13y ago
Honestly? I think the answer is "the one you already know". Most of the languages covered in the article are capable of doing 90+% of what the average tech startup needs (a web site, an API, database connectivity). Save yourself the trouble of heading towards the latest hip technology and just write with the stuff you already know how to use. Worry about how flexible and scalable it is once you've actually proven your idea works.
- mattetti 13y ago
  OP here, when you build a company, you need more than one person so you also need to think about your product needs (what tech better fitted) and who you will hire to help you build it.
  - untog 13y ago
    That still seems backwards. Hire developers. Use a language those developers are comfortable with. Don't choose a language then hire developers for it. In any case, I'm not sure that many (any?) product needs could dictate choice of language in the vast majority of cases. Yes, if you need to do a ton of realtime stuff then maybe think about Node etc., but most people want the same standard stuff.
    - deleted 13y ago
      [deleted]
    - jrochkind1 13y ago
      "hire developers, use a language those developers are comfortable with." So you can use that method when hiring the first developer. When it's time to hire the second developer, are you looking for only developers that are comfortable with the same languages as the first developer? If so, you are hiring developers based on language, and no longer following your advice. If not.... then you get a bunch of developers comfortable with different languages, and now what? Often the answer might be "good developers can learn to be effective at any language." Which while on the whole (if not always) true, nevertheless only sometimes works for an enterprise (sometimes you don't have time to wait for them to learn it). But even so, now that turns into different advice: Hire your first developer, have her use a language she's comfortable with, then hire subsequent developers that either already know that language or are capable of learning it, and have them learn it. Which doesn't sound quite so obvious as your original advice, although it's not neccesarily an unreasonable approach.
      - davidw 13y ago
        So use what you are comfortable with - as long as it's not something that's so completely obscure that no one else knows it. If you just chase popularity, you're also probably likely chasing mediocrity. On the other hand, no, Visual Object Forth ++ from Borland is probably not the best thing to build a web site with.
Spearchucker 13y ago
The whole "C#, VS and MSDN reek of licenses" is getting a bit staid. I'm writing a thick client/desktop app (almost 300k LoC) using Visual Studio Express , SQL Express and online MSDN. Yes, I paid money for Windows and Office, but that has little bearing on being able to write shrink-wrap quality apps with free tools from Microsoft.
- hackula1 13y ago
  I left the .Net world about 3 years ago. There were plenty of things to complain about, but licensing was never one of them. Most of the stack is free until you get to the point where you should be able to pay for it anyway.
  - chc 13y ago
    I recently decided it might be worthwhile to learn the Microsoft stack, and had heard similar things about how you can just get whatever you need for free until you've scaled up. So I went poking around Microsoft's site for this free stuff. Half an hour later I gave up without having gotten my hands on anything but an impenetrable white paper about different versions of Visual Studio. So it seems that either people are exaggerating how free this stuff is or Microsoft is very good at hiding this.
    - adolfojp 13y ago
      1. Go to the Visual Studio website: http://www.microsoft.com/visualstudio/ http://www.microsoft.com/visualstudio/ 2. Click on the Products menu 3. Click on Express 2012 products 4. There is no step 4
      - chc 13y ago
        Ah, I didn't realize that when people say they give their stuff for free, they meant they're giving a different product away for free. That is…weird. I can't figure out what this includes. Is this actually enough to deploy a web app with the full Microsoft stack?
weakwire 13y ago
scala is just great (minus compile time). But really. what you know best . (pref type safe)
bernatfp 13y ago
I thought this lesson was already learned. You should use the one you're more comfortable with to build an MVP even if it doesn't scale well. You will take care about that later.
bifrost 13y ago
I have similar views to the author, however I generally respond with "LOLCODE, all the cool kids are using it" because its clear they need to do the work themselves to figure it out. If they ask "is it sane to use XYZ" I could give them some actually useful information, but sadly people often want to be given the answer rather than get advice. I'd say this question ranks up there with "Can I ask you a question?" to which I usually respond "You just did...". If you want useful information, just ask for it, your friends and peers are not your parents. NB: I ported a lolcode interpreter so I do actually encourage people to use it... sometimes...
czbond 13y ago
I have a different stance on this. The technology that drives the company is strategic business decision, not a technical decision. Sure - create the MVP in whatever you want, the technology is less import - but don't do that for Rev 2. Rev 2, the true architecture of the company should be based on A) what's the right tools for the use case B) are the resources with that talent available to keep from hindering the company? For example, I wouldn't start a company with Go/Rust/etc anywhere but in SanFran - because to most of the country these languages are still fads.
mindcrime 13y ago
Interesting take, but I'm disappointed that Groovy wasn't broken out into a separate entry. Groovy is a great choice in that you can leverage the entire world of Java libraries, while using a modern, dynamic language that is mostly backwards (syntax) compatible with Java - but without the verbosity. And Grails is a first-class convention-over-configuration framework for building webapps. IMO, Groovy is absolutely one of the top platform choices a startup could make. We've been using Groovy and Grails at Fogbeam for 2+ years and haven't regretted the decision at all, FWIW.
- vorg 13y ago
  Because Groovy has unfortunately turned into a mere appendage to Grails, with very little independent use, it's generally not considered as a viable standalone language by many people anymore.
BerislavLopac 13y ago
There is only one answer to this question: whatever your people are best with. Whether have any "people" (including yourself) who can code or not, you don't need to worry about the technology, you need to worry about your team. If we're talking about Web apps, technology is much less relevant than the team's abilities. If you're also going for native apps, your options are mostly limited anyway (especially on mobile), but the same principle still applies. Another reason for going with a familiar technology is that it will be easier for you to find future team members, as you will (presumably) already know the local community, thus avoiding what happened to Reddit.
tieTYT 13y ago
> C# > We have a better IDE than the Java guys Biased Java guy here. Completely disagree. Yes VS lets you build nice UIs with drag and drop. But if you compare bare bones Intellij IDEA to bare bones Visual Studio, Intellij IDEA wins everywhere else. All things being equal (that includes programming languages), you can be more productive in Intellij IDEA because its got the fundamentals down and has intuitive shortcuts for doing everything. Of course I haven't used VS for about 5 years. Keep that in mind. But back then IDEA was light years ahead and .NET devs still thought VS was better.
- edwinnathaniel 13y ago
  As long as the .NET guys don't have Maven they can't win. I can check-out a Java project that contains pom.xml using the big 3 Java IDEs out there (Eclipse, IntelliJ, NetBeans), compile, build, run unit-testing, integration-testing, navigate my codebase like crazy. But you know, I'm gettin tired singing the same choir of Java. .NET guys can sing how great their C# languages and VS.NET are but we know Java ecosystems win hands down End-To-End; we got it cover from distributed systems, big-data, enterprise, "service oriented", dependency management, build, validation (findbugs, checkstyle). Eclipse + essential plugins are more than enough for me (albeit I'm using IntelliJ these days) and it's free.
  - jrochkind1 13y ago
    Ha! I think what might seperate Java lovers from Java haters is whether you consider `maven` to be an asset or a liability! Those who only occasionally use Java when they have to... tend to find maven incredibly confusing to get working properly.
    - edwinnathaniel 13y ago
      Hahahaha, I think you're on to something there! I wouldn't call myself a Java lovers as I'm moving away from Java lately but so far I haven't found a comparable tool to build+dependency that Maven provides nor I have found a good ecosystems that adhere to non-breaking fundamental building-block standards (Servlet, JSP, JPA2, EJB3-lite, JMS, etc). Yes, Maven could be painful to start with especially without someone who had previous experience on your team but feature-wise, nothing competes with it yet. Ruby needs RubyGems and Bundler (and Rake to that extends) to compete with Maven. I heard the philosophy of "Do one thing and do it well" but if you're using those tools altogether every time (Rails) then what's the point...?
blacktulip 13y ago
This comment[0] interested me. I've never exposed to erlang. Can someone please explain this a bit to me why she said only erlang can do concurrency? [0]: http://matt.aimonetti.net/posts/2013/08/27/what-technology-should-my-startup-use/#comment-1019493802 http://matt.aimonetti.net/posts/2013/08/27/what-technology-s...
- lucaspiller 13y ago
  "Erlang based systems obtain many of the aforementioned properties from the Erlang concurrency model. Erlang handles the concurrency itself instead of relying on the OS. A concurrent entity in Erlang, called Erlang process, is much lighter than a standard OS process or thread, initially using about 3 KB of memory on a 64bit system. In a typical Erlang systems, you can easily create hundreds of thousands or maybe even millions of Erlang processes. The Erlang virtual machine uses its own scheduler which ensures that each process gets a fair share of execution time. The scheduler also distributes processes over available CPU cores, using as few OS threads as possible (by default only as much as the number of available CPU cores)." http://www.theerlangelist.com/2012/12/yet-another-introduction-to-erlang.html http://www.theerlangelist.com/2012/12/yet-another-introducti... It is kind of like Node in that it is very easy to do concurrent stuff, except instead of nested callbacks and all that jazz, you write 'processes' which are designed to share nothing. They run akin to OS threads in that one process crashing won't bring down the whole system (unlike Node). As no state is shared it also means that they can easily (i.e. it is built into the VM, and switched on by default) be scaled up to run over many cores. If you are interested, you might want to look at Elixir (a language built on top of the Erlang VM) which has a more Ruby-esque syntax: http://elixir-lang.org/ http://elixir-lang.org/ EDIT: Should also point out that I think "Jessica's" comment was just trolling, however it isn't far from the truth :)
  - _nato_ 13y ago
    Is ``Jessica's'' comment not far from the truth because Scala and Go have shared memory for their Actors/Processes? I know Erlang doesn't share memory between their processes which leads to concurrency; is this what she was getting at?
greatzebu 13y ago
I clicked through in the hope that it would say "it barely matters, just get started and fix mistakes as you go". It started off with promise when he asserted that the people asking this question usually didn't actually care about his answer and that other factors are much more important, but then for some reason we got the long list of languages and bullet points anyway.
killnine 13y ago
I agree the lesson has been learned: use what your best with. BUT currently I am looking to switch it up a bit (Tired of the same old thing) so I have been shopping around to learn a new language while building a web app. This post was a major help for me not only because of the timing but because I feel a lot more comfortable with what I want to look at. You can't bash a post for a personally insightful feel into the major options.
tieTYT 13y ago
> My problem with Clojure is that ... Exceptions are often meaningless and trying to debug someone else’s code is challenging since the language itself is complex and it can be extended by macros. Finally, the Clojure community isn’t really web-oriented, most of the work done in Clojure seems to be data-centric. You really nailed it here. I really like the language but I really struggled with debugging code and I'd shit my pants every time I refactored. I had a much nicer experience with Haskell: If your code compiles, it probably works. With Clojure: If your code compiles, it probably doesn't work. I'll tell you something's wrong, but you'll spend most of your development time discovering the cause. That's very frustrated. But to give Clojure the benefit of the doubt, I never felt like my development pipeline was efficient. Unfortunately, I couldn't find a canonical example of a good development pipeline.
crazygringo 13y ago
> Does this technology fit my company’s core values? This is actually a fantastic way of looking at it. All programming languages have philosophies, and certain "cultures" that they bring along with them. It's important to realize that technology choices are not just about the technology.
cgag 13y ago
I don't know what you mean by Clojure being data-centric rather than web centric. Requests are data, responses are data. Plenty of people are doing web-dev in Clojure. Edit: I would also disagree with the language being complex. I think the only languages that compete with its level of simplicity are mostly other lisps/schemes.
- Mikera 13y ago
  The point about complexity is probably fair from the perspective of someone just getting started with Clojure. Sure, the syntax itself is very simple and regular (like any Lisp). The complexity is in all the other stuff - macros, code-as-data, vars, namespaces, metadata, managed references, persistent data structures, leiningen, paredit etc. Once you've got up the steep learning curve, I find Clojure is unbelievably productive. It's just a bit tough getting there. I think it's all solvable, but the Clojure community does need to listen and learn from constructive criticism.

83 points by mattetti 13y ago

Clojure seems to get a lot of attention, but don't forget Common Lisp. If you're tired of the reinvention treadmill and want a great language that is actually mature, CL can be excellent. CL also has great runtime support: SBCL (for super performance) and ABCL (if you need the JVM).

DanielBMarkham 13y ago

Asking this question for many readers is like asking "What kinds of shoes should your startup use?" Value is important. Say that about a thousand times. Once you are creating value, then you can write long blog posts about various tool choices -- or spend time reading them. Until then? These issues are so trivial as to almost not be worthy of discussion. The interesting thing is that this is exactly backwards from the way most folks are taught programming. You pick the tool first, learn it's secrets, then set about making someone happy. This is a great paradigm if you want to be a corporate programmer, but if you're looking to form a startup you've got the cart in front of the horse. Sure, bring the skills to use all kinds of tech. But don't spend a millisecond focusing on that crap when nobody wants what you're offering. A lot of guys who say they're in startups are like a severely overweight and out of shape guy who sits around reading running magazines and ordering expensive gear. Yeah sure, that stuff can be dreadfully important. But only in the context of actually doing something. Otherwise it's just bike shedding.

untog 13y ago

Honestly? I think the answer is "the one you already know". Most of the languages covered in the article are capable of doing 90+% of what the average tech startup needs (a web site, an API, database connectivity). Save yourself the trouble of heading towards the latest hip technology and just write with the stuff you already know how to use. Worry about how flexible and scalable it is once you've actually proven your idea works.

mattetti 13y ago
OP here, when you build a company, you need more than one person so you also need to think about your product needs (what tech better fitted) and who you will hire to help you build it.
- untog 13y ago
  That still seems backwards. Hire developers. Use a language those developers are comfortable with. Don't choose a language then hire developers for it. In any case, I'm not sure that many (any?) product needs could dictate choice of language in the vast majority of cases. Yes, if you need to do a ton of realtime stuff then maybe think about Node etc., but most people want the same standard stuff.
  - deleted 13y ago
    [deleted]
  - jrochkind1 13y ago
    "hire developers, use a language those developers are comfortable with." So you can use that method when hiring the first developer. When it's time to hire the second developer, are you looking for only developers that are comfortable with the same languages as the first developer? If so, you are hiring developers based on language, and no longer following your advice. If not.... then you get a bunch of developers comfortable with different languages, and now what? Often the answer might be "good developers can learn to be effective at any language." Which while on the whole (if not always) true, nevertheless only sometimes works for an enterprise (sometimes you don't have time to wait for them to learn it). But even so, now that turns into different advice: Hire your first developer, have her use a language she's comfortable with, then hire subsequent developers that either already know that language or are capable of learning it, and have them learn it. Which doesn't sound quite so obvious as your original advice, although it's not neccesarily an unreasonable approach.
    - davidw 13y ago
      So use what you are comfortable with - as long as it's not something that's so completely obscure that no one else knows it. If you just chase popularity, you're also probably likely chasing mediocrity. On the other hand, no, Visual Object Forth ++ from Borland is probably not the best thing to build a web site with.

Spearchucker 13y ago

The whole "C#, VS and MSDN reek of licenses" is getting a bit staid. I'm writing a thick client/desktop app (almost 300k LoC) using Visual Studio Express , SQL Express and online MSDN. Yes, I paid money for Windows and Office, but that has little bearing on being able to write shrink-wrap quality apps with free tools from Microsoft.

hackula1 13y ago
I left the .Net world about 3 years ago. There were plenty of things to complain about, but licensing was never one of them. Most of the stack is free until you get to the point where you should be able to pay for it anyway.
- chc 13y ago
  I recently decided it might be worthwhile to learn the Microsoft stack, and had heard similar things about how you can just get whatever you need for free until you've scaled up. So I went poking around Microsoft's site for this free stuff. Half an hour later I gave up without having gotten my hands on anything but an impenetrable white paper about different versions of Visual Studio. So it seems that either people are exaggerating how free this stuff is or Microsoft is very good at hiding this.
  - adolfojp 13y ago
    1. Go to the Visual Studio website: http://www.microsoft.com/visualstudio/ http://www.microsoft.com/visualstudio/ 2. Click on the Products menu 3. Click on Express 2012 products 4. There is no step 4
    - chc 13y ago
      Ah, I didn't realize that when people say they give their stuff for free, they meant they're giving a different product away for free. That is…weird. I can't figure out what this includes. Is this actually enough to deploy a web app with the full Microsoft stack?

weakwire 13y ago

scala is just great (minus compile time). But really. what you know best . (pref type safe)

bernatfp 13y ago

I thought this lesson was already learned. You should use the one you're more comfortable with to build an MVP even if it doesn't scale well. You will take care about that later.

bifrost 13y ago

I have similar views to the author, however I generally respond with "LOLCODE, all the cool kids are using it" because its clear they need to do the work themselves to figure it out. If they ask "is it sane to use XYZ" I could give them some actually useful information, but sadly people often want to be given the answer rather than get advice. I'd say this question ranks up there with "Can I ask you a question?" to which I usually respond "You just did...". If you want useful information, just ask for it, your friends and peers are not your parents. NB: I ported a lolcode interpreter so I do actually encourage people to use it... sometimes...

czbond 13y ago

I have a different stance on this. The technology that drives the company is strategic business decision, not a technical decision. Sure - create the MVP in whatever you want, the technology is less import - but don't do that for Rev 2. Rev 2, the true architecture of the company should be based on A) what's the right tools for the use case B) are the resources with that talent available to keep from hindering the company? For example, I wouldn't start a company with Go/Rust/etc anywhere but in SanFran - because to most of the country these languages are still fads.

mindcrime 13y ago

Interesting take, but I'm disappointed that Groovy wasn't broken out into a separate entry. Groovy is a great choice in that you can leverage the entire world of Java libraries, while using a modern, dynamic language that is mostly backwards (syntax) compatible with Java - but without the verbosity. And Grails is a first-class convention-over-configuration framework for building webapps. IMO, Groovy is absolutely one of the top platform choices a startup could make. We've been using Groovy and Grails at Fogbeam for 2+ years and haven't regretted the decision at all, FWIW.

vorg 13y ago
Because Groovy has unfortunately turned into a mere appendage to Grails, with very little independent use, it's generally not considered as a viable standalone language by many people anymore.

BerislavLopac 13y ago

There is only one answer to this question: whatever your people are best with. Whether have any "people" (including yourself) who can code or not, you don't need to worry about the technology, you need to worry about your team. If we're talking about Web apps, technology is much less relevant than the team's abilities. If you're also going for native apps, your options are mostly limited anyway (especially on mobile), but the same principle still applies. Another reason for going with a familiar technology is that it will be easier for you to find future team members, as you will (presumably) already know the local community, thus avoiding what happened to Reddit.

tieTYT 13y ago

> C# > We have a better IDE than the Java guys Biased Java guy here. Completely disagree. Yes VS lets you build nice UIs with drag and drop. But if you compare bare bones Intellij IDEA to bare bones Visual Studio, Intellij IDEA wins everywhere else. All things being equal (that includes programming languages), you can be more productive in Intellij IDEA because its got the fundamentals down and has intuitive shortcuts for doing everything. Of course I haven't used VS for about 5 years. Keep that in mind. But back then IDEA was light years ahead and .NET devs still thought VS was better.

edwinnathaniel 13y ago
As long as the .NET guys don't have Maven they can't win. I can check-out a Java project that contains pom.xml using the big 3 Java IDEs out there (Eclipse, IntelliJ, NetBeans), compile, build, run unit-testing, integration-testing, navigate my codebase like crazy. But you know, I'm gettin tired singing the same choir of Java. .NET guys can sing how great their C# languages and VS.NET are but we know Java ecosystems win hands down End-To-End; we got it cover from distributed systems, big-data, enterprise, "service oriented", dependency management, build, validation (findbugs, checkstyle). Eclipse + essential plugins are more than enough for me (albeit I'm using IntelliJ these days) and it's free.
- jrochkind1 13y ago
  Ha! I think what might seperate Java lovers from Java haters is whether you consider `maven` to be an asset or a liability! Those who only occasionally use Java when they have to... tend to find maven incredibly confusing to get working properly.
  - edwinnathaniel 13y ago
    Hahahaha, I think you're on to something there! I wouldn't call myself a Java lovers as I'm moving away from Java lately but so far I haven't found a comparable tool to build+dependency that Maven provides nor I have found a good ecosystems that adhere to non-breaking fundamental building-block standards (Servlet, JSP, JPA2, EJB3-lite, JMS, etc). Yes, Maven could be painful to start with especially without someone who had previous experience on your team but feature-wise, nothing competes with it yet. Ruby needs RubyGems and Bundler (and Rake to that extends) to compete with Maven. I heard the philosophy of "Do one thing and do it well" but if you're using those tools altogether every time (Rails) then what's the point...?

blacktulip 13y ago

This comment[0] interested me. I've never exposed to erlang. Can someone please explain this a bit to me why she said only erlang can do concurrency? [0]: http://matt.aimonetti.net/posts/2013/08/27/what-technology-should-my-startup-use/#comment-1019493802 http://matt.aimonetti.net/posts/2013/08/27/what-technology-s...

lucaspiller 13y ago
"Erlang based systems obtain many of the aforementioned properties from the Erlang concurrency model. Erlang handles the concurrency itself instead of relying on the OS. A concurrent entity in Erlang, called Erlang process, is much lighter than a standard OS process or thread, initially using about 3 KB of memory on a 64bit system. In a typical Erlang systems, you can easily create hundreds of thousands or maybe even millions of Erlang processes. The Erlang virtual machine uses its own scheduler which ensures that each process gets a fair share of execution time. The scheduler also distributes processes over available CPU cores, using as few OS threads as possible (by default only as much as the number of available CPU cores)." http://www.theerlangelist.com/2012/12/yet-another-introduction-to-erlang.html http://www.theerlangelist.com/2012/12/yet-another-introducti... It is kind of like Node in that it is very easy to do concurrent stuff, except instead of nested callbacks and all that jazz, you write 'processes' which are designed to share nothing. They run akin to OS threads in that one process crashing won't bring down the whole system (unlike Node). As no state is shared it also means that they can easily (i.e. it is built into the VM, and switched on by default) be scaled up to run over many cores. If you are interested, you might want to look at Elixir (a language built on top of the Erlang VM) which has a more Ruby-esque syntax: http://elixir-lang.org/ http://elixir-lang.org/ EDIT: Should also point out that I think "Jessica's" comment was just trolling, however it isn't far from the truth :)
- _nato_ 13y ago
  Is ``Jessica's'' comment not far from the truth because Scala and Go have shared memory for their Actors/Processes? I know Erlang doesn't share memory between their processes which leads to concurrency; is this what she was getting at?

greatzebu 13y ago

I clicked through in the hope that it would say "it barely matters, just get started and fix mistakes as you go". It started off with promise when he asserted that the people asking this question usually didn't actually care about his answer and that other factors are much more important, but then for some reason we got the long list of languages and bullet points anyway.

killnine 13y ago

I agree the lesson has been learned: use what your best with. BUT currently I am looking to switch it up a bit (Tired of the same old thing) so I have been shopping around to learn a new language while building a web app. This post was a major help for me not only because of the timing but because I feel a lot more comfortable with what I want to look at. You can't bash a post for a personally insightful feel into the major options.

tieTYT 13y ago

> My problem with Clojure is that ... Exceptions are often meaningless and trying to debug someone else’s code is challenging since the language itself is complex and it can be extended by macros. Finally, the Clojure community isn’t really web-oriented, most of the work done in Clojure seems to be data-centric. You really nailed it here. I really like the language but I really struggled with debugging code and I'd shit my pants every time I refactored. I had a much nicer experience with Haskell: If your code compiles, it probably works. With Clojure: If your code compiles, it probably doesn't work. I'll tell you something's wrong, but you'll spend most of your development time discovering the cause. That's very frustrated. But to give Clojure the benefit of the doubt, I never felt like my development pipeline was efficient. Unfortunately, I couldn't find a canonical example of a good development pipeline.

crazygringo 13y ago

> Does this technology fit my company’s core values? This is actually a fantastic way of looking at it. All programming languages have philosophies, and certain "cultures" that they bring along with them. It's important to realize that technology choices are not just about the technology.

cgag 13y ago

I don't know what you mean by Clojure being data-centric rather than web centric. Requests are data, responses are data. Plenty of people are doing web-dev in Clojure. Edit: I would also disagree with the language being complex. I think the only languages that compete with its level of simplicity are mostly other lisps/schemes.

Mikera 13y ago
The point about complexity is probably fair from the perspective of someone just getting started with Clojure. Sure, the syntax itself is very simple and regular (like any Lisp). The complexity is in all the other stuff - macros, code-as-data, vars, namespaces, metadata, managed references, persistent data structures, leiningen, paredit etc. Once you've got up the steep learning curve, I find Clojure is unbelievably productive. It's just a bit tough getting there. I think it's all solvable, but the Clojure community does need to listen and learn from constructive criticism.