Hacker News Reader

Comment by ablekh | Hacker News Reader

Interesting post and excellent discussion. I have the following question to all Julia and/or Python experts here. What strategy for developing a cloud-native {science and engineering}-focused platform would be better, in your opinion, and why: A) develop an MVP and then relevant production platform in Python, spending some saved time and efforts (due to simplicity, [as of now] better tooling and much wider pool of experts) on development of more and/or better features; B) develop an MVP in Python, then rewrite it for production in Julia for much better native performance, GPU integration and potential use of macros for an embedded DSL; C) take more time initially to master Julia and develop an MVP and then the corresponding production platform in Julia from scratch?

EDIT: Forgot to mention that HPC workloads would represent a significant, albeit non-unique, aspect of the platform in question.

View on HN

I’m a bit biased as someone who switched from Python to Julia for my physics research (I.e. I’m biased to believe I made a good choice and others should follow my decision making), but I think any extra effort you spend in the beginning to get it working in Julia will pay big dividends.

In the scientific world, Julia’s package ecosystem is already more developed than Python in some fields (Differential equations being one, but there are others), so you may not find that limiting you.

Furthermore, for the reasons laid out in the article, Julia is highly composable and empirically, has a far greater ratio of code re-use than Python. I believe you’ll see greater bang for your buck in Julia because code you write is more likely to be re-used, especially in scientific domains.

Your blazingly fast and thoughtful comment is much appreciated. Let's see what others have to say ... :-)

One clarification that I would like to make (which IMO diminishes your second point's potential value) is that the B2B SaaS platform that I plan to build would stay away from implementing a myriad of domain-specific scientific methods and algorithms (though I plan to provide a valuable core) and rather would enable users to integrate their own implementations (through a plug-in architecture). Thus, Julia's package ecosystem seems to be a factor of somewhat lesser importance.

I would avoid the two language problem so option B is out of the way. If you choose option A, then you run into a risk of having to optimize some part of the code in C/C++. So you end up with the two language problem again. If you care about performance, then option C is not a bad place to be. Learning Julia is not a big deal. It would not take a seasoned developer too much time to get up to speed with it. What I found is that the Julia community is so vibrant that you can get a lot of help to move along quickly. My two cents.

Thank you for sharing your helpful insights. I will continue learning Julia as well as exploring and comparing options (in addition to Python and Julia, I'm also considering Node.js and C#, though to a lesser degree). I have certainly noticed the vibrancy of the Julia community, however, to me, as a startup founder, the problem of talent availability still represents a significant issue - community help can get us only so far. Most Julia developers are academia/science-affiliated, with a smaller number of people employed in the industry, mostly in sectors like finance and energy - so, a very limited talent pool makes it quite challenging to build a very good engineering team, at least, in the near term).

Reply on news.ycombinator.com