Hacker News Reader

Comment by Eridrus | Hacker News Reader

I'm surprised by all the negativity in this thread. The need to write C++ components for models is pretty real when you need things to be fast and run on CPU. God forbid you ever want to deploy that on some sort of accelerator, necessitating a rewrite to CUDA or whatever language that accelerator speaks.

Maybe that's too niche of a subject for people to really care about, and maybe it's going to fail now that Lattner is gone (though there still seemed to be a bunch of activity last I checked), but the problem it is trying to solve is real.

View on HN

The negativity is because they were never serious about it.

While C++ might not be the ideal language, choosing one that only works properly in Apple platforms, dismissing the complaints of lack of any solid roadmap in platforms that researchers actually use and hand waving any usability problems to just use notebooks in Google Compute cloud is not how a language gains adoption beyond its initial niche.

I don't want to be that guy, but if they were going with a heavy handed language anyway, why not Rust? It has a good multiplatform support and most of the same benefits of Swift.

The article addresses this. Data scientists probably don't want to manage memory.

But that's not what you do in Rust? That's more of a C++ thing. I think you'd be surprised, Rust is much more similar to Swift than you'd think. The biggest layer of complexity is fighting with the borrow checker in some cases, but that only really comes into play when you want to write something concurrent.

I love Rust and I don't know much about data science but from my understanding many data scientists are not hardcore programmers it the same way that many programmers are not necessarily great at sysadmin. It's a tool, but it's not really the core of their job. In particular they mention Python being very popular in these circles.

Switching from garbage collected and dynamically typed to manual memory management + static typing + borrow checker + trait-based generics is going to be a deep dive for these people. Maybe they'd end up better off in the end though, who knows. I personally think that dynamic typing and GCs are overrated and their benefits overstated but that's obviously not the consensus out there.

I guess the core of my argument is that none of these features need to be used. It's very easy to write basic scripts in Rust at least in my experience. Maybe you might encounter difficulty with the borrow checker occasionally, once in a blue moon now that non lexical lifetimes are a thing. Most of the other disadvantages also apply to Swift.

Either way, people will find a way to justify their preference. The people in question liked Swift, and there's nothing wrong with that.

Julia would have been the obvious choice, if Chris Latter wasn't leading the project, most likely.

Probably, yes. My point is if they wanted a general purpose high performance multi-paradigm language like Swift. But in general I think Julia would have been a better choice, so I agree.

Imo, Julia should’ve been the choice; I have never heard a single researcher use Swift for anything other than iOS coding (I certainly never have). But we will see how this plays out, I guess.

Their reasoning: "We love Rust, but it has a steep learning curve that may exclude data scientists and other non-expert programmers who frequently use TensorFlow." [1]

(I can't comment on that because I don't know Rust nor am I a data scientist!)

[1] https://github.com/tensorflow/swift/blob/master/docs/WhySwif...

Yeah it just sounds like a cop out to me, Swift's learning curve is equally steep to Rust in my experience. But as mentioned elsewhere, Julia would probably have been the best fit.

Perhaps it could be this: if my value comes from running some crazy interesting high level Math derived machine learning model on data and I’m highly paid the opportunity cost to invest the time and effort to both become good at and write C++ is higher than if I can do the same thing in a few lines of python and just throw some more compute at the problem since that’s a fixed cost.

parsing this single sentence would constitute passing an EFL exam in my book

Perhaps the most valuable writing advice I've ever received: “When you think one sentence needs 35+ words what you really need is two sentences.”

Yes, yes, I tend to ramble.

it wasn't meant as a dig - it seems perfectly valid and a good example of how much can actually be written in one sentence

> Perhaps it could be this: if my value comes from running some crazy interesting high-level Math-derived ML model on data, and I’m highly paid, then the opportunity cost of becoming good at C++ is higher than if I can do the same thing in a few lines of python and just throw some more compute at the problem, since that’s a fixed cost.

Add some hyphens and commas and shed a bit of cruft, and it's fine IMO. (I hope you don't mind my speculative editing.)

I appreciate the feedback. Defending wordy stream-of-consciousness writing style is not a hill I want to die on.

I did realize that if I have to throw a million cores at something vs. 1000 perhaps it would make sense to spend the effort or buy the time from an expert in C++ so as to save on the compute cost. But then, what if those million cores are only needed for a a day or an hour? Then python or some other rapid prototyping language would make a bit more sense imo.

Cheers!

there was no need for that, see my response 3 hours prior

> I appreciate the feedback.

> Defending wordy stream-of-consciousness writing style is not a hill I want to die on.

prospective politeness is not a basis for justification

Compute is most definitely a marginal cost rather than a fixed cost....

And when you start talking about buying 10s of millions in additional hardware to support the project you're trying to launch you start thinking pretty hard about whether you can speed things up.

And for practitioners most of this is not crazy high level math, it's first year linear algebra and multivariable calculus at most, and generally just lego blocks, intuition and data work.

Reply on news.ycombinator.com