14 ms·

not picking on it specifically but I just recently saw that flatpak is written in C as well despite the fact that it was released just eight years ago. Red Hat

not picking on it specifically but I just recently saw that flatpak is written in C as well despite the fact that it was released just eight years ago. Red Hat is one of the companies that also has a strange C addiction for almost anything. There's pretty much no reason to not use a memory safe, performant language like Go at this point for infrastructure-ish software.

loo 3y ago
Red Hat should switch to Zig.
- gabereiser 3y ago
  But Red Hat and Rust just Roll off the tongue
  - dmux 3y ago
    Or Red Hat and Red Lang [0] [0] https://www.red-lang.org/ https://www.red-lang.org/
gabereiser 3y ago
Go is tough to get approved in certain Red Hat markets. Simply because it calls out to github for packages without an audit tool. A lot of finance companies have blocked the use of Golang because of that. Totally fine with Java and their own Nexus. Same with Javascript and their own NPM on Nexus. But they can't see past `go get github.com...` When they totally could be doing `go get sources.redhat.com...`
- klooney 3y ago
  Go has a thing for that now- everything goes through a proxy (https://proxy.golang.org https://proxy.golang.org), and if you set GO_PROXY, you can send it through your proxy (Nexus et al).
  - a1o 3y ago
    I don't know for Go case how it would work, but what I saw in case of Maven is it's company wide blocked and you have to get your packages through Sonatype Nexus - and Nexus either has it's own packages or it has a proxy for Maven packages. So I wonder in case of Go, if it would be unfeasible to block GitHub so they would just block the entire use of the language in company developed software.
    - gabereiser 3y ago
      exactly. If you block go packages via firewall IT rules, you block github.com software engineering work. It's the one thing I think that's holding Golang back. Deno as well. I know it looks novel but it's a security nightmare.
      - klooney 3y ago
        Blocking the official Google Go proxy will work pretty well, go get will just fail by default. If someone works around that on a developer machine, it shouldn't matter, because release builds should still come from an automated system, right?
  - gabereiser 3y ago
    yeah, go modules have streamlined golang development so much. Providing a custom domain configuration on your site allows go to grab the code vs a user visiting it in their browser.
- wbl 3y ago
  The audit tool is go.sum
dralley 3y ago
>not picking on it specifically but I just recently saw that flatpak is written in C as well despite the fact that it was released just eight years ago. You say "just 8 years ago" but another way of phrasing that would be "only 4 months after Rust went 1.0". And that's the first release, which means work probably started before Rust went 1.0 >Red Hat is one of the companies that also has a strange C addiction for almost anything. This is kinda true and I wish it was different, but most of the examples people bring up are ones like the one you brought up. Rust wasn't a "safe choice" at the time they were started. There's other factors too, like needing to support POWER and Z architectures. If you have a lot of such products written in C, and you have a GCC toolchain team in-house, that's not so difficult. If you have a lot of such products written in Rust, and your LLVM toolchain team is much smaller and the compiler itself less mature on those platforms, it's a bit more challenging. And then the whole issue of dynamic vs. static linking, where there's a ton of organizational inertia in favor of the former. All that said I think the list of valid excuses is increasingly small nowadays.

loo 3y ago

Red Hat should switch to Zig.

gabereiser 3y ago
But Red Hat and Rust just Roll off the tongue
- dmux 3y ago
  Or Red Hat and Red Lang [0] [0] https://www.red-lang.org/ https://www.red-lang.org/

gabereiser 3y ago

Go is tough to get approved in certain Red Hat markets. Simply because it calls out to github for packages without an audit tool. A lot of finance companies have blocked the use of Golang because of that. Totally fine with Java and their own Nexus. Same with Javascript and their own NPM on Nexus. But they can't see past `go get github.com...` When they totally could be doing `go get sources.redhat.com...`

klooney 3y ago
Go has a thing for that now- everything goes through a proxy (https://proxy.golang.org https://proxy.golang.org), and if you set GO_PROXY, you can send it through your proxy (Nexus et al).
- a1o 3y ago
  I don't know for Go case how it would work, but what I saw in case of Maven is it's company wide blocked and you have to get your packages through Sonatype Nexus - and Nexus either has it's own packages or it has a proxy for Maven packages. So I wonder in case of Go, if it would be unfeasible to block GitHub so they would just block the entire use of the language in company developed software.
  - gabereiser 3y ago
    exactly. If you block go packages via firewall IT rules, you block github.com software engineering work. It's the one thing I think that's holding Golang back. Deno as well. I know it looks novel but it's a security nightmare.
    - klooney 3y ago
      Blocking the official Google Go proxy will work pretty well, go get will just fail by default. If someone works around that on a developer machine, it shouldn't matter, because release builds should still come from an automated system, right?
- gabereiser 3y ago
  yeah, go modules have streamlined golang development so much. Providing a custom domain configuration on your site allows go to grab the code vs a user visiting it in their browser.
wbl 3y ago
The audit tool is go.sum

dralley 3y ago

>not picking on it specifically but I just recently saw that flatpak is written in C as well despite the fact that it was released just eight years ago. You say "just 8 years ago" but another way of phrasing that would be "only 4 months after Rust went 1.0". And that's the first release, which means work probably started before Rust went 1.0 >Red Hat is one of the companies that also has a strange C addiction for almost anything. This is kinda true and I wish it was different, but most of the examples people bring up are ones like the one you brought up. Rust wasn't a "safe choice" at the time they were started. There's other factors too, like needing to support POWER and Z architectures. If you have a lot of such products written in C, and you have a GCC toolchain team in-house, that's not so difficult. If you have a lot of such products written in Rust, and your LLVM toolchain team is much smaller and the compiler itself less mature on those platforms, it's a bit more challenging. And then the whole issue of dynamic vs. static linking, where there's a ton of organizational inertia in favor of the former. All that said I think the list of valid excuses is increasingly small nowadays.