Jamey Sharp On Whether You Should Translate Your Code To Rust

[Passso]

rust???

Rust utterly failed to make its case and instead

this is Sparta!!!

[doom_Oo7]

The plus side of a GUI toolkit written in Rust is that it would be super portable to every programming language in existence that can interface with C.

You know that C cannot call Rust code, right ? You have to do exactly the same in Rust to make your code portable to C than you would in C++ : wrap your code in an extern block, and only use C-safe features :

In Rust : https://doc.rust-lang.org/book/ffi.html
In C++ : http://en.cppreference.com/w/cpp/lan...nguage_linkage

Basically, the only thing that is compatible with C is C. Any language with more advanced features will have to make some compromises at some point to be able to be talked to by a C program.

[kaprikawn]

We've got this problem at my workplace. We've got a whole bunch of software, some of it written in-house, some of it provided by third-party vendors. There was a push in the last few years to increase the amount we develop in-house because of the cost of making changes to the third-party solutions on an ongoing basis was creating problems. More often than not we'd just make do without making the changes rather than pay the third parties. And we'd struggle on with sub-optimal software.

So now we've got a whole bunch of new developers, and they came in and started writing new software. They looked at the requirements and decided the best tools for the job were a whole bunch of technologies not used by my company before. And when they finished their first major deliverable, they couldn't hand it over to the IT support team for day-to-day running of this software. The IT support team, like their name suggests, supports every other piece of software in our business, including third-party supplied software. But they don't support the software these new, in-house developers have done. Why? It's because they've used technologies that the support team are unfamiliar with. And the developers are having to do the day-to-day support.

I can't tell you the amount of problems this causes. For example, IT support are set up to provide out-of-hours cover because of the nature of their job. If a server has a hiccup at 2am, the on-call person is notified by SMS or some other means and they sort it out. The developers are strictly MON-FRI 9-5. This is just one example amongst many.

The point I'm trying to make is, all the people who contribute to the core open-source software are familiar with C and/or C++, because that's what the software is written in on the whole. I don't see the benefits of Rust outweighing the cost of transitioning to a technology that fewer people are familiar with. One of the major strengths of FOSS is that new contributors can come on-board with just knowledge and ability, and they can strengthen a project. But if you've written your code in a fringe language, you put up an unnecessary road block to new contributors. 'I want to and can contribute to project z' vs 'I want to contribute to project z...but I'll have to learn Rust first', doesn't seem like a viable way of fostering open-source to me.

TL;DR - Rust isn't enough of a game-changer to warrant requiring OSS developers to learn it so as to be able to support it and contribute to it on an ongoing basis.

[defaultUser]

We've got this problem at my workplace. We've got a whole bunch of software, some of it written in-house, some of it provided by third-party vendors. There was a push in the last few years to increase the amount we develop in-house because of the cost of making changes to the third-party solutions on an ongoing basis was creating problems. More often than not we'd just make do without making the changes rather than pay the third parties. And we'd struggle on with sub-optimal software.

So now we've got a whole bunch of new developers, and they came in and started writing new software. They looked at the requirements and decided the best tools for the job were a whole bunch of technologies not used by my company before. And when they finished their first major deliverable, they couldn't hand it over to the IT support team for day-to-day running of this software. The IT support team, like their name suggests, supports every other piece of software in our business, including third-party supplied software. But they don't support the software these new, in-house developers have done. Why? It's because they've used technologies that the support team are unfamiliar with. And the developers are having to do the day-to-day support.

I can't tell you the amount of problems this causes. For example, IT support are set up to provide out-of-hours cover because of the nature of their job. If a server has a hiccup at 2am, the on-call person is notified by SMS or some other means and they sort it out. The developers are strictly MON-FRI 9-5. This is just one example amongst many.

The point I'm trying to make is, all the people who contribute to the core open-source software are familiar with C and/or C++, because that's what the software is written in on the whole. I don't see the benefits of Rust outweighing the cost of transitioning to a technology that fewer people are familiar with. One of the major strengths of FOSS is that new contributors can come on-board with just knowledge and ability, and they can strengthen a project. But if you've written your code in a fringe language, you put up an unnecessary road block to new contributors. 'I want to and can contribute to project z' vs 'I want to contribute to project z...but I'll have to learn Rust first', doesn't seem like a viable way of fostering open-source to me.

TL;DR - Rust isn't enough of a game-changer to warrant requiring OSS developers to learn it so as to be able to support it and contribute to it on an ongoing basis.

Learning a new language/development environment is a non issue if this new shining toy is sufficiently familiar to what people is used to do. How many projects based on node.js, golang,julia, scala appeared in the last 4, 5 years. But for languages that departs from the traditional way like pretty much all functional languages, like haskell and ocaml the number of projects stays rather small

[bug77]

kaprikawn You'd think updating the support team on the new technologies used would have been the next logical step after starting using said technologies.
What you're describing is mismanagement. I experienced it first hand when rewriting an application using the same language and largely the same tools. You leave support out of the loop, you get bitten.

[nomadewolf]

For new projects, Rust should be the way to go.
Will it create some problems? Sure! Is it worth it? Absolutely!
Redox OS has show so much in so little time. It showed already that it is possible.
Rust might not have much following right now, but if Redox becomes sucessfull, i think it can really push Rust forward.
And would be a good thing.

[cl333r]

I think we should work on developing a new GUI toolkit written in Rust rather than pursuing Qt support. The plus side of a GUI toolkit written in Rust is that it would be super portable to every programming language in existence that can interface with C. So, you shouldn't fault any language for not having good wrappers for Qt.

A new GUI remotely close to Qt will take 6-8 years to develop if successful. I've had enough waiting for Wayland for 10 years which many thought would take 3-4 years.

"you shouldn't fault any language" - you shouldn't dumb down my words to platitudes, I didn't say or imply Rust is somehow a faulty language (it's a very good language), I said it doesn't have mature (Qt5) wrappers, and it's a serious unsolved issue regardless of how hard it's to overcome it.

[nomadewolf]

TL;DR - Rust isn't enough of a game-changer to warrant requiring OSS developers to learn it so as to be able to support it and contribute to it on an ongoing basis.

IMO the problem is this:
C (and by C, i mean C, C++, etc) is good. Very good. And does everything we need.
Everyone likes to and is used to programing in C.
Therefore, it's not about a new language that is a game changer. But rather, a language that does something that cannot be done in C and that something is vital.

[stqn]

TL;DR - Rust isn't enough of a game-changer to warrant requiring OSS developers to learn it so as to be able to support it and contribute to it on an ongoing basis.

But there are many developers who do not want to program in C++ and are happy to see better languages coming.
(And no I’m not talking about Rust; last time I checked its home page was written so only compiler writers could understand it, so I stopped there.)

[Holograph]

Do you want your code to be useful in the future? If so, then avoid "fads" like Rust. They never last.