Maybe I am wrong, but I have always perceived that the influence of Japanese culture on America is no longer as strong as it was in the 90s and early 00s. That could be my childhood bias though.
Japanese pop culture (specifically, anime and video games) seems to have become more mainstream in the US across various demographics, likely due to the web and streaming services like Crunchyroll and obviously video games, but also because the generation that held it as a cultural niche has grown up and become the standard bearers for current American culture.
Mainstream pop and rap artists are making anime references in their music now, and plenty of modern animation and movies making nods to it, even adopting the anime aesthetic (like Avatar, Teen Titans and RWBY.)
pretty much the entire deep learning community is still using python 2.7. I have moved onto python 3.6, but Julia is still an unsafe bet because it has an unreliable community behind it.
What does unreliable community even mean? As far as I know the Julia community is strong and healthy. Just check out their discourse site or slack overflow tag julia-lang.
First of all, I am deeply involved with Julia, so be wary of any biases as I try to stay objective.
Lattner et al. outright says that "[We] picked Swift over Julia because Swift has a much larger community, is syntactically closer to Python, and because we were more familiar with its internal implementation details - which allowed us to implement a prototype much faster." and I only buy the last point – which, mind you, is an argument I would have made as well if I was sitting on a whole team specialised in a language. They acknowledge that “Julia is another great language with an open and active community”, so I would hardly say that your “unreliable” statement is shared by them.
Apart from the very strong practical argument made above, I think “Deployment” is really what it boiled down to. When Google launched TensorFlow, the general sentiment among many in the research community was “why”? As in, why this big move on the part of a major corporation? Back then I stated that the reason I saw was that for better or for worse, Google – and many others – see a future where Machine Learning (or Artificial Intelligence, if you prefer) would be embedded into almost any product. For this to be feasible, you need: know-how throughout the company, see the excellent TensorFlow tutorials/training, and the ability to deploy models across their entire spectrum of devices/environments. This is what it would mean to be an “AI first company”. One of the reason why TensorFlow at its core is a static graph, I would bet is because they saw deployment as key back then, as they do now.
However, TensorFlow is the very embodiment of the “two language problem” [1]; as anyone that tries to wrap TensorFlow in language X quickly realises, pretty much everything you care about on a high level of abstraction is written in Python and the underlying C++ API is about as bare bone as it gets. Fun fact, this is why TensorFlow.jl [2] goes through both the Python and C++ API. Now, add to this that PyTorch recently arrived on the scene and quickly became a very real “threat” to TensorFlow since dynamic graphs (eager execution) is far more intuitive to work with and enables you to express a richer set of models. However, it suffers from deployment issues since it is intrinsically tied to the Python interpreter. TensorFlow Eager was most likely a stop-gap measure and it was perceived to be clunkier than PyTorch, also after TensorFlow Fold being left to rot I sincerely doubt that many are willing to buy into yet another code branch to interoperate with TensorFlow “proper”. This all sets the stage for the TensorFlow Swift announcement.
From my academic perspective, this is a great time to be a Machine Learning researcher; we have plenty of options and the attention we are receiving from other software and hardware communities is amazing. As for Swift “vs” Julia, they both have their own issues.
Swift has a non-existing scientific computing community (this is why I find the “much larger community” argument disingenuous, as mobile application developers do not count in this particular case), they will have to build it entirely from scratch and community building is difficult. But they have the power of Google and its minions to work on the software itself (Hello DeepMind employees, have you gotten over the sour taste in your mouth from being forced to switch from Torch (Lua) to TensorFlow (Python) yet? I suspect Mountain View has ordered another meal for you!), perhaps this is sufficient to overcome the current lack of a community? Time will tell. There is also the problem of external collaboration that we have seen with TensorFlow, while it is open source the direction of the development is partially hidden which makes bringing in open source contributors trickier than necessary – think, no unified public forum where things are discussed.
Julia, while it has a (strong?) scientific computing community, it lacks static compilation from the perspective of “deployment” and is ultimately a team of ragtag researchers and open source contributors spread across the globe. Can they keep up? Again, time will tell. There is also the classic “issues” with Julia not being statically compiled, but I can see this swing either way depending on the overall direction in preference for static vs dynamic over the next decade.
Ultimately, they are both on top of LLVM and I suspect that much will be learnt from the other; there is room for more than one approach. My decision to side with Julia is partially to stay my own course, partially a preference for “the bazaar” development model, and partially because I have a hunch that Julia has a better chance to capture the scientific computing community as a whole which is likely to yield benefits down the line. As I said before, time will tell.
It's going to have enough comparative advantage when a bit more mature that I can see it drawing off from the python community and entrenching itself as a serious contender.
I actually do the same thing. Do the dependency install inside of a docker container in order to build the .zip. This is absolutely essential for compiled libraries in python or anything that involves postgresql. If you attempt to install psycopg on mac and then deploy that on lambda it will fail. So you either need a prebuilt version for ubuntu that you keep around, or you need to build in a docker container. We just build inside a docker container.
Yeah, it works really well, also allows me to configure CI/CD in VSTS/TFS via Windows agents for AWS deploys to Lambda. In the end, I'm pretty pleased with it. I've mostly used Node, but Python binary dependencies would have the same need.
Not entirely sure why I got the downvote, other than the tongue in cheek aspect and "lol" at the end.
There are probably many on HN who can answer this better than me, and it of course depends on what role you are interviewing for . But IIRC, for Engineers the process involves a technical phone screen, followed by a second technical interview plus a behavioral/EQ interview. After that, your application goes before a hiring committee.
I can provide 100% assurance of that. We choose projects based on "Doing the most good, for the most people, in the most need". It could be easily argued that the vast majority of our work, focuses on helping vulnerable populations. I've been here 10 Months and never had a single ethical concern. Furthermore, I firmly believe this is the kind of organization that would be fully supportive of anyone vocalizing any ethical concerns they personally had, in fact this would be encouraged.
I have not yet committed to a deep learning framework, as up until now, I was mostly either using scikit-learn or building neural networks from scratch, straight numpy (lol)
I've heard a nice thing about Keras is that it forms more of an abstraction on top of other libraries, though I could be misunderstanding.
I don't have a lot of experience, but I recently ported an RNN model from lasagne/theano to keras/tensorflow, and the latter combination was about 4x slower. Not sure whether it's keras or tensorflow causing the slowdown. The API is nice though.
I also tried to flip the keras switch to run on top of theano instead but it had issues that I didn't have time to fix, so I just stuck with the original lasagne/theano stack.
