11 ms·

Before making criticisms that Garbage Collection "defeats the point" of Rust, it's important to consider that Rust has many other strengths: - Rust has no over

Before making criticisms that Garbage Collection "defeats the point" of Rust, it's important to consider that Rust has many other strengths: - Rust has no overhead from a "framework" - Rust programs start up quickly - The rust ecosystem makes it very easy to compile a command-line tool without lots of fluff - The strict nature of the language helps guide the programmer to write bug-free code. In short: There's a lot of good reasons to choose Rust that have little to do with the presence or absence of a garbage collector. I think having a working garbage collection at the application layer is very useful; even if it, at a minimum, makes Rust easier to learn. I do worry about 3rd party libraries using garbage collectors, because they (garbage collectors) tend to impose a lot of requirements, which is why a garbage collector usually is tightly integrated into the language.

jvanderbot 1y ago
You've just listed "Compiled language" features. Only the 4th point has any specificity to Rust, and even then, is vague in a way that could be misinterpreted. Rust's predominant feature, the one that brings most of its safety and runtime guarantees, is borrow checking. There are things I love about Rust besides that, but the safety from borrow checking (and everything the borrow checker makes me do) is why I like programming in rust. Now, when I program elsewhere, I'm constantly checking ownership "in my head", which I think is a good thing.
- zamalek 1y ago
  - Rust is a nice language to use
- gwbas1c 1y ago
  Oh no, I'm directly criticizing C/C++/Java/C#: The heavyweight framework (and startup cost) that comes with Java and C# makes them challenging for widely-adopted lightweight command-line tools. (Although I love C# as a language, I find the Rust toolchain much simpler and easier to work with than modern dotnet.) Building C (and C++) is often a nightmare.
  - ComputerGuru 1y ago
    New AOT C# is nice, but not fully doable with the most common dependencies. It addresses a lot of the old issues (size, bloat, startup latency, etc)
    - jiggawatts 1y ago
      Hilariously, the Microsoft SQL Client is the primary blocker for AOT for most potential usecases. Want fast startup for an Azure Function talking to Azure SQL Database? Hah… no. In all seriousness, that one dependency is the chain around the ankle of modern .NET because it’s not even fully async capable! It’s had critical performance regression bugs open for years. Microsoft’s best engineers are busy partying in the AI pool and forgot about drudgery like “make the basics components work”.
  - hypeatei 1y ago
    > The heavyweight framework Do you mean the VM/runtime? If so, you might be able to eliminate that with an AOT build. > I find the Rust toolchain much simpler and easier to work with than modern dotnet What part of the toolchain? I find them pretty similar with the only difference being the way you install them (with dotnet coming from a distro package and Rust from rustup)
    - jillesvangurp 1y ago
      Exactly, natively compiled garbage collected languages (like Java with Graal; or as executed on Android) don't have a lot of startup overhead. In Java the startup overhead is mostly two things that usually conspire to make things worse: 1) dynamic loading of jar files 2) reflection Number 1 allows you to load arbitrary jar files with code and execute them. Number 2 allows you to programmatically introspect existing code and then execute logic like "Find me all Foo sub classes and create an instance of those and return the list of those objects". You can do that at any time but a lot of that kind of stuff happens at startup. That involves parsing, loading and introspecting thousands of class files in jar files that need to be opened and decompressed. Most of "Java is slow" is basically programs loading a lot of stuff at startup, and then using reflection to look for code to execute. You don't have to do those things. But a lot of popular web frameworks like Spring do. A lot of that stuff is actually remarkably quick considering what it is doing. You'd struggle to do this in many other languages. Or at all because many languages don't have reflection. If you profile it, there are millions of calls happening in the first couple of seconds. It's taking time yes. But that code has also been heavily optimized over the years. Dismissing what that does as "java is slow" and X is fast is usually a bit of an apples and oranges discussion. With Spring Boot, there are dozens of libraries that self initialize if you simply add the dependency or the right configuration to your project. We can argue about whether that's nice or not; I'm leaning to no. But it's a neat feature. I'm more into lighter weight frameworks these days. Ktor server is pretty nice, for example. It starts pretty quickly because it doesn't do a whole lot on startup. Loading a tiny garbage collector library on startup isn't a big deal. It will add a few microseconds to your startup time maybe. Probably not milliseconds. Kotlin has a nice native compiler. If you compile hello world with it it's a few hundred kilobytes for a self contained binary with the program, runtime, and the garbage collection. It's not a great garbage collector. For memory intensive stuff you are better off using the JVM. But if that's not a concern, it will do the job.
- jrop 1y ago
  Just going to jump in here and say that there's another reason I might want Rust with a Garbage Collector: The language/type-system/LSP is really nice to work with. There have indeed been times that I really miss having enums + traits, but DON'T miss the borrow checker.
  - tuveson 1y ago
    Maybe try a different ML-influenced language like OCaml or Scala. The main innovation of Rust is bringing a nice ML-style type system to a more low level language.
    - Yoric 1y ago
      Jane Street apparently has a version of OCaml extended with affine types. I'd like to test that, because that would (almost) be the best of all worlds.
      - nobleach 1y ago
        I think you're referring to OxCaml. I'd love to see this make a huge splash. Right now one of the biggest shortcomings of OCaml, is one is still stuck implementing so much stuff from scratch. Languages like Rust, Go and Java have HUGE ecosystems. OCaml is just as old (even older than Rust since OCaml inspired Rust and its original compiler was written in OCaml) as these languages. Since it's not been as popular, it's hard to find well-supported libraries.
        debugnik 1y ago
        I too wish that some OxCaml features bring new blood to OCaml. I've been using OCaml for a few years for personal projects and I find the language really simple and powerful at the same time, but I had to implement me some foundational libraries (e.g. proper JSON, parser combinators), and now I'm considering porting one of those projects to Rust just so I can have unboxed types and better Windows support. > even older than Rust That's an understatement, (O)Caml is between 17 and 25 years older than Rust 0.1 depending on which Caml implementation you start counting from.
- tayo42 1y ago
  What other language has modern features like rust and is compiled?
  - procaryote 1y ago
    it depends completely on what you put in "modern features"
    - tayo42 1y ago
      Pattern matching, usable abstractions, non null types, tagged unions or w/e enums are, build tools etc
      - munificent 1y ago
        I'm not sure what you mean by "usable abstractions" and tagged unions are a little verbose because they are defined in terms of closed sets of subtypes, but otherwise Dart has all of those.
        tayo42 1y ago
        Nothing like "oh you can do that but with this weird work around" or if they're clunky to use
      - procaryote 1y ago
        This sounds more like "this is what I like in rust" than "features any modern language should have" though If you like rust, use rust. It's very likely the best rust
        lmm 1y ago
        > This sounds more like "this is what I like in rust" than "features any modern language should have" though Good build tooling has been around since 2004, and all of the rest of those features have been around since the late 1970s. There's really no excuse for a language not having all of them.
gizmo686 1y ago
Also, the proposed garbage collector is still opt in. Only pointers that are specifically marked as GC are garbage collected. This means that most references are still cleaned up automatically when the owner goes out of scope. This greatly reduces the cost of GC compared to making all heap allocations garbage collected. This isn't even a new concept in Rust. Rust already has a well accepted RC<T> type for reference counted pointers. From a usage perspective, GC<T> seems to fit in the same pattern.
- zigzag312 1y ago
  Language where most of the libraries are without GC, but has an GC opt in would be interesting. For example only your business logic code would use GC (so you can write it more quickly). And parts where you don't want GC are still written in the same language, avoiding the complexity of FFI. Add opt-in development compilation JIT for quick iteration and you don't need any other language. (Except for user scripts where needed.)
  - MaxBarraclough 1y ago
    The D programming language has an optional garbage collector. [0][1] With the @nogc attribute the compiler can check/enforce that your function doesn't depend on the GC. [2] [0] https://dlang.org/spec/garbage.html https://dlang.org/spec/garbage.html [1] https://news.ycombinator.com/item?id=33382159 https://news.ycombinator.com/item?id=33382159 [2] https://dlang.org/spec/function.html#nogc-functions https://dlang.org/spec/function.html#nogc-functions
- seivan 1y ago
  [dead]
yoyohello13 1y ago
I love the rust ecosystem, syntax, and type system. Being able to write Rust without worrying about ownership/lifetimes sounds great honestly.
rixed 1y ago
In all honesty, there are three topics I try to refrain myself from engaging with on HN, often unsuccesfully: politics, religion, and rust. I don't know what you had to go through before reaching rust's secure haven, but what you just said is true for the vast majority of compiled languages, which are legions.
- quotemstr 1y ago
  It's the fledging of a new generation of developers. Every time I see one of these threads I tell myself, "you, too, were once this ignorant and obnoxious". I don't know any cute except letting them get it out of their system and holding my nose as they do.
  - Ar-Curunir 1y ago
    Well you might find it good to learn that Rust is based on plenty of ideas dating back decades, so _your_ obnoxious and patronizing attitude is unwarranted.
    - quotemstr 1y ago
      Rust gets some things right and some things wrong. Its designers are generally clueful, but like all humans, fallible. But what does this discussion have to do with Rust exactly? Exactly the same considerations would apply to a C++ GC. The only thing more cringe than insisting on a GC strategy without understanding the landscape is to interpret everything as an attack on one's favored language.
- bregma 1y ago
  > politics, religion, and rust Is there a real distinction between any of those?
James_K 1y ago
Go is probably a better pick in this case.
- throwaway127482 1y ago
  With data intensive Go applications you eventually hit a point where your code has performance bottlenecks that you cannot fix without either requiring insane levels of knowledge on how Go works under the hood, or using CGo and incurring a high cost for each CGo call (last I heard it was something like 90ns), at which point you find yourself regretting you didn't write the program in Rust. If GC in Rust could be made ergonomic enough, I think it could be a better default choice than Go for writing a compiled app with high velocity. You could start off with an ergonomic GC style of Rust, then later drop into manual mode wherever you need performance.
- ViewTrick1002 1y ago
  Inviting in nil errors, data races and a near non-existent type system.
- bryanlarsen 1y ago
  It's possible to turn off GC for most of go and only use it where I want it? That's what this solution gives us for Rust.
victorbjorklund 1y ago
Also assuming one can mix garbage collection with the borrower (is that what its called in rust?) one should be able to use GC for things that arent called that much / that important and use the normal way for things that benefit from no GC interupts etc
imtringued 1y ago
The problem with conventional garbage collection has very little to do with the principle or algorithms behind garbage collection and more to do with the fact that seemingly every implementation has decided to only support a single heap. The moment you can have isolated heaps almost every single problem associated with garbage collection fades away. The only thing that remains is that cleaning up memory as late as possible is going to consume more memory than doing it as early as possible.
- tuveson 1y ago
  What problem does that solve with GC, specifically? It also seems like that creates an obvious new problem: If you have multiple heaps, how do you deal with an object in heap A pointing to an object in heap B? What about cyclic dependencies between the two? If you ban doing that, then you’re basically back to manual memory management.
  - paulddraper 1y ago
    There’s a ton of work that goes into multi-generational management, incremental vs stop the world, frequency heuristics, etc. A lot of the challenge is there is not just one universal answer for these, the optimum strategies vary case by case. You are correct that each memory arena is the boundary of the GC. Any GC between them must be handled manually.
- grogers 1y ago
  BEAM (i.e. erlang) is exactly that model, every lightweight process has its own heap. I don't see how you'd make that work in a more general environment that supports sharing pointers across threads.
fithisux 1y ago
I really like your work
jadenPete 1y ago
Rust's choice of constructs also makes writing safe and performant code easy. Many other compiled languages lack proper sum and product types, and traits (type classes) offer polymorphism without many of the pitfalls of inheritance, to name a few.
drnick1 1y ago
Aren't Rust programs still considerably larger than their C equivalent because everything is statically linked? It's kind of hard to see that as an advantage.
- paulddraper 1y ago
  No. They may be larger because they are doing more work, depends on the program. But no they don’t statically compile everything.
  - nsvd2 1y ago
    Static compilation and static linking are two separate things - however, Rust is both statically compiled and (usually) uses static linking of dependency libraries.
    - paulddraper 1y ago
      You’re right. I mean static linking. And by default Rust does not. Needs glibc.
- IshKebab 1y ago
  You can get Rust binaries pretty small: https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust But in practice it's more like there's an overhead for "hello world" but it's a fixed overhead. So it's really only a problem where you have lots of binaries, e.g. for coreutils. The solution there is a multi-call binary like Busybox that switches on argv[0]. C programs often seem small because you don't see the size of their dependencies directly, but they obviously still take up disk space. In some cases they can be shared but actually the amount of disk space this saves is not very big except for things like libc (which Rust dynamically links) and maybe big libraries like Qt, GTK, X11.
- nsvd2 1y ago
  Yes, all Rust libraries depended on are statically compiled into the final binary. One one hand, it makes binary size much larger, on the other, it makes it much easier to build an application that will "just work" without too much fuss. In my personal projects with Rust, this ends up being very nice because it makes packaging easier. However, I've never been in a situation where binary size matters like in the embedded space, for example. Rust isn't the only language with this approach, Go is another.

jvanderbot 1y ago

You've just listed "Compiled language" features. Only the 4th point has any specificity to Rust, and even then, is vague in a way that could be misinterpreted. Rust's predominant feature, the one that brings most of its safety and runtime guarantees, is borrow checking. There are things I love about Rust besides that, but the safety from borrow checking (and everything the borrow checker makes me do) is why I like programming in rust. Now, when I program elsewhere, I'm constantly checking ownership "in my head", which I think is a good thing.

zamalek 1y ago
- Rust is a nice language to use
gwbas1c 1y ago
Oh no, I'm directly criticizing C/C++/Java/C#: The heavyweight framework (and startup cost) that comes with Java and C# makes them challenging for widely-adopted lightweight command-line tools. (Although I love C# as a language, I find the Rust toolchain much simpler and easier to work with than modern dotnet.) Building C (and C++) is often a nightmare.
- ComputerGuru 1y ago
  New AOT C# is nice, but not fully doable with the most common dependencies. It addresses a lot of the old issues (size, bloat, startup latency, etc)
  - jiggawatts 1y ago
    Hilariously, the Microsoft SQL Client is the primary blocker for AOT for most potential usecases. Want fast startup for an Azure Function talking to Azure SQL Database? Hah… no. In all seriousness, that one dependency is the chain around the ankle of modern .NET because it’s not even fully async capable! It’s had critical performance regression bugs open for years. Microsoft’s best engineers are busy partying in the AI pool and forgot about drudgery like “make the basics components work”.
- hypeatei 1y ago
  > The heavyweight framework Do you mean the VM/runtime? If so, you might be able to eliminate that with an AOT build. > I find the Rust toolchain much simpler and easier to work with than modern dotnet What part of the toolchain? I find them pretty similar with the only difference being the way you install them (with dotnet coming from a distro package and Rust from rustup)
  - jillesvangurp 1y ago
    Exactly, natively compiled garbage collected languages (like Java with Graal; or as executed on Android) don't have a lot of startup overhead. In Java the startup overhead is mostly two things that usually conspire to make things worse: 1) dynamic loading of jar files 2) reflection Number 1 allows you to load arbitrary jar files with code and execute them. Number 2 allows you to programmatically introspect existing code and then execute logic like "Find me all Foo sub classes and create an instance of those and return the list of those objects". You can do that at any time but a lot of that kind of stuff happens at startup. That involves parsing, loading and introspecting thousands of class files in jar files that need to be opened and decompressed. Most of "Java is slow" is basically programs loading a lot of stuff at startup, and then using reflection to look for code to execute. You don't have to do those things. But a lot of popular web frameworks like Spring do. A lot of that stuff is actually remarkably quick considering what it is doing. You'd struggle to do this in many other languages. Or at all because many languages don't have reflection. If you profile it, there are millions of calls happening in the first couple of seconds. It's taking time yes. But that code has also been heavily optimized over the years. Dismissing what that does as "java is slow" and X is fast is usually a bit of an apples and oranges discussion. With Spring Boot, there are dozens of libraries that self initialize if you simply add the dependency or the right configuration to your project. We can argue about whether that's nice or not; I'm leaning to no. But it's a neat feature. I'm more into lighter weight frameworks these days. Ktor server is pretty nice, for example. It starts pretty quickly because it doesn't do a whole lot on startup. Loading a tiny garbage collector library on startup isn't a big deal. It will add a few microseconds to your startup time maybe. Probably not milliseconds. Kotlin has a nice native compiler. If you compile hello world with it it's a few hundred kilobytes for a self contained binary with the program, runtime, and the garbage collection. It's not a great garbage collector. For memory intensive stuff you are better off using the JVM. But if that's not a concern, it will do the job.
jrop 1y ago
Just going to jump in here and say that there's another reason I might want Rust with a Garbage Collector: The language/type-system/LSP is really nice to work with. There have indeed been times that I really miss having enums + traits, but DON'T miss the borrow checker.
- tuveson 1y ago
  Maybe try a different ML-influenced language like OCaml or Scala. The main innovation of Rust is bringing a nice ML-style type system to a more low level language.
  - Yoric 1y ago
    Jane Street apparently has a version of OCaml extended with affine types. I'd like to test that, because that would (almost) be the best of all worlds.
    - nobleach 1y ago
      I think you're referring to OxCaml. I'd love to see this make a huge splash. Right now one of the biggest shortcomings of OCaml, is one is still stuck implementing so much stuff from scratch. Languages like Rust, Go and Java have HUGE ecosystems. OCaml is just as old (even older than Rust since OCaml inspired Rust and its original compiler was written in OCaml) as these languages. Since it's not been as popular, it's hard to find well-supported libraries.
      - debugnik 1y ago
        I too wish that some OxCaml features bring new blood to OCaml. I've been using OCaml for a few years for personal projects and I find the language really simple and powerful at the same time, but I had to implement me some foundational libraries (e.g. proper JSON, parser combinators), and now I'm considering porting one of those projects to Rust just so I can have unboxed types and better Windows support. > even older than Rust That's an understatement, (O)Caml is between 17 and 25 years older than Rust 0.1 depending on which Caml implementation you start counting from.
tayo42 1y ago
What other language has modern features like rust and is compiled?
- procaryote 1y ago
  it depends completely on what you put in "modern features"
  - tayo42 1y ago
    Pattern matching, usable abstractions, non null types, tagged unions or w/e enums are, build tools etc
    - munificent 1y ago
      I'm not sure what you mean by "usable abstractions" and tagged unions are a little verbose because they are defined in terms of closed sets of subtypes, but otherwise Dart has all of those.
      - tayo42 1y ago
        Nothing like "oh you can do that but with this weird work around" or if they're clunky to use
    - procaryote 1y ago
      This sounds more like "this is what I like in rust" than "features any modern language should have" though If you like rust, use rust. It's very likely the best rust
      - lmm 1y ago
        > This sounds more like "this is what I like in rust" than "features any modern language should have" though Good build tooling has been around since 2004, and all of the rest of those features have been around since the late 1970s. There's really no excuse for a language not having all of them.

gizmo686 1y ago

Also, the proposed garbage collector is still opt in. Only pointers that are specifically marked as GC are garbage collected. This means that most references are still cleaned up automatically when the owner goes out of scope. This greatly reduces the cost of GC compared to making all heap allocations garbage collected. This isn't even a new concept in Rust. Rust already has a well accepted RC<T> type for reference counted pointers. From a usage perspective, GC<T> seems to fit in the same pattern.

zigzag312 1y ago
Language where most of the libraries are without GC, but has an GC opt in would be interesting. For example only your business logic code would use GC (so you can write it more quickly). And parts where you don't want GC are still written in the same language, avoiding the complexity of FFI. Add opt-in development compilation JIT for quick iteration and you don't need any other language. (Except for user scripts where needed.)
- MaxBarraclough 1y ago
  The D programming language has an optional garbage collector. [0][1] With the @nogc attribute the compiler can check/enforce that your function doesn't depend on the GC. [2] [0] https://dlang.org/spec/garbage.html https://dlang.org/spec/garbage.html [1] https://news.ycombinator.com/item?id=33382159 https://news.ycombinator.com/item?id=33382159 [2] https://dlang.org/spec/function.html#nogc-functions https://dlang.org/spec/function.html#nogc-functions
seivan 1y ago
[dead]

yoyohello13 1y ago

I love the rust ecosystem, syntax, and type system. Being able to write Rust without worrying about ownership/lifetimes sounds great honestly.

rixed 1y ago

In all honesty, there are three topics I try to refrain myself from engaging with on HN, often unsuccesfully: politics, religion, and rust. I don't know what you had to go through before reaching rust's secure haven, but what you just said is true for the vast majority of compiled languages, which are legions.

quotemstr 1y ago
It's the fledging of a new generation of developers. Every time I see one of these threads I tell myself, "you, too, were once this ignorant and obnoxious". I don't know any cute except letting them get it out of their system and holding my nose as they do.
- Ar-Curunir 1y ago
  Well you might find it good to learn that Rust is based on plenty of ideas dating back decades, so _your_ obnoxious and patronizing attitude is unwarranted.
  - quotemstr 1y ago
    Rust gets some things right and some things wrong. Its designers are generally clueful, but like all humans, fallible. But what does this discussion have to do with Rust exactly? Exactly the same considerations would apply to a C++ GC. The only thing more cringe than insisting on a GC strategy without understanding the landscape is to interpret everything as an attack on one's favored language.
bregma 1y ago
> politics, religion, and rust Is there a real distinction between any of those?

James_K 1y ago

Go is probably a better pick in this case.

throwaway127482 1y ago
With data intensive Go applications you eventually hit a point where your code has performance bottlenecks that you cannot fix without either requiring insane levels of knowledge on how Go works under the hood, or using CGo and incurring a high cost for each CGo call (last I heard it was something like 90ns), at which point you find yourself regretting you didn't write the program in Rust. If GC in Rust could be made ergonomic enough, I think it could be a better default choice than Go for writing a compiled app with high velocity. You could start off with an ergonomic GC style of Rust, then later drop into manual mode wherever you need performance.
ViewTrick1002 1y ago
Inviting in nil errors, data races and a near non-existent type system.
bryanlarsen 1y ago
It's possible to turn off GC for most of go and only use it where I want it? That's what this solution gives us for Rust.

victorbjorklund 1y ago

Also assuming one can mix garbage collection with the borrower (is that what its called in rust?) one should be able to use GC for things that arent called that much / that important and use the normal way for things that benefit from no GC interupts etc

imtringued 1y ago

The problem with conventional garbage collection has very little to do with the principle or algorithms behind garbage collection and more to do with the fact that seemingly every implementation has decided to only support a single heap. The moment you can have isolated heaps almost every single problem associated with garbage collection fades away. The only thing that remains is that cleaning up memory as late as possible is going to consume more memory than doing it as early as possible.

tuveson 1y ago
What problem does that solve with GC, specifically? It also seems like that creates an obvious new problem: If you have multiple heaps, how do you deal with an object in heap A pointing to an object in heap B? What about cyclic dependencies between the two? If you ban doing that, then you’re basically back to manual memory management.
- paulddraper 1y ago
  There’s a ton of work that goes into multi-generational management, incremental vs stop the world, frequency heuristics, etc. A lot of the challenge is there is not just one universal answer for these, the optimum strategies vary case by case. You are correct that each memory arena is the boundary of the GC. Any GC between them must be handled manually.
grogers 1y ago
BEAM (i.e. erlang) is exactly that model, every lightweight process has its own heap. I don't see how you'd make that work in a more general environment that supports sharing pointers across threads.

fithisux 1y ago

I really like your work

jadenPete 1y ago

Rust's choice of constructs also makes writing safe and performant code easy. Many other compiled languages lack proper sum and product types, and traits (type classes) offer polymorphism without many of the pitfalls of inheritance, to name a few.

drnick1 1y ago

Aren't Rust programs still considerably larger than their C equivalent because everything is statically linked? It's kind of hard to see that as an advantage.

paulddraper 1y ago
No. They may be larger because they are doing more work, depends on the program. But no they don’t statically compile everything.
- nsvd2 1y ago
  Static compilation and static linking are two separate things - however, Rust is both statically compiled and (usually) uses static linking of dependency libraries.
  - paulddraper 1y ago
    You’re right. I mean static linking. And by default Rust does not. Needs glibc.
IshKebab 1y ago
You can get Rust binaries pretty small: https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust But in practice it's more like there's an overhead for "hello world" but it's a fixed overhead. So it's really only a problem where you have lots of binaries, e.g. for coreutils. The solution there is a multi-call binary like Busybox that switches on argv[0]. C programs often seem small because you don't see the size of their dependencies directly, but they obviously still take up disk space. In some cases they can be shared but actually the amount of disk space this saves is not very big except for things like libc (which Rust dynamically links) and maybe big libraries like Qt, GTK, X11.
nsvd2 1y ago
Yes, all Rust libraries depended on are statically compiled into the final binary. One one hand, it makes binary size much larger, on the other, it makes it much easier to build an application that will "just work" without too much fuss. In my personal projects with Rust, this ends up being very nice because it makes packaging easier. However, I've never been in a situation where binary size matters like in the embedded space, for example. Rust isn't the only language with this approach, Go is another.