Tell HN: Rust is the superglue

Rust seems monumentally unsuited as a glue language like Perl or Bash. It is statically typed, compiled, makes strong assumption about the code, is relatively hard to write/learn and somewhat verbose.

Rusts reason for existence and main goal is replacing C++.

>For machine learning, we have the Py ecosystem

A very bad state of affairs to be sure and also not really true as python is just a thin layer ontop of the actual code running the networks, which are written in C++ or loaded of to GPUs.

Just FYI, the market for C++ is excellent and has been for years, but I've yet to receive any well paid Rust project offer. My impression is that most people working with Rust are idealists (and not businesspeople) and the salaries reflect that.

You maybe prematurely optimizing. The technological singularity will be realized when algorithms develop new programming languages, new hardware description languages, and so forth. We're not quite there yet.

There is no universal answer or panacea tool. Evaluating which tool to use from the toolbox depends on a particular use and who else will be working with it. Being flexible and experimenting should, at a minimum, improve one's engineering instincts even if a particular approach fails.

There won't be many engineering jobs left once self-programming systems and AI become consolidated by megacorps. The remaining jobs will be the "janitors" and AI architects. We won't need or be able to use 27 million software developers, perhaps only 10-100k in 20 years.

PS: In the meantime, run a model that can maintain and refactor COBOL. ;) Or, specialize somewhat to what's hot right now without worrying too much about the distant future.

First. I love F#. But it didn't take off in the market, so I'm learning Rust.

What I tend to see is that Rust does have a higher learning curve, because you have to change your brain's way of approaching problems. The 'functional' way of viewing things. (plenty of past flame wars on functional programming, so not trying to start that here)

Once you do learn Rust (or functional), it is safer, better, faster. But if you just came in from C++, Java, C#, and try and force that way of thinking into it, then it is difficult and crappy and you wonder what the fuss is about.

For Python. I tend to think if it wasn't for Machine Learning Libraries, it would have started to die off. It is super great as an ad-hoc, throw together some janky little script to tie some libraries together. It is very useful for new or non-programmers to just whip out something 'close enough'. Or as another poster said, the REPL that is similar to MATLAB. BUT -> Nobody builds big applications in MATLAB. So the use case is either, small janky scripts to do something small and useful, or as MATLAB with REPL which are also small scripts. Once a program gets to a certain size, it would be much better to graduate to something with at least type checking.

I do really hope that the giant ecosystem of Python does start to migrate to RUST. Ecosystems don't turn on a dime, so it will be years. And who knows, Python is also improving, maybe it's shortcomings will be fixed faster than the ecosystem migrates to RUST.

You can practice your Rust skills by writing performant and/or gluey extensions for higher-level language such as NodeJS (checkout napi-rs) and Python or complementing JS in the browser if you target Webassembly.

For instance, checkout Llama-node https://github.com/Atome-FE/llama-node for an involved Rust-based NodeJS extension. Python has PyO3, a Rust-Python extension toolset: https://github.com/PyO3/pyo3.

They can help you leverage your Rust for writing cool new stuff.

I think Python is probably way better suited to be the superglue you mention, and in many areas it already serves that function. Many Python libraries are high-level bindings for low-level C/C++/Fortran (or recently, Rust) libraries. Examples are numpy, scipy, tensorflow, PyQt, ....

Rust is great in the sense that it is very suitable for being embedded into other software as it doesn't have a runtime system (like e.g. Golang) and can be compiled for almost any architecture. Rust's usability for "regular" programmers and technical users is horrible in my opinion. I e.g. worked with scientists a lot (and was one myself) and in my lab everyone could wrap their head around Python in a couple of days and become productive very fast, whereas most people would throw in the towel when they had to write low-level code in C/C++. In terms of learning curve and complexity I would put Rust somewhere in the same ballpark with C++. There are many differences and Rust has a much better developer experience as it has a modern package manager and the toolchain is much nicer, but it's still a low-level language with many intricacies.

Rust can be used in a number of domains; from the use cases of programming languages I've encountered, its niche isn't one of the things you mention, and it wouldn't be my first choice. I think Rust's strengths are in these domains:

  - Embedded devices
  - Standalone applications
  - Operating systems / RTOSes etc
  - Performance-critical libraries

IMO, it's a replacement for C/C++ with higher safety guarantees. Of course it's more suitable for ML, and Web, than C/C++, but if there're no hard perf requirements, there're better options.

Rust is a welcome addition to the global language toolbox but I feel is mostly a mirage in terms of future breakthroughs in the language / programming space: It still falls under the "formal methods / program correctness" paradigm which has led people astray for decades. Like Gerald Sussman proclaiming (talking about Haskell):

"This is the most advanced of the obsolete languages!"

Watch this talk: https://www.infoq.com/presentations/We-Really-Dont-Know-How-...

Another great talk on the subject (also the biological model of dealing with complexity) is Alan Kay's "Programming and Scaling".

The Element team is writing its next generation Matrix SDK in Rust, which means that it can be embedded in pretty much any language.

Most of the early intention and excitement was the potential to replace C++, and maybe even at least a little C, in systems-level and native code. Obviously, it was first created to replace the JavaScript engine in Firefox, which was C++, but I know a lot of people working on basic utilities and libraries found all over the core components of any normal Linux distro who had hope we might get something equally performant and expressive to C++, but with a far better developer experience and language-level support for the more modern features that C++ tends to get from something like boost. Or look at things like ripgrep and what not, just trying to replace some of the common GNU coreutils, POSIX command-line things you expect a system to have. It eventually made it into the kernel, even, though only for device drivers and that's probably as far as it will get.

I would say this has so far not really panned out. Partly, this is because C++ remains and has always been good enough. Partly, because POSIX component replacements were not made as drop-in replacements, so you still need GNU coreutils and existing bash built-ins and what not if you want build scripts and system scripts to still work. Partly, because so much of the modern developer ecosystem is focused on web development rather than native system-level tooling and libraries that Rust has gravitated toward that because that is who is adopting it. Look at how, for instance, Rust versus Go has become so much more common of a question to see compared to Rust versus C++. It's clearly more expressive and full of features than Go, but unless your system really depends on very predictable latency to the point that garbage collection can't be tolerated, it's not clear there's any real value-add even if it's a "better" language.

Rust also suffers a bit from a problem faced by any new language on the scene. If you work in older languages like C, C++, Java, you automatically and easily interoperate with some many existing deployed systems. There's a tested, true, well-maintained library for just about anything you could ever want to do. You can start a project quite quickly by forking something similar that already exists. Languages that did well as up-and-comers had some compelling killer app they were connected to that gave them that ecosystem within some more narrow niche. JavaScript obviously runs in the browser and was the only option for a long-time if you want client-side code to execute in a user's browser. This also proved to be useful for cross-platform desktop apps when computers became powerful enough and disk space plentiful enough that just shipping a browser runtime with every application became a feasible idea. Go had Kubernetes and Docker's rewrite, so if you want to do anything related to container runtimes or orchestration, it's the obvious place to turn. Python came to dominate machine learning because it has great interoperability with native code and it could easily wrap pre-existing Fortran and C++ to get a BLAS and higher-level numerical libaries in a dynamically-typed language with a REPL that was more or less perfect for exploratory, interactive work, and the dreaded operator overloading that developers hate proved to be a great feature for attracting scientists, because it allowed SciPy and NumPy to mimic the syntax of MATLAB, giving a free version with near parity of something that normally costs five grand for a single-user license and researchers were already familiar with using.

Rust unfortunately sits in this unholy middle ground for easy adoption. It comes with a very nice build tool and package manager built-in, but the ecosystem unfortunately took on the JavaScript "bring in thousands of tiny libraries that each do one thing" characteristic that is antithetical to C and C++ with gigantic libraries that do everything. The syntax is like 80/20 ML/Algol, so people coming from a functional background will see it and wonder why it's so verbose and can't do better type inference and needs brace-delimiting. People coming from an imperative background will translate the classic "writing C in C++" thing to "writing C++ in Rust" because they don't fully grok the idioms.

The compile-time garbage collection thing is a great, very cool feature, not quite as good as something like Idris, but probably the best you'll get out of any language anyone actually uses, but it still sits in this weird middle ground. People coming from C and C++ will get frustrated feeling the compiler doesn't trust them but they're pretty sure they know what they're doing is correct. People coming from dynamically typed or garbage collected languages will just follow the suggestions coming from the rustc error messages until it finally compiles, but without really understanding what the hell the borrow checker is doing or why they need it.

If your idea is correct, then you're talking about replacing C++, which is the current backbone for JavaScript and Python. But think about what this entails. You're talking about rewriting the Chromium JavaScript engine on the one hand, and rewriting BLAS, LAPACK, Armadillo, TensorFlow on the other. Who is going to do this? You're talking about low-level systems programmers on the one hand and scientists, applied mathematicians, and engineers on the other. But most actual uptake for Rust is application developers working on relatively greenfield projects.

This is not /r/rustjerk

Rust is awesome and could replace both JS and PY at exactly what they’re supposedly good at. The main issue is compatibility and library availability.

Zig seems more interesting but it’s not mature enough yet.

I’ve been so spoilt with IDE support, documentation, massive community and ChatGPT for Python typescript and others that I really can’t pick up Zig yet.

One of the things I heard is that ChatGPT doesn’t actually “get” the hard parts of rust, and that’s a huge issue because the whole point of AI in programming is it’s meant to be able to lead and guide you in learning and understanding.

“Rust is so hard to learn that the AI doesn’t get it” is a bad place to be for rust.