←back to thread

205 points michidk | 1 comments | | HN request time: 0s | source
Show context
dazzawazza ◴[] No.41835253[source]
Access to competant Rust developers can be a challenge even for large companies.

I recently finished a contract at a (very large game dev) company where some tools were written in Rust. The tools were a re-write of python scripts and added no new functionality but were slightly faster in Rust.

The reality was that these tools were unmaintainable by the rest of the company. Only the author "knew" Rust and it was hard to justify a new hire Rust developer to maintain this small set of tools.

The only reason these tools were written in Rust was because the dev wanted to learn Rust (a big but common mistake). I pointed out to the Technical Director that this was a big mistake and the teams had taken on a large amount of technical debt for no reason other than the ego of the wanna-be-rust-developer. Since I "knew" Rust he wanted me to maintain it. My advice was to go back to the Python scripts and I left.

replies(21): >>41835266 #>>41835268 #>>41835305 #>>41835386 #>>41835427 #>>41835460 #>>41835522 #>>41835570 #>>41835607 #>>41835745 #>>41835838 #>>41836318 #>>41836384 #>>41836673 #>>41836742 #>>41837344 #>>41839371 #>>41840322 #>>41840444 #>>41846616 #>>41848063 #
gwd ◴[] No.41835305[source]
This question of "what tools / languages" should we use was introduced to me (during an interview, actually) as "technical strategy". There is more to the choice of language or tooling than whether it's fast or slow or reliable at one instant in time -- you have to ask how you will grow and maintain things going forward.

That said, obviously all languages were in that state at some point. Twenty-eight years ago you might have said the same thing about Java. Twenty-four years ago, Perl might have looked like a better choice than Python; now it's clearly the opposite. XenServer took a gamble and wrote their main control stack in OCaml in 2008; on the whole that has had some benefits, but the number of OCaml developers has not significantly grown, and it's not easy to hire people.

That said, I think Rust is much more likely to follow Java's trajectory than OCaml's: My prediction is that it's only going to be easier and easier to find Rust developers.

replies(11): >>41835318 #>>41835619 #>>41835744 #>>41835903 #>>41835951 #>>41837013 #>>41837218 #>>41837495 #>>41837561 #>>41838356 #>>41840370 #
adamc ◴[] No.41840370[source]
Twenty-four years ago, Python already looked better to me. I maintained a big Perl 5 app. Yuck. The problem wasn't that you couldn't write it, the problem was that you had to be able to read widely differing styles of Perl... and if you wanted to read library code, it was a huge pain. I quit maintaining that system in 2005, and it has barely changed since, from what I'm told.

Viability of a language is certainly a consideration, but the characteristics of the language also matter.

What you couldn't really predict about Java in, say, 2000, was how much the complexity of its ecosystem would grow. In 2000 (or 2005) it was fairly easy to move in and out of Java from project to project. That is not true today. My fear on the Rust front is that it's going to be another C++, where the complexity is considerable and requires more or less full-time expertise.

replies(2): >>41845136 #>>41846965 #
1. pjmlp ◴[] No.41846965[source]
In 2000, Java was still about doing dancing applets, businesses only started taking Java marketing seriously after two things happened, Hotspot became a thing, making it more appealing than C++ for cross-platform server code, versus dealing with the mess of writing portable C++ code when most compilers were a mix of C++ARM and catching up to C++98, with C++ compiler specific frameworks being heavily used.

The second one was Sun's Distributed Objects Everywhere project being canceled, and the Objective-C code being reborn into the first J2EE proposal.

There was nothing else like that for business software other than Smalltalk and later .NET, however most Java vendors were ex-Smalltalkers, and in 2001 .NET was a no-go for anyone that would care about supporting UNIX deployments as well.

In 2001, we were moving away from scripting + write extensions into C, into Java, and only pivoted into .NET because being a MSFT partner with access to the "partner eyes only" betas from Microsft before .NET was announced, additionally there was some ideas to move away from UNIX customers.

However by 2006, while at Nokia Networks, a strong UNIX shop back then, the large majority of their applications were going into the Rewrite into Java phase.