2 ms·

> you'll be more productive in the short-term I'm not so sure. One of the advantages of these more mainstream languages is the combination of an incredibly lar

> you'll be more productive in the short-term I'm not so sure. One of the advantages of these more mainstream languages is the combination of an incredibly large selection of libraries and many people having already made the mistake you will make. This means when you run into an issue, there are already several posts on stack overflow about it, and you move on without issue.

jlouis 10y ago
The really interesting problems have the property that there is no library written for them yet. Granted, you need some kind of interaction with the outside world, but this is easy to handle in another language layer. The "existing libraries" are only going to be efficient if your entrepreneurship is based around the idea of rehashing or recombining existing tooling, which is already there. But far from all projects has that property. Also, one of the really intriguing thing about splitting your service into smaller micro-service based architectures, is that you can mix and match different languages. Which gives you the ability to pick languages which suits a solution. A good example is the TensorFlow system by Google. Model building usually happens in Python, but you then load that model into a thin C++ layer which serves the requests on the network as a standalone application. The same approach can be taken with some of the more advanced languages. Even better, as a startup, the least of your worries straight away is horizontal scaling. Modern machines are so fast you can run an incredible amount of concurrency on a single large node, so why bother too much with scaling? This help the micro-service model even more, as there is less reason to worry about the communication overhead.
- pdpi 10y ago
  > The really interesting problems have the property that there is no library written for them yet. But it's the reverse of that that's precisely the point though. If all the uninteresting problems already do have nicely packaged solutions, you get to focus on the interesting problem instead. The question then becomes: are you better off solving the interesting problems in better language at he cost of having to solve more of the uninteresting ones?
- eva1984 10y ago
  > Modern machines are so fast you can run an incredible amount of concurrency on a single large node, so why bother too much with scaling. Because that node might die any second.

jlouis 10y ago

The really interesting problems have the property that there is no library written for them yet. Granted, you need some kind of interaction with the outside world, but this is easy to handle in another language layer. The "existing libraries" are only going to be efficient if your entrepreneurship is based around the idea of rehashing or recombining existing tooling, which is already there. But far from all projects has that property. Also, one of the really intriguing thing about splitting your service into smaller micro-service based architectures, is that you can mix and match different languages. Which gives you the ability to pick languages which suits a solution. A good example is the TensorFlow system by Google. Model building usually happens in Python, but you then load that model into a thin C++ layer which serves the requests on the network as a standalone application. The same approach can be taken with some of the more advanced languages. Even better, as a startup, the least of your worries straight away is horizontal scaling. Modern machines are so fast you can run an incredible amount of concurrency on a single large node, so why bother too much with scaling? This help the micro-service model even more, as there is less reason to worry about the communication overhead.

pdpi 10y ago
> The really interesting problems have the property that there is no library written for them yet. But it's the reverse of that that's precisely the point though. If all the uninteresting problems already do have nicely packaged solutions, you get to focus on the interesting problem instead. The question then becomes: are you better off solving the interesting problems in better language at he cost of having to solve more of the uninteresting ones?
eva1984 10y ago
> Modern machines are so fast you can run an incredible amount of concurrency on a single large node, so why bother too much with scaling. Because that node might die any second.