3 ms·
I name that the isolated island syndrome. If you wait long enough, any stable working solutions will be reinvented in its own Language. It's completely unprod
by adev_ 7y ago
I name that the isolated island syndrome.
If you wait long enough, any stable working solutions will be reinvented in its own Language.
It's completely unproductive. But there is reason to that: compatibility with the language toolchain and understandability.
- nevi-me 7y agoit has to be done at some point. I still have vcpkg on my Windows machine, because I needed to install it and a few GB of other things, just to use PostgreSQL in Rust a few years ago (I think Diesel). If someone hadn't implemented the libpq protocol in Rust, I likely wouldn't have written in binary copy support on the dataframe in one afternoon. This reduces the barrier for people to productively use their favourite languages. It might be unproductive at first, but we see the benefits as time goes on.
- adev_ 7y ago> This reduces the barrier for people to productively use their favourite languages. It might be unproductive at first, but we see the benefits as time goes on. It is vastly unproductive to reproduce anything useful in 10 different language just because our cross-language tooling awfuly suxxe. The lack of cross-language dev-oriented lead us in the ridiculous situation where every language has its own package manager and his completely unable to use a package made for an other language. There is reasons to that... but much more political than technical and that's the sad state we are in.
- imtringued 7y agoI don't understand how it is completely unproductive. Surely there must some advantage that Rust has over C++? If that advantage exists then there is your justification for reinventing something that already exists. If all you do is reuse existing C++ libraries in Rust then why even bother with Rust in the first place? Why not just use C++ directly? Well, the most of the value from using Rust is derived from the things that are written in Rust. Let me give you an example but this time with Groovy. Groovy runs on the JVM and that means it benefits from the existing JVM ecosystem, right? Well, of course you get the benefit of existing libraries but there was a crucial difference between using them through Groovy/Grails than natively through Java. There were lots of grails plugins that were very thin layers above the Java libraries yet somehow the usability increased a hundredfold. A small plugin with maybe 1000 lines of code ended up providing more value to our business than the part of the library that was written in Java.