Is Rust building up a decent ecosystem now for application programming? When I tried developing in Rust I came to the conclusion that you pay a heavy price for not having a garbage collector. Was I doing it wrong?
It's a general purpose language, but it does give you full control. Plus, of course, you can encode a large amount of program states in the type system and borrowing checks enforce rules that programmers usually have to check in their head.
I find that when I write Rust, I have to worry about an order of magnitude less about silly things like lifetime bugs, reference bugs, resource cleanup, all of which are 80% of my job when I write C#, or other similar managed languages.
Plus Rust can generate a static executable, which is reasonably small, and doesn't require a third party runtime.
Rust executables are only 100% static on OSes that expose system libraries as static libraries, and there are not many of those around, outside embedded systems.
If I could get all of those quality of life things in a language with a garbage collector, I'd probably use that for most things instead. Right now though, the closest options would be maybe OCaml or Swift, one of which doesn't really give me nearly as much in terms of quality of life stuff around documentation and tooling, and the other isn't nearly as streamlined to use on my platform of choice as I'd like, so I'm using Rust unless (or until!) something better for my personal projects comes along.
Even shipping the whole computer on a container, might not do it, because most containers are leaky abstractions the way their Dockerfiles are written.
Sure, you might get a loading error if you try to run your Ubuntu 24.04-compiled executable on Ubuntu 18.04 if you use the default toolchain. tTat’s exactly the same as C or C++, only much easier to fix in rust by rustup-installing the right tool chain.
Compiling on Ubuntu 18.04 and running on 24.04 is absolutely not an issue. Same for windows.
In practice this is really not a problem, especially for cargo libraries that you anyway build from source.
Not even modern 3D graphics APIs, none of them, work with static linking, yet another area static linking advocates have to accept the industry has moved on.
This seems to be a weird hair to split. GP clearly means “a single executable you can run on any install of the target OS without dependencies.” Whether it’s a truly honest-to-goodness static binary that don’t link to libc or libSystem or whatever is important to approximately zero people, outside of internet pedants.
However, it is not achieved in practice with "static" languages like rust and golang for me
I frequently run into dynlib issues with regards to incompatible glibc references when sharing binaries between different OS like Ubuntu and Fedora or even just different versions of the same OS
Assuming you’re talking about rust binaries, this would only happen if your binary is using glibc symbols that don’t exist on an older version of glibc, and then try to run that binary on a system with the older glibc.
But glibc is a red herring here, because rust is only using libc to call syscalls on the host, because that’s how you’re supposed to do it on every OS, and that’s how you have to do it on every OS but Linux. (Only Go seems to want to implement their own syscalls on Linux.)
It’s a red herring though, because even if rust made their own syscalls and didn’t use glibc on Linux, you’d just fail with ENOSYS when these syscalls are used, instead of failing with undefined symbols at load time. If you try to run stuff that was developed against newer kernel features, on a system without these syscalls, you’re going to run into an equivalent issue. (You might get lucky and not need those syscalls in your app, but that’s not always going to be the case.)
Ironically the same folks don't see to appreciate how object files and binary libraries work in static linking, lets make it even better compiling always from source.
> Good dependency management, a rich package ecosystem, defaults to static binaries which are easy to distribute and a tendency to be fast (even if it’s just the lack of startup overhead) make it a popular choice.
> .....
> Plus Rust can generate a static executable, which is reasonably small, and doesn't require a third party runtime.
Somewhere this thread....
And guess what, you can also ignore my comments.
They use static binary to mean “the dependencies I specify in my package manager are all put in the one binary, and it doesn’t require a separately installed runtime to run”, which is totally reasonable, and it is opposed to so many languages that don’t work this way.
You’re using static binary to mean “does not link to anything at all”, which on some systems results in worse portability, since the syscall interface is unstable and linking to libc/libsystem/etc is the only supported way to make syscalls.
You come into the discussion assuming definition B, ignore the fact that they’re using definition A, say that they’re making a big deal about definition B, etc.
There’s no confusion from anyone here but you. We all are using definition A. You’re the only one using definition B. It’s probably better if you just recognize that and move on rather than insisting everyone here is an idiot but you.
In fact there are a bunch of them for the terminal.
1. Historically a CLI like this would often be written in C, so Rust isn't that strange of a choice.
2. Rust is know for the borrow checker and being a great low level language. However, it's also an excellent modern general purpose language with a great ecosystem. People end up using it for all kinds of things because it's a joy to use.
"When I tried developing in Rust I came to the conclusion that you pay a heavy price for not having a garbage collector. Was I doing it wrong?"
Rust is tricky to grasp initially, the learning curve goes pretty much vertical immediately, but once you "get it" it's very nice. When I started out I overused borrowing and ran into heaps of lifetime problems. I think limiting yourself to only using references for function arguments and, rarely, return values is a good place to start. As soon as you are start adding references to struct you should stop and think about who owns the data and what its lifetime is. Thinking properly about ownership is the big shift from GC languages. Once you've gotten into that habit, lifetimes are downstream from that.
*Perl
I don't face much friction from the borrow checker to consider it a 'heavy price for not having a garbage collector'. There are even tools like bacon [1] that can give your real-time feedback on your code. It's even better with the default language server. I sometimes train other developers in Rust - mostly people who are not even into systems programming (JS, Python programmers). However, they don't seem to struggle too much with the borrow checker either. Could you elaborate a bit on what you consider as 'the heavy price'? What sort of issues were you facing frequently?
I will say that rust is pretty damn productive once you organize your brain around ownership. I haven't had to mark a lifetime in over a month.
I also recently started some open source projects (mostly CLI tools) where I picked Go for one reason: Rust’s learning curve is super steep.
In order to make my projects approachable for other developers Go seemed to be a better choice over Rust.
You do pay a bit in syntactic overhead (lifetimes, borrow checking perplexities), though you get used to it. I'd still not use it for a standard product-y web app. For CLI tools though, it's pretty good.
Give it a try.
It also helps that rust attracts the kind of devs that make nice tools.
This is because empirically, they usually work better, feel more polished, faster and I can easily contribute patches if I need. If a tool is written in Python, I’ll go out of my way to find a rewrite in another language.
It's just wherever you go, here, Phoronix, Linux Kernel Mailing List for example, the forums are full of haters that just ask "not again, why?" anytime Rust is mentioned. Maybe I've become biased because of that.
Rust helps with performance and security, lots of examples are evidence of that. It's not 100% bulletproof, but nothing is. But it helps. And yet IT people just yell on it for some reason. Like we all should just get stuck forever with C, C++, praise Go, and hate everything else.
Honestly though I thought we were past the "written in Rust" phase.