[wokwokwok]

> comparatively tedious languages like Rust will never attract data science practitioners.

Well, fast.ai is using swift now.

... I think it's fair to say 'never say never'.

You're probably right, rust isn't really the sweet spot for this stuff, but its also a case that python has some down sides that are pretty severe, and well acknowledged.

[chillee]

Just because fast.ai has some investment in Swift does not mean that S4TF has attracted mind share. The bulk of fast.ai is still taught on Pytorch.

[wokwokwok]

The parent comment literally said data science practitioners don't care about speed or safety because the GPU is where all the real work happens; that's false, I've provided an example of it being false from a respected party. What do you want me to say?

eh, I give up. Believe whatever you want to believe.

[chillee]

I'm not saying that no data science practitioners care about speed and safety, and its easy for me to come up with cases where they should/do care.

My point is that even fast.ai still views S4TF as somewhat niche, and that data science practitioners as a whole still don't care.

[MiroF]

I am a practitioner, I care, but everyone on this thread seems to be distracted by the red herring of speed and efficiency.

None of these languages are going to be speedier in the GPU. But python has serious design problems that manifest itself when developing a large project.

You can only go so far with dynamic typing

[melling]

I wouldn’t call Swift a tedious language.

With type inference, immutability, etc, Swift is far from tedious:

http://www.h4labs.com/dev/ios/swift_cookbook.html?topic=stri...

http://www.h4labs.com/dev/ios/swift_cookbook.html?topic=dict...

It’s not quite as nice as Python but it’s an enjoyable language.

[wokwokwok]

> They don't care about the kind of safety it brings, they don't care about improving performance in a component that's idle 99% of the time.

https://www.fast.ai/2019/03/06/fastai-swift/:

> Because Swift for TensorFlow is the first serious effort I’ve seen to incorporate differentiable programming deep in to the heart of a widely used language that is designed from the ground up for performance.

> But Python is not designed to be fast, and it is not designed to be safe. Instead, it is designed to be easy, and flexible. To work around the performance problems of using “pure Python” code, we instead have to use libraries written in other languages (generally C and C++), like numpy, PyTorch, and TensorFlow, which provide Python wrappers. To work around the problem of a lack of type safety, recent versions of Python have added type annotations that optionally allow the programmer to specify the types used in a program. However, Python’s type system is not capable of expressing many types and type relationships, does not do any automated typing, and can not reliably check all types at compile time. Therefore, using types in Python requires a lot of extra code, but falls far short of the level of type safety that other languages can provide.

ie. My point: OP's point is categorically false.

...not that swift is tedious. I <3 swift.

[kuzehanka]

...But fast.ai is a Python library. Partially written in swift.

Validating the original point that nothing will replace python for DL applications any time soon but middleware will continue to be implemented in c++/rust/swift/whatever you fancy.

S4TF isn't the first and certainly not the last end to end non-python DL stack. It might be worth highlighting as an example if it ever reaches mindshare above the noise floor amongst those stacks.

[wokwokwok]

> Our hope is that we’ll be able to use Swift to write every layer of the deep learning stack, from the highest level network abstractions all the way down to the lowest level RNN cell implementation. There would be many benefits to doing this...

Well, the tldr: you’re wrong.

The more approachable reading: python isn’t going anywhere, but people are looking at other things for more than just low level implementations with a python wrapper.

...it’s early days yet, who knows where things will go... but maybe do a bit more reading and have an open mind?

There’s more to life than python.

[skohan]

Python is easy to get started with, but once a project grows to any meaningful size, I would rather have a compiler which is giving me more correctness guarantees than Python is capable of.

IMO Swift strikes the best balance between strictness and productivity of any language I've worked with.

[ImNotTheNSA]

> Python is easy to get started with, but once a project grows to any meaningful size, I would rather have a compiler

boy do I have a continent full of python developers to introduce you to... “python - by any means necessary” is their motto.

But in all seriousness, there are a lot of people (where I work) who started with python and have been daily driving it for so long that any other language is too tedious to get started with. Even if it means writing unreadable, hacky python, python still wins out for them.

I suspect there are a lot of similar people in data science.

[frutiger]

Rust has those too, GGGP still considered it tedious.

[antisemiotic]

I think the tedious part would be the borrow checker. Also, Rust doesn't have top-level type inference (by design).

[skohan]

Yeah there is some tedium in general with Rust syntax. Semicolons, for example, feel old fashioned, and there's a lot of verbosity in things like unwrapping. It's a fine language and I like working with it, but there's a lot of details involved in Rust development which don't make sense for data scientists to worry about.