3 ms·

> How do I add GLib as a dependency to my C project? Use symbol versioning. Anyway, I feel the author is a bit unfair. He traded supporting multiple compilers

> How do I add GLib as a dependency to my C project? Use symbol versioning. Anyway, I feel the author is a bit unfair. He traded supporting multiple compilers for Rust's only and it is not really surprising that he felt that the maintainer burden decreased. As soon as Rust gets broad adaption I guess there will be subtly incompatible compiler vendors in Rust too.

masklinn 5y ago
> Use symbol versioning. That doesn't mean anything. > Anyway, I feel the author is a bit unfair. He traded supporting multiple compilers They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to.
- jcelerier 5y ago
  > They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to. No, people are just inflicting that upon themselves for no good reason. I ship software built with the same clang / libc++ toolchain targetting Mac / Windows / Linux and things works absolutely fine.
  - masklinn 5y ago
    > I ship software Is it an open-source library?
- rightbyte 5y ago
  > That doesn't mean anything. I meant that you can specify symbol versions to link to glibc specifically. https://sourceware.org/binutils/docs/ld/VERSION.html https://sourceware.org/binutils/docs/ld/VERSION.html > They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to. He could have used gcc on different platforms too. He writes: "the platonic ideal portable C exists only as a hypothetical construct in the C standard. The C that exists in the real world is whatever Microsoft, Apple, and others have shipped. That C is a mess" I.e. his problem could have been solved by sticking to one compiler, be it Rust or Clang ...
  - jcranmer 5y ago
    > I meant that you can specify symbol versions to link to glibc specifically. sanxiyn was talking about GLib, not glibc, and these are two very different projects...
  - masklinn 5y ago
    > I meant that you can specify symbol versions to link to glibc specifically. You're confusing glibc and GLib... > He could have used gcc on different platforms too. That certainly would have solved the multiple platform issue, I'm sure gcc has great and easy support for producing VS-compatible dlls, and that there's nothing an ios dev likes to hear more than "you can use GCC to compile libimagequant".
pornel 5y ago
I don't think that fragmentation is a given. Other implementations may never take off. Python, Node.js, Java, PHP, C#, Golang, Ruby are all more popular and older than Rust, and did not develop fragmentation like C. They have one dominant target, and other implementations have to follow it, or die. Rust's situation is closer to these languages than to C. But even if there were serious contenders, Rust has already established a strong baseline: there are over 70,000[1] packages that require Rust+Cargo in their current form. A viable alternative has to support them, or it will be niche like mrustc is. [1]: https://lib.rs/stats https://lib.rs/stats
- rightbyte 5y ago
  Ye that is true (isn't Java a bad example though with Google-Java, OpenJdk vs BigEnterpriseJdk etc?).
  - masklinn 5y ago
    Java could have been a good example, but Sun had a rather strict validation process for calling something Java. Furthermore, there are big difference in philosophy with C: 1. IB and UB are not considered normal parts of specifications, meaning there's way less opportunity for originality in the interpretation of the specifications 2. there tends to be an ur-implementation, and notable divergences from that tends to be interpreted as either a bug in the other implementation(s) or a lack of specification to be resolved between all implementations Rust only has UB in unsafe (AFAIK), which greatly limits implementation flexibility in terms of observable behaviour; and the reference implementation would very much be considered the reference implementation, so I expect e.g. rust-gcc will be sticking close to the reference implementation and behavioural divergence will either be fixed to match, or will lead to more precise specification and both implementations converging. Probably eventually with, if not a Sun-style validation suite, a Ruby-style Spec Suite (https://github.com/ruby/spec https://github.com/ruby/spec).

masklinn 5y ago

> Use symbol versioning. That doesn't mean anything. > Anyway, I feel the author is a bit unfair. He traded supporting multiple compilers They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to.

jcelerier 5y ago
> They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to. No, people are just inflicting that upon themselves for no good reason. I ship software built with the same clang / libc++ toolchain targetting Mac / Windows / Linux and things works absolutely fine.
- masklinn 5y ago
  > I ship software Is it an open-source library?
rightbyte 5y ago
> That doesn't mean anything. I meant that you can specify symbol versions to link to glibc specifically. https://sourceware.org/binutils/docs/ld/VERSION.html https://sourceware.org/binutils/docs/ld/VERSION.html > They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to. He could have used gcc on different platforms too. He writes: "the platonic ideal portable C exists only as a hypothetical construct in the C standard. The C that exists in the real world is whatever Microsoft, Apple, and others have shipped. That C is a mess" I.e. his problem could have been solved by sticking to one compiler, be it Rust or Clang ...
- jcranmer 5y ago
  > I meant that you can specify symbol versions to link to glibc specifically. sanxiyn was talking about GLib, not glibc, and these are two very different projects...
- masklinn 5y ago
  > I meant that you can specify symbol versions to link to glibc specifically. You're confusing glibc and GLib... > He could have used gcc on different platforms too. That certainly would have solved the multiple platform issue, I'm sure gcc has great and easy support for producing VS-compatible dlls, and that there's nothing an ios dev likes to hear more than "you can use GCC to compile libimagequant".

pornel 5y ago

I don't think that fragmentation is a given. Other implementations may never take off. Python, Node.js, Java, PHP, C#, Golang, Ruby are all more popular and older than Rust, and did not develop fragmentation like C. They have one dominant target, and other implementations have to follow it, or die. Rust's situation is closer to these languages than to C. But even if there were serious contenders, Rust has already established a strong baseline: there are over 70,000[1] packages that require Rust+Cargo in their current form. A viable alternative has to support them, or it will be niche like mrustc is. [1]: https://lib.rs/stats https://lib.rs/stats

rightbyte 5y ago
Ye that is true (isn't Java a bad example though with Google-Java, OpenJdk vs BigEnterpriseJdk etc?).
- masklinn 5y ago
  Java could have been a good example, but Sun had a rather strict validation process for calling something Java. Furthermore, there are big difference in philosophy with C: 1. IB and UB are not considered normal parts of specifications, meaning there's way less opportunity for originality in the interpretation of the specifications 2. there tends to be an ur-implementation, and notable divergences from that tends to be interpreted as either a bug in the other implementation(s) or a lack of specification to be resolved between all implementations Rust only has UB in unsafe (AFAIK), which greatly limits implementation flexibility in terms of observable behaviour; and the reference implementation would very much be considered the reference implementation, so I expect e.g. rust-gcc will be sticking close to the reference implementation and behavioural divergence will either be fixed to match, or will lead to more precise specification and both implementations converging. Probably eventually with, if not a Sun-style validation suite, a Ruby-style Spec Suite (https://github.com/ruby/spec https://github.com/ruby/spec).