Hacker News Reader

Comment by naikrovek | Hacker News Reader

People gripe about the strangest things.

After using Go almost exclusively for about 18 months I have had to interface with existing C libraries exactly zero times.

View on HN

I think it's less an issue of the average programmer using FFI and more an issue of common libraries leveraging it.

With python, why is it so popular currently? For large part because of its very good data science and machine learning ecosystem. And why does that exist? Mostly because python libraries like numpy, theano, and scikit-learn were built on top of mature, high-performance C libraries like OpenBLAS, LAPACK, and Cuda.

I very much doubt that anything like scipy would exist if the developers had to reinvent the wheel of the underlying numbers libraries from scratch. C's been around a long-time. There's huge amounts of high-quality mature software that already exists in a C framework. A language's ability to easily "plug-in" to the C ecosystem is a major leg-up when it comes to bootstrapping its own comprehensive library ecosystem.

How is FFI remotely strange? Not everyone is doing webdev, and even then, you would be surprised how many libraries are leveraging C ones.

I've run a few semi popular open source projects, and it's surprisingly common to hear people tell me it's useless because it's lacking their specific pet feature. Now these comments just make me laugh, just like the parent's gripe with slow FFI

Calling the FFI a pet feature is nonsense.

I think you don't get the point. Most people don't create such interfaces, but the libraries/systems they work with use them a lot, at least in other languages.

This is for example the reason why there won't be a large mathy/scientific ecosystem in golang.

> This is for example the reason why there won't be a large mathy/scientific ecosystem in golang.

That seems weird. Go has a pretty large (and growing) Data Science Community.

Lots of Math/Scientific stuff there, especially including many people from Python and Ruby backgrounds.

Python needs FFI, because its native performance is fairly poor [1]. In general, Go gets away with less FFI because it's fast enough that it doesn't need things to be implemented in C to run quickly. This is especially true if you consider "Go" as "Go + its ASM", which is probably what you'd want if you think of it in terms of science programming.

For another example of a similar effect, Rust has great FFI. Yet I would expect over time it will be necessary for fewer and fewer things, because Rust is already roughly on par with C, and over time, a native Rust API will still be preferable to a C API wrapped with a Rust access layer. It will always have great C FFI, by its nature, but the percentage of projects that won't need it is already pretty high and probably only going up over time.

[1]: People seem to misinterpret this statement a lot, as if I'm saying Python is bad or something. No; it is simply this: Python performance is not very good at a very raw level. It is merely one characteristic of a language out of many, many relevant ones, not a full assessment of the language. Python has many other dimensions in which it has superior capabilities. It just pays for that on the performance dimension. (Whether that's an essential or an accidental tradeoff, well, ask me again in ten years; the programming language community seems to be in the process of working that out right now.)

If the go-silo offers everything you need than yes, there is no need for a good FFI in go... but if you want access to the low-level ecosystems of C/C++/Rust without a heavy penalty, then it might not be an option.

It's not just about speed. Great mature libraries have been written in C over the decades. Rewriting them in a new language is a herculean effort. Writing bindings to them lets you use the fruit of all that labor.

What you say is true, yet, I observe that people undertake that herculean effort with some frequency.

Whether that's a good idea, and why that is, those would be entirely separate conversations. But it's just an observable fact that languages pick up native implementations of core functionality over time, subject to certain performance restrictions (e.g., I'm sure that if it wouldn't be unusably slow, Python would have a native-Python image library... it's just Python doesn't really have that option).

The effort I'm familiar with is the many attempts to make a decent linear algebra library in haskell. There are a number of libraries with huge work put in, but none has reached blas/lapack parity. Nothing's remotely comparable to numpy in ease of use yet. It picks up more libraries as time goes on, and the existing ones mature, but it's so slow that I'm skeptical they'll ever match numpy's usefulness a decade ago.

I think it's really easy to focus on the big hitters and forget they are the exceptions. Yes, matching lapack, any GUI toolkit, a browser engine, and a handful of other things is a big challenge that takes its own community to overcome, not something any language community can do with an incidental fraction of the community's available firepower.

But those are the exceptions, and often you don't need a best-of-breed solution and may prefer the language-native one.

Again, I'm not theorizing about what could be here; I'm looking out in the world, where I see that most libraries tend to emerge out into a native version if the underlying language can possibly meet the basic requirements for performance and such. This is something that needs to be explained, not explained away.

Also... I love me some Haskell, and on a per capita basis the community is great, but if Rust's community isn't already several times larger and growing faster, I'd be stunned, just to pick one example. Haskell has some very interesting cases of best-of-breed libraries, but it doesn't exhibit the library profusion you get from sheer personpower. (Of course, it doesn't really have the problems you get when your libraries are generated by sheer personpower either.)

> if Rust's community isn't already several times larger and growing faster, I'd be stunned

I'd love to see the numbers on that if you know where to find them.

Reply on news.ycombinator.com