19 ms·

"Rust does not have a stable ABI"

163 points by caution 6y ago

seanhunter 6y ago
Not an expert, but if you want a stable Rust-to-non-rust ABI, you can use the C ABI as the article mentions. If you want a stable rust-to-rust ABI for FFI there's a crate for that https://crates.io/crates/abi_stable https://crates.io/crates/abi_stable It seems somewhat unrealistic to expect a really new language commit across the board to the same sort of ABI stablility as a decades-old language such as C.
choeger 6y ago
It might simply be the time to invent a more modern ABI. If for some reason modern languages insist on monomorphization, we should be able to design an ABI that suits that need. Rough sketch: A modern shared library is code that generates code (very much like a dynamic linker is actually code that links code). The interface of the library would consist of: a) a description language for the shape of data types (not types themselves, mind you) b) a list of generators for functions c) a list of function applied to shapes as a requirement The job of the modern dynamic linker would then be to invoke all the functions to the necessary shapes, put the resulting code into memory and link it. It might be useful to support this with some kind of caching mechanism.
PudgePacket 6y ago
Off-topic but it seems the quotes around the title don't render on the front page, but they do render on this page? It flips the entire tone of this article. Initially on reading the title I just eye-rolled, but clicking through and seeing it was a response to that, and was actually the quote in quote marks made much more sense!!
- ccmcarey 6y ago
  I see it on both HN homepage and this page.
- cube00 6y ago
  I see quotes on both pages on Firefox 79 on Windows
  - _Microft 6y ago
    The submitter might have edited the title. HN fixes a number of things in titles on submission but allows to undo these automatic changes manually.
deleted 6y ago
[deleted]
georgyo 6y ago
The optimized and stripped library in rust was about 8 times the size of the C version. While 9MB is not a lot by itself, if a significant portion of libraries decide they want to switch to rust that would explode disk usage! Though I think my problem with rust is that they make breaking changes in their compiler and spec every release. People regularly building on rust unstable to get features not yet released. This all makes things complicated for a distro. But the points at about making breaking changes at the bottom resonated with me. Stability is what has allowed the Linux ecosystem to grow so well. Many interconnected parts all moving in unison. Not being able to fix a bad design decision because of this does suck. Still, having everything work and sadly is more important than perfect design.
- viraptor 6y ago
  > Though I think my problem with rust is that they make breaking changes in their compiler and spec every release. Can you bring specific examples? The stable version is not only actually stable, but when big changes happen you can also opt into previous edition's behaviour with one config line. Breaking spec every release really doesn't sound right. As for unstable - distros could find that complicated, but distros don't have to ship unstable things, so that doesn't sound like a big problem.
  - fluffy87 6y ago
    I guess they mean ABI breaking changes, like enum Lay-out optimizations, etc. (not “language feature” breaking changes).
    - viraptor 6y ago
      By changes in the compiler I could kind of understand it like that... but changes in spec?
- the_duke 6y ago
  > Though I think my problem with rust is that they make breaking changes in their compiler and spec every release That's not accurate. Rust is backwards compatible. Most 1.0 code would still compile perfectly fine today. There have been some minor breaking changes for soundness reasons, if I remember correctly. There also has been one edition upgrade (2018 edition), but every new compiler still supports the old edition, and most new stuff actually works in the old edition as well. There are experimental features, which are only available on the nightly compiler and have to be opted in to with a "#[feature(X)]" attribute. But those are very clearly labelled as experimental, unstable, and evolving, with no stability guarantees whatsoever. The criticism I would share is that while Rust is backwards compatible, it is obviously not forwards compatible. Rust evolved dramatically since 1.0, and many developers jump on new features once available. So compiling actively maintained projects with a older compiler in distros like Debian is not fun. But the rate of change has slowed down a lot over the past year or so.
zaro 6y ago
With everything slowly( or sometimes rapidly) moving into containers (docker, systemd portable services, flatpak, snaps) I think the concept of system library will probably become irrelevant at some point not that far into the future.
- ex_amazon_sde 6y ago
  This would make it impossible to achieve the most basic level of security.
- zozbot234 6y ago
  Containers (and containerish systems like flatpak) still have portable dependencies that are equivalent to "system" libraries in this context.
- arp242 6y ago
  I don't think we're anywhere near a future where "ls" will be run in a container.
  - krageon 6y ago
    I used to think that we're not anywhere near a future where most applications came bundled with an entire browser, yet here we are.
- gspr 6y ago
  How does it matter whether a library is a "system" one or not?
  - jononor 6y ago
    The expectation is that with a "system" package, one can update that one package and (basically) everything on the system now uses that new version. Practical for security and important bugfixes.
- wirrbel 6y ago
  It's still a system library just a system stuffed into a container.
fluffy87 6y ago
Two issues with the post: - An ABI is not a PL feature, but a platform feature, I.e., it is not that Rust does not have a stable ABI, but that eg Linux does not have a stable ABI for Rust (it has one for C and you can use this ABI from Rust). - You can export generic Rust APIs with a stable C ABI by using trait objects, and it is often very easy to do this. So the claim that Rust and C++ are on the same boat wrt generics / instantiations is not true.
- moonchild 6y ago
  > An ABI is not a PL feature, but a platform feature, I.e., it is not that Rust does not have a stable ABI, but that eg Linux does not have a stable ABI for Rust (it has one for C and you can use this ABI from Rust). This is somewhat of a disingenuous thing to say, because it implies that the fault lies with linux for not providing a stable abi to rust. An ABI comprises various conventions wrt calling convention, name mangling, data layout, etc.; these are provided variably by the operating system, language specification, and language compiler. And, as TFA mentions, the rust compiler explicitly does not provide a stable ABI.
  - pjmlp 6y ago
    Windows does provide two cross language stable ABIs, CLR CLS and COM/UWP. Mainframes also provide cross language stable ABIs, so called language environments.
  - fluffy87 6y ago
    I don’t agree. The C ABI is specified in a spec that Linux adopts (eg the x86-psabi), and it is what allows all software using this abi (from assembly to C to Rust) to eg Interface with each other. Linux could write an ABI spec for Rust on its platform today and add a patch to the Rust compiler (or to a C++ comoiler) to adhere to this ABI. Nobody has done this, and from many povs this is something that does not make much sense doing, but it’s up to the platform to specify how binary software communicates with each other. Linux only specifies this for C, and that’s what Rust software currently does and has to use on Linux.
phh 6y ago
The article is pretty interesting and I learned quite a few things, but it looks like the author is knowingly not answering the issue they raise by themselves. In my opinion, the most important thing distros does that is incompatible with how rust currently works, is handling security/bug updates. The one libjpeg.so for everyone is meant to fix libjpeg flaws for everyone. And it has many security flaws. And it has many users. There is no denying the way this is done by distros is good. Now, to pick author's code, one of its dependency is a CSS parsing, which is prone to flaws. (Maybe not /security/ flaws, but still) The question is, how is the distro supposed to handle that? I know rust has tooling for that, but it seems to me that with the perfect version match crate build system, every dependency will happily break API. So let's say author no longer has time to develop rust librsvg, and cssparser crate has a major flaw, which is fixed only in a new API rewrite branch, then what? Distro are supposed to fix that themselves? Sounds like much more work for them.
- nicoburns 6y ago
  From a security point of view, you shouldn't be using unmaintained libraries anyway, no? And if librsvg is maintained, then all the distro has to do is package the latest version.
- Cogitri 6y ago
  Yes, every crate using a different versions of their dependencies involves a lot more work for distros, especially when a crate uses a -sys crate (e.g. libgit2-sys) and libgit2-sys does an API break. Now every crate that uses libgit2-sys in the repo manually needs its dependencies updated, which is a rather time consuming process (especially if the bindings in libgit2-sys are only built against some random git version).
- deleted 6y ago
  [deleted]
- posix_me_less 6y ago
  > There is no denying the way this is done by distros is good. Let me tell you, the way it is done by distros (Centos, Debian) is far from being good. You will get the fix a long time after the bug is published. And you only get it if your system is recent enough.
dthul 6y ago
I didn't know that it was possible to export Rust enums with a C ABI like that, that's nifty!
young_unixer 6y ago
This whole ideology of "the user should get all their software from their Linux distribution" and it's implicit consequence: there's no clear difference between system software (internal tooling) and application software installed by the user (Audacity and friends) should just die already. I want my OS to just provide a decent interface over which I can install application packages myself, packages that I get from my own sources, just like on Windows. if those packages are statically linked, fine. I know most Linux users disagree, but I don't want the relationship between software vendor and user to be distorted by some distro maintainer, or having to be limited to a package manager. I want to be able to store application installers in my filesystem. I also want my distribution to hide it's Python binary from me so I can install my own Python without breaking the OS. Basically: stop assuming that I want to live under your wing. I just want you to give me a nice desktop environment, a terminal and a well docomented way to install third party software. I know distro developers don't owe me anything, and it's fine if they do something else, but this is the actual reason why Linux isn't used in the desktop.
- fuzzy2 6y ago
  …? You can have all of this today. > this is the actual reason why Linux isn't used in the desktop. Yeah, no.
  - ironmagma 6y ago
    Just curious, what do you think the actual reason is?
    - deleted 6y ago
      [deleted]
    - fuzzy2 6y ago
      Hm, hard to find “the one reason”. I think the most important factors are: * What people (not necessarily the users but corporate decision-makers) are used to (Windows) * Enterprise manageability (achievable on Linux, but built-in on Windows) * What is preinstalled (Windows) * What some exotic business applications work with (Windows) Almost purely soft factors, very hard to counter if virtually all the computers you can buy at your local PC shop come with Windows preinstalled. My neighbors (70+) accidentally got hold of a laptop that didn’t come with Windows but Ubuntu and they’re perfectly fine with it. It still has Firefox after all. :-)
jokoon 6y ago
Wouldn't it be possible to have a C-like language that is somewhat backward compatible with C, and have the nice security features of Rust? I get that Rust is awesome, but I'm not certain you need to make an entire new language just to have the security stuff. Of course it might be complicated to do, but in the end, aren't there linters or other validators that can give the same security results rust has, but with C or even C++?
- jdub 6y ago
  1. You could possibly get closer, but you'd lose a lot. Most of Rust's "nice security features" are wildly incompatible with existing C/C++ code and inherent language features. 2. No. If C/C++ could be made safe* Rust would not exist. * everyone agrees on this point, including the richest and largest software companies on the planet
  - dependenttypes 6y ago
    > Most of Rust's "nice security features" are wildly incompatible with existing C/C++ code and inherent language features Such as?
    - fhars 6y ago
      Lifetimes and the borrow checker.
      - dependenttypes 6y ago
        A linter can do that.
        smolder 6y ago
        Nope.
        dependenttypes 6y ago
temac 6y ago
"Why do distros expect all the living organisms on your machine to share The World's Single Lungs Service, and The World's Single Stomach Service, and The World's Single Liver Service?" This has been debated for years, and parts of the answers is right above. Also, software is not a collection of biological organisms. And the local variables are not shared, so WTF anyway. The analogy makes no sense. Everybody is already neatly separated. Proponent of everything static have yet to show non toy / very specialized systems where everything is actually static. Let's avoid the strawman anyway and in this case, yes, some static linking can have its use, especially for some small utility / metaprog / etc. packages, although it has and will always have drawbacks to, especially for higher level feature support (e.g. a codec). You have to go into the specifics to understand which are more important depending on the context. Probably a mix is needed. For a Linux distro, I suspect some people will go crazy if the fix for a security vuln of a small piece of code ends up downloading hundreds of MB, but maybe there are advantages so great that this is something we can live with. The net perf impact is extremely hard to predict and measure. You will duplicate tons of code, but arguably e.g. the cache overhead might not be extremely bad, we now have tons of memory, so maybe we can waste some, etc. Note however that if a Linux distro is competing with other kind of plateforms, there is the risk to put the Linux distro at a disadvantage if the static vs. dynamic (maybe on a package per package basis) is chosen improperly, because other platforms make the distinction between platform and application, their platform typically provides a very large API, and they won't go the insane way and switch to static. The lack of proper dynamic linkage story for Rust is a problem that needs to be fixed to enable some kind of usages. Not something that can always be worked-around (sometimes it can, and for some crate you really want static to begin with anyway)
- rollcat 6y ago
  > For a Linux distro, I suspect some people will go crazy if the fix for a security vuln of a small piece of code ends up downloading hundreds of MB [...]. I always wondered about this problem; you could distribute the .o/.a's the same way you currently distribute the .so's, and integrate the linker with the package manager. This theoretically seems to share most of the benefits of both static and dynamic linking: push complexity away from the kernel/dynamic loader, smaller updates = easier patching (compared to fully static binaries), etc. And it works for closed source. OpenBSD does something similar already for libc and kernel (for boot-time address layout randomisation) and it works great.
Ijumfs 6y ago
Why are people even using Rust and Go, aside from employer say-so? They're not formally defined, there aren't multiple functioning implementations, it's just not a good idea.
- nullifidian 6y ago
  There are formally defined Rust subsets (see Rustbelt).
- sanxiyn 6y ago
  Go has a supported alternative implementation, gccgo.
jpm_sd 6y ago
This is a bunch of nonsense. Rust prefers static linking because it is predictable. These supposedly "huge" binaries are laughably small on a modern >1TB hard drive. If you're building a tiny embedded system, by all means optimize your builds system-wide, you have total control! But for a desktop, is this really a concern?
- Jasper_ 6y ago
  I seem to keep running out of space on my relatively small SSD where my OS is installed, so, yeah, it totally is a concern.
  - qppo 6y ago
    Buy a bigger ssd if you can, they're cheap. The last drive I bought was a 1TB Intel SSD for like $90. But the pain point is on laptops like MacBooks which have comically small storage space for their price point. I think the base models have a measly 256GB SSD and charge crazy amounts for upgrades.
  - AnIdiotOnTheNet 6y ago
    If applications were portable, then just put them on a different disk. This isn't rocket science, we've been doing it since the 80s. Problem is that portable applications are an alien concept to Linux.
    - heavyset_go 6y ago
      > Problem is that portable applications are an alien concept to Linux. Static builds, AppImage, FlatPak, containers, etc would like to have a word with you.
- dTal 6y ago
  Yes, it's a concern. Firstly, hard drive space isn't the only reason to make binaries small - you have RAM pressure, cache pressure, and bandwidth to save. Secondly and more importantly, waste adds up. If you replaced every binary on the system with a Rust equivalent - which, to listen to some advocates, is the eventual goal - you could end up with a base system that's many times larger. In a larger sense, something that sets out to be a "systems programming language" needs to be exactly the sort of thing suitable for a tiny embedded system, even if it isn't running on one, because everything else builds on top of it. The attitude that "we have tons of power, why not waste it" just doesn't fly at the very lowest levels. You can write a desktop application in Python, and it's broadly fine - but try writing an OS kernel!
tannernelson 6y ago
I really don’t see the problem with just statically linking everything.
ckok 6y ago
In a way I'm happy rust does not have a stable abi. Swift does, but the stability is 'whatever apple swift emit'. Very little documentation, that what's there is out of date, so the only practical language that can interact with swift is swift. To be able to interact from another language, one would have to parse swift, make the semantics of all types and generics match exactly to be able to do the simplest things. (For example array and string, two core types are stock full of generics and protocols) I'd hate to have the same happening for rust.
amluto 6y ago
> While C++ had the problem of "lots of template code in header files", Rust has the problem that monomorphization of generics creates a lot of compiled code. There are tricks to avoid this and they are all the decision of the library/crate author. Is there any research on having compilers do some of these tricks automatically? A compiler should, at least in principle, be able to tell what aspects of a type parameter are used in a given piece of code. Such a compiler could plausibly produce code that is partially or fully type-erased automatically without losing efficiency. In some cases, I would believe that code size, runtime performance (due to improved cache behavior), and compile times would all improve.
- sanxiyn 6y ago
  Implementing type erasure for Rust compiler is a research problem. In principle it ought to be possible, but I am not aware of any prior work.
mixmastamyk 6y ago
There's a lot of either/or false dichotomy being discussed in here. Distro packaging (or not) comes with various tradeoffs of course, some good or bad depending on perspective. To get to the point, I quite prefer the package manager way of installing software to "hunt down a single release" app installers of Windows/Mac. The only issue is that sometimes software is a bit out of date. That's what the snap/flat pack/appimage projects are trying to solve. As soon as one of those three get their user-hostile issues fixed, it will be a software paradise. :D

163 points by caution 6y ago

Not an expert, but if you want a stable Rust-to-non-rust ABI, you can use the C ABI as the article mentions. If you want a stable rust-to-rust ABI for FFI there's a crate for that https://crates.io/crates/abi_stable https://crates.io/crates/abi_stable It seems somewhat unrealistic to expect a really new language commit across the board to the same sort of ABI stablility as a decades-old language such as C.

choeger 6y ago

It might simply be the time to invent a more modern ABI. If for some reason modern languages insist on monomorphization, we should be able to design an ABI that suits that need. Rough sketch: A modern shared library is code that generates code (very much like a dynamic linker is actually code that links code). The interface of the library would consist of: a) a description language for the shape of data types (not types themselves, mind you) b) a list of generators for functions c) a list of function applied to shapes as a requirement The job of the modern dynamic linker would then be to invoke all the functions to the necessary shapes, put the resulting code into memory and link it. It might be useful to support this with some kind of caching mechanism.

PudgePacket 6y ago

Off-topic but it seems the quotes around the title don't render on the front page, but they do render on this page? It flips the entire tone of this article. Initially on reading the title I just eye-rolled, but clicking through and seeing it was a response to that, and was actually the quote in quote marks made much more sense!!

ccmcarey 6y ago
I see it on both HN homepage and this page.
cube00 6y ago
I see quotes on both pages on Firefox 79 on Windows
- _Microft 6y ago
  The submitter might have edited the title. HN fixes a number of things in titles on submission but allows to undo these automatic changes manually.

deleted 6y ago

[deleted]

georgyo 6y ago

The optimized and stripped library in rust was about 8 times the size of the C version. While 9MB is not a lot by itself, if a significant portion of libraries decide they want to switch to rust that would explode disk usage! Though I think my problem with rust is that they make breaking changes in their compiler and spec every release. People regularly building on rust unstable to get features not yet released. This all makes things complicated for a distro. But the points at about making breaking changes at the bottom resonated with me. Stability is what has allowed the Linux ecosystem to grow so well. Many interconnected parts all moving in unison. Not being able to fix a bad design decision because of this does suck. Still, having everything work and sadly is more important than perfect design.

viraptor 6y ago
> Though I think my problem with rust is that they make breaking changes in their compiler and spec every release. Can you bring specific examples? The stable version is not only actually stable, but when big changes happen you can also opt into previous edition's behaviour with one config line. Breaking spec every release really doesn't sound right. As for unstable - distros could find that complicated, but distros don't have to ship unstable things, so that doesn't sound like a big problem.
- fluffy87 6y ago
  I guess they mean ABI breaking changes, like enum Lay-out optimizations, etc. (not “language feature” breaking changes).
  - viraptor 6y ago
    By changes in the compiler I could kind of understand it like that... but changes in spec?
the_duke 6y ago
> Though I think my problem with rust is that they make breaking changes in their compiler and spec every release That's not accurate. Rust is backwards compatible. Most 1.0 code would still compile perfectly fine today. There have been some minor breaking changes for soundness reasons, if I remember correctly. There also has been one edition upgrade (2018 edition), but every new compiler still supports the old edition, and most new stuff actually works in the old edition as well. There are experimental features, which are only available on the nightly compiler and have to be opted in to with a "#[feature(X)]" attribute. But those are very clearly labelled as experimental, unstable, and evolving, with no stability guarantees whatsoever. The criticism I would share is that while Rust is backwards compatible, it is obviously not forwards compatible. Rust evolved dramatically since 1.0, and many developers jump on new features once available. So compiling actively maintained projects with a older compiler in distros like Debian is not fun. But the rate of change has slowed down a lot over the past year or so.

zaro 6y ago

With everything slowly( or sometimes rapidly) moving into containers (docker, systemd portable services, flatpak, snaps) I think the concept of system library will probably become irrelevant at some point not that far into the future.

ex_amazon_sde 6y ago
This would make it impossible to achieve the most basic level of security.
zozbot234 6y ago
Containers (and containerish systems like flatpak) still have portable dependencies that are equivalent to "system" libraries in this context.
arp242 6y ago
I don't think we're anywhere near a future where "ls" will be run in a container.
- krageon 6y ago
  I used to think that we're not anywhere near a future where most applications came bundled with an entire browser, yet here we are.
gspr 6y ago
How does it matter whether a library is a "system" one or not?
- jononor 6y ago
  The expectation is that with a "system" package, one can update that one package and (basically) everything on the system now uses that new version. Practical for security and important bugfixes.
wirrbel 6y ago
It's still a system library just a system stuffed into a container.

fluffy87 6y ago

Two issues with the post: - An ABI is not a PL feature, but a platform feature, I.e., it is not that Rust does not have a stable ABI, but that eg Linux does not have a stable ABI for Rust (it has one for C and you can use this ABI from Rust). - You can export generic Rust APIs with a stable C ABI by using trait objects, and it is often very easy to do this. So the claim that Rust and C++ are on the same boat wrt generics / instantiations is not true.

moonchild 6y ago
> An ABI is not a PL feature, but a platform feature, I.e., it is not that Rust does not have a stable ABI, but that eg Linux does not have a stable ABI for Rust (it has one for C and you can use this ABI from Rust). This is somewhat of a disingenuous thing to say, because it implies that the fault lies with linux for not providing a stable abi to rust. An ABI comprises various conventions wrt calling convention, name mangling, data layout, etc.; these are provided variably by the operating system, language specification, and language compiler. And, as TFA mentions, the rust compiler explicitly does not provide a stable ABI.
- pjmlp 6y ago
  Windows does provide two cross language stable ABIs, CLR CLS and COM/UWP. Mainframes also provide cross language stable ABIs, so called language environments.
- fluffy87 6y ago
  I don’t agree. The C ABI is specified in a spec that Linux adopts (eg the x86-psabi), and it is what allows all software using this abi (from assembly to C to Rust) to eg Interface with each other. Linux could write an ABI spec for Rust on its platform today and add a patch to the Rust compiler (or to a C++ comoiler) to adhere to this ABI. Nobody has done this, and from many povs this is something that does not make much sense doing, but it’s up to the platform to specify how binary software communicates with each other. Linux only specifies this for C, and that’s what Rust software currently does and has to use on Linux.

phh 6y ago

The article is pretty interesting and I learned quite a few things, but it looks like the author is knowingly not answering the issue they raise by themselves. In my opinion, the most important thing distros does that is incompatible with how rust currently works, is handling security/bug updates. The one libjpeg.so for everyone is meant to fix libjpeg flaws for everyone. And it has many security flaws. And it has many users. There is no denying the way this is done by distros is good. Now, to pick author's code, one of its dependency is a CSS parsing, which is prone to flaws. (Maybe not /security/ flaws, but still) The question is, how is the distro supposed to handle that? I know rust has tooling for that, but it seems to me that with the perfect version match crate build system, every dependency will happily break API. So let's say author no longer has time to develop rust librsvg, and cssparser crate has a major flaw, which is fixed only in a new API rewrite branch, then what? Distro are supposed to fix that themselves? Sounds like much more work for them.

nicoburns 6y ago
From a security point of view, you shouldn't be using unmaintained libraries anyway, no? And if librsvg is maintained, then all the distro has to do is package the latest version.
Cogitri 6y ago
Yes, every crate using a different versions of their dependencies involves a lot more work for distros, especially when a crate uses a -sys crate (e.g. libgit2-sys) and libgit2-sys does an API break. Now every crate that uses libgit2-sys in the repo manually needs its dependencies updated, which is a rather time consuming process (especially if the bindings in libgit2-sys are only built against some random git version).
deleted 6y ago
[deleted]
posix_me_less 6y ago
> There is no denying the way this is done by distros is good. Let me tell you, the way it is done by distros (Centos, Debian) is far from being good. You will get the fix a long time after the bug is published. And you only get it if your system is recent enough.

dthul 6y ago

I didn't know that it was possible to export Rust enums with a C ABI like that, that's nifty!

young_unixer 6y ago

This whole ideology of "the user should get all their software from their Linux distribution" and it's implicit consequence: there's no clear difference between system software (internal tooling) and application software installed by the user (Audacity and friends) should just die already. I want my OS to just provide a decent interface over which I can install application packages myself, packages that I get from my own sources, just like on Windows. if those packages are statically linked, fine. I know most Linux users disagree, but I don't want the relationship between software vendor and user to be distorted by some distro maintainer, or having to be limited to a package manager. I want to be able to store application installers in my filesystem. I also want my distribution to hide it's Python binary from me so I can install my own Python without breaking the OS. Basically: stop assuming that I want to live under your wing. I just want you to give me a nice desktop environment, a terminal and a well docomented way to install third party software. I know distro developers don't owe me anything, and it's fine if they do something else, but this is the actual reason why Linux isn't used in the desktop.

fuzzy2 6y ago
…? You can have all of this today. > this is the actual reason why Linux isn't used in the desktop. Yeah, no.
- ironmagma 6y ago
  Just curious, what do you think the actual reason is?
  - deleted 6y ago
    [deleted]
  - fuzzy2 6y ago
    Hm, hard to find “the one reason”. I think the most important factors are: * What people (not necessarily the users but corporate decision-makers) are used to (Windows) * Enterprise manageability (achievable on Linux, but built-in on Windows) * What is preinstalled (Windows) * What some exotic business applications work with (Windows) Almost purely soft factors, very hard to counter if virtually all the computers you can buy at your local PC shop come with Windows preinstalled. My neighbors (70+) accidentally got hold of a laptop that didn’t come with Windows but Ubuntu and they’re perfectly fine with it. It still has Firefox after all. :-)

jokoon 6y ago

Wouldn't it be possible to have a C-like language that is somewhat backward compatible with C, and have the nice security features of Rust? I get that Rust is awesome, but I'm not certain you need to make an entire new language just to have the security stuff. Of course it might be complicated to do, but in the end, aren't there linters or other validators that can give the same security results rust has, but with C or even C++?

jdub 6y ago
1. You could possibly get closer, but you'd lose a lot. Most of Rust's "nice security features" are wildly incompatible with existing C/C++ code and inherent language features. 2. No. If C/C++ could be made safe* Rust would not exist. * everyone agrees on this point, including the richest and largest software companies on the planet
- dependenttypes 6y ago
  > Most of Rust's "nice security features" are wildly incompatible with existing C/C++ code and inherent language features Such as?
  - fhars 6y ago
    Lifetimes and the borrow checker.
    - dependenttypes 6y ago
      A linter can do that.
      - smolder 6y ago
        Nope.
        dependenttypes 6y ago

temac 6y ago

"Why do distros expect all the living organisms on your machine to share The World's Single Lungs Service, and The World's Single Stomach Service, and The World's Single Liver Service?" This has been debated for years, and parts of the answers is right above. Also, software is not a collection of biological organisms. And the local variables are not shared, so WTF anyway. The analogy makes no sense. Everybody is already neatly separated. Proponent of everything static have yet to show non toy / very specialized systems where everything is actually static. Let's avoid the strawman anyway and in this case, yes, some static linking can have its use, especially for some small utility / metaprog / etc. packages, although it has and will always have drawbacks to, especially for higher level feature support (e.g. a codec). You have to go into the specifics to understand which are more important depending on the context. Probably a mix is needed. For a Linux distro, I suspect some people will go crazy if the fix for a security vuln of a small piece of code ends up downloading hundreds of MB, but maybe there are advantages so great that this is something we can live with. The net perf impact is extremely hard to predict and measure. You will duplicate tons of code, but arguably e.g. the cache overhead might not be extremely bad, we now have tons of memory, so maybe we can waste some, etc. Note however that if a Linux distro is competing with other kind of plateforms, there is the risk to put the Linux distro at a disadvantage if the static vs. dynamic (maybe on a package per package basis) is chosen improperly, because other platforms make the distinction between platform and application, their platform typically provides a very large API, and they won't go the insane way and switch to static. The lack of proper dynamic linkage story for Rust is a problem that needs to be fixed to enable some kind of usages. Not something that can always be worked-around (sometimes it can, and for some crate you really want static to begin with anyway)

rollcat 6y ago
> For a Linux distro, I suspect some people will go crazy if the fix for a security vuln of a small piece of code ends up downloading hundreds of MB [...]. I always wondered about this problem; you could distribute the .o/.a's the same way you currently distribute the .so's, and integrate the linker with the package manager. This theoretically seems to share most of the benefits of both static and dynamic linking: push complexity away from the kernel/dynamic loader, smaller updates = easier patching (compared to fully static binaries), etc. And it works for closed source. OpenBSD does something similar already for libc and kernel (for boot-time address layout randomisation) and it works great.

Ijumfs 6y ago

Why are people even using Rust and Go, aside from employer say-so? They're not formally defined, there aren't multiple functioning implementations, it's just not a good idea.

nullifidian 6y ago
There are formally defined Rust subsets (see Rustbelt).
sanxiyn 6y ago
Go has a supported alternative implementation, gccgo.

jpm_sd 6y ago

This is a bunch of nonsense. Rust prefers static linking because it is predictable. These supposedly "huge" binaries are laughably small on a modern >1TB hard drive. If you're building a tiny embedded system, by all means optimize your builds system-wide, you have total control! But for a desktop, is this really a concern?

Jasper_ 6y ago
I seem to keep running out of space on my relatively small SSD where my OS is installed, so, yeah, it totally is a concern.
- qppo 6y ago
  Buy a bigger ssd if you can, they're cheap. The last drive I bought was a 1TB Intel SSD for like $90. But the pain point is on laptops like MacBooks which have comically small storage space for their price point. I think the base models have a measly 256GB SSD and charge crazy amounts for upgrades.
- AnIdiotOnTheNet 6y ago
  If applications were portable, then just put them on a different disk. This isn't rocket science, we've been doing it since the 80s. Problem is that portable applications are an alien concept to Linux.
  - heavyset_go 6y ago
    > Problem is that portable applications are an alien concept to Linux. Static builds, AppImage, FlatPak, containers, etc would like to have a word with you.
dTal 6y ago
Yes, it's a concern. Firstly, hard drive space isn't the only reason to make binaries small - you have RAM pressure, cache pressure, and bandwidth to save. Secondly and more importantly, waste adds up. If you replaced every binary on the system with a Rust equivalent - which, to listen to some advocates, is the eventual goal - you could end up with a base system that's many times larger. In a larger sense, something that sets out to be a "systems programming language" needs to be exactly the sort of thing suitable for a tiny embedded system, even if it isn't running on one, because everything else builds on top of it. The attitude that "we have tons of power, why not waste it" just doesn't fly at the very lowest levels. You can write a desktop application in Python, and it's broadly fine - but try writing an OS kernel!

tannernelson 6y ago

I really don’t see the problem with just statically linking everything.

ckok 6y ago

In a way I'm happy rust does not have a stable abi. Swift does, but the stability is 'whatever apple swift emit'. Very little documentation, that what's there is out of date, so the only practical language that can interact with swift is swift. To be able to interact from another language, one would have to parse swift, make the semantics of all types and generics match exactly to be able to do the simplest things. (For example array and string, two core types are stock full of generics and protocols) I'd hate to have the same happening for rust.

amluto 6y ago

> While C++ had the problem of "lots of template code in header files", Rust has the problem that monomorphization of generics creates a lot of compiled code. There are tricks to avoid this and they are all the decision of the library/crate author. Is there any research on having compilers do some of these tricks automatically? A compiler should, at least in principle, be able to tell what aspects of a type parameter are used in a given piece of code. Such a compiler could plausibly produce code that is partially or fully type-erased automatically without losing efficiency. In some cases, I would believe that code size, runtime performance (due to improved cache behavior), and compile times would all improve.

sanxiyn 6y ago
Implementing type erasure for Rust compiler is a research problem. In principle it ought to be possible, but I am not aware of any prior work.

mixmastamyk 6y ago

There's a lot of either/or false dichotomy being discussed in here. Distro packaging (or not) comes with various tradeoffs of course, some good or bad depending on perspective. To get to the point, I quite prefer the package manager way of installing software to "hunt down a single release" app installers of Windows/Mac. The only issue is that sometimes software is a bit out of date. That's what the snap/flat pack/appimage projects are trying to solve. As soon as one of those three get their user-hostile issues fixed, it will be a software paradise. :D