4 ms·

They're dismissive of your comments because you don't understand that most OS systems programming realistically has to be done in C. If you want to create a li

They're dismissive of your comments because you don't understand that most OS systems programming realistically has to be done in C. If you want to create a library like OpenSSL that every consumer in every language can use, C is your only practical choice.

wtetzner 12y ago
Well, hopefully in the not-too-distant future, Rust will be a good choice for these kinds of projects.
- binarycrusader 12y ago
  Rust unfortunately has a dependency on LLVM, which is not yet available for some hardware and OS platforms. I realize that's improving, but it does make Rust adoption slower for systems programming where languages that only require a standard C or C++ compiler thrive. Also, while I think it will likely prove a great alternative (especially for OS level systems programming), it's clearly early days and the language is still undergoing significant churn.
voidlogic 12y ago
I'm a professional systems programmer, I understand C has been the lingua franca and why. If today I was creating OpenSSL from scratch there are other options. If I need it NOW I could use D. If I was willing to wait a few months or contribute Go shared library support I could use Go. If I was willing to wait until Rust was mature to release and deal with its churn in development I could use Rust. I guess I'm just suffering from sour grapes over the fact HN continues to suffer more and more of down-voting for sake of disagreement rather than for factual inaccuracy.
- binarycrusader 12y ago
  Go or D is a very large set of dependencies for a security-focused library and hence unlikely to be suitable for a project like OpenSSL that is designed for use everywhere and by everyone in every language. Security code that needs to be audited should be as minimal as possible. Go and D are also not yet available for every platform and would force a set of design constraints on consumers that would likely decrease its attractiveness as a solution. Again, C remains the best choice given the goals I mentioned. It's also why I said OS systems programming and not just systems programming.
  - voidlogic 12y ago
    Go between the golang.org compiler and gccgo, Go runs on a pretty vast array of architectures. I think for a security related project, I would be happy to best serve the 99% and leave some minor architectures to find another solution if that meant being able to implement a SSL/TLS library in a fast memory safe language. After, one of the root problems of OpenSSL was it tried to be all things to all people. As for Go's large dependencies are you talking about the Go runtime as build time dependency, because Go is notable for its pronounced lack of runtime dependencies? In any case, I think you and I both have an understanding of the issues at hand, I just think we would be willing to make different trade-offs.
    - binarycrusader 12y ago
      You're right; I don't think your tradeoffs are as reasonable as you believe, and I don't think they're tradeoffs that most would be willing to make. The reality is that those "minor" platforms you refer to are ones where a lot of big iron and expensive systems are. While Go / LLVM will eventually be supported on them, Go is still a very large dependency, and is currently not suitable for OS systems programming. If you did choose to write a new security library in Go, and supposing that the shared library issue was addressed, you'd still have to severely constrain the design of the library to ensure maximum interoperability. I'm just not sure it's worth the compromise. Rust, if it was ready, and its runtime dependencies were also better supported, would be far more appropriate than Go.
      - hga 12y ago
        A very good point; I'm considering using LLVM for some projects, but I'm only interested in 32 and 64 bit x86 and ARM targets. What big iron targets would you say are also required? Here are some possibilities I can think of: SPARC, IBM's z/Architecture (what about ESA/390 or earlier?) and POWER (the latter of which historically includes more than one ISA), Intel's IA-64 (Itanium, used by HP). Modulo the various Power ISAs, which I am not familiar with, LLVM claims "is generally reliable" support for all of the about except IA-64: http://llvm.org/docs/CodeGenerator.html#target-feature-matrix http://llvm.org/docs/CodeGenerator.html#target-feature-matri... Which doesn't mean production level quality, of course. More critically, just because LLVM has back end support of an architecture, doesn't mean any particular language using LLVM will support it, or at least as I recall, the language has to know and use details about the back ends it's targeting.

wtetzner 12y ago

Well, hopefully in the not-too-distant future, Rust will be a good choice for these kinds of projects.

binarycrusader 12y ago
Rust unfortunately has a dependency on LLVM, which is not yet available for some hardware and OS platforms. I realize that's improving, but it does make Rust adoption slower for systems programming where languages that only require a standard C or C++ compiler thrive. Also, while I think it will likely prove a great alternative (especially for OS level systems programming), it's clearly early days and the language is still undergoing significant churn.

voidlogic 12y ago

I'm a professional systems programmer, I understand C has been the lingua franca and why. If today I was creating OpenSSL from scratch there are other options. If I need it NOW I could use D. If I was willing to wait a few months or contribute Go shared library support I could use Go. If I was willing to wait until Rust was mature to release and deal with its churn in development I could use Rust. I guess I'm just suffering from sour grapes over the fact HN continues to suffer more and more of down-voting for sake of disagreement rather than for factual inaccuracy.

binarycrusader 12y ago
Go or D is a very large set of dependencies for a security-focused library and hence unlikely to be suitable for a project like OpenSSL that is designed for use everywhere and by everyone in every language. Security code that needs to be audited should be as minimal as possible. Go and D are also not yet available for every platform and would force a set of design constraints on consumers that would likely decrease its attractiveness as a solution. Again, C remains the best choice given the goals I mentioned. It's also why I said OS systems programming and not just systems programming.
- voidlogic 12y ago
  Go between the golang.org compiler and gccgo, Go runs on a pretty vast array of architectures. I think for a security related project, I would be happy to best serve the 99% and leave some minor architectures to find another solution if that meant being able to implement a SSL/TLS library in a fast memory safe language. After, one of the root problems of OpenSSL was it tried to be all things to all people. As for Go's large dependencies are you talking about the Go runtime as build time dependency, because Go is notable for its pronounced lack of runtime dependencies? In any case, I think you and I both have an understanding of the issues at hand, I just think we would be willing to make different trade-offs.
  - binarycrusader 12y ago
    You're right; I don't think your tradeoffs are as reasonable as you believe, and I don't think they're tradeoffs that most would be willing to make. The reality is that those "minor" platforms you refer to are ones where a lot of big iron and expensive systems are. While Go / LLVM will eventually be supported on them, Go is still a very large dependency, and is currently not suitable for OS systems programming. If you did choose to write a new security library in Go, and supposing that the shared library issue was addressed, you'd still have to severely constrain the design of the library to ensure maximum interoperability. I'm just not sure it's worth the compromise. Rust, if it was ready, and its runtime dependencies were also better supported, would be far more appropriate than Go.
    - hga 12y ago
      A very good point; I'm considering using LLVM for some projects, but I'm only interested in 32 and 64 bit x86 and ARM targets. What big iron targets would you say are also required? Here are some possibilities I can think of: SPARC, IBM's z/Architecture (what about ESA/390 or earlier?) and POWER (the latter of which historically includes more than one ISA), Intel's IA-64 (Itanium, used by HP). Modulo the various Power ISAs, which I am not familiar with, LLVM claims "is generally reliable" support for all of the about except IA-64: http://llvm.org/docs/CodeGenerator.html#target-feature-matrix http://llvm.org/docs/CodeGenerator.html#target-feature-matri... Which doesn't mean production level quality, of course. More critically, just because LLVM has back end support of an architecture, doesn't mean any particular language using LLVM will support it, or at least as I recall, the language has to know and use details about the back ends it's targeting.