4 ms·

At this point, why not just use C?

by identity0 6y ago

ayush--s 6y ago
that'd be rewrite
- secondcoming 6y ago
  They've done the hard work already. It'd be trivial to port.
pjmlp 6y ago
UB, memory leaks, memory corruption, implicit conversions,... The benefit of using Go is keeping the memory safety for like 90% of the application, with just a tiny unsafe code portion. In C, 100% of the source code is unsafe.
- flohofwoe 6y ago
  Assuming that Go can easily call into C code you can still implement the performance-critical parts in carefully written and tested C and the other 90% in high-level Go. On the other hand, if implanting a faster allocator fixes performance problems, then there's something bigger amiss in the overall application design. Creating and destroying small objects at such a high frequency that memory management overhead becomes noticeable isn't a good idea in any case, GC or not.
  - pjmlp 6y ago
    > performance-critical parts in carefully written and tested C Is something that not even the Linux kernel with its careful and throughout patch review process is not able to achieve.
  - identity0 6y ago
    I believe calling C from Go is a massive pain, and is slow, because of goroutines. Go makes the OS syscalls directly to avoid going through libc.
- identity0 6y ago
  -Wimplicit, UBSan, ASan,... The idea that "you can't write safe C" is a big joke. C is as safe as you make it.
  - pjmlp 6y ago
    Right, and the CVE database doesn't exist either, it is just a conspiracy theory created by those of us against C mythical lack of security. https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro... https://www.chromium.org/Home/chromium-security/memory-safety https://www.chromium.org/Home/chromium-security/memory-safet... https://cwe.mitre.org/data/definitions/416.html https://cwe.mitre.org/data/definitions/416.html https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/chrome-70-of-all-security-bugs...
- noch 6y ago
  > UB, memory leaks, memory corruption, implicit conversions,[...] > In C, 100% of the source code is unsafe Is it perhaps better to focus on context? That is,cost vs benifit wrt context: - How much safety and what kind and level of safety assurances does the specific application need? - How much does it cost in development time/friction, application performance, engineering complexity, [insert other relevant cost axes] to achieve the desired level of safety and safety assurances?
  - pjmlp 6y ago
    As proven by the high integrity security standards, if you want to write safety proven code in C, there is no way around something like MISRA-C, Frama-C, alongside certification tooling like the one sold by LDRA. https://www.ldra.com/ https://www.ldra.com/ Naturally this is a kind of expenses that 99% of the companies aren't going to spend until it finally becomes a legal liability to have security exploits on the software.

At this point, why not just use C?

ayush--s 6y ago

that'd be rewrite

secondcoming 6y ago
They've done the hard work already. It'd be trivial to port.

pjmlp 6y ago

UB, memory leaks, memory corruption, implicit conversions,... The benefit of using Go is keeping the memory safety for like 90% of the application, with just a tiny unsafe code portion. In C, 100% of the source code is unsafe.

flohofwoe 6y ago
Assuming that Go can easily call into C code you can still implement the performance-critical parts in carefully written and tested C and the other 90% in high-level Go. On the other hand, if implanting a faster allocator fixes performance problems, then there's something bigger amiss in the overall application design. Creating and destroying small objects at such a high frequency that memory management overhead becomes noticeable isn't a good idea in any case, GC or not.
- pjmlp 6y ago
  > performance-critical parts in carefully written and tested C Is something that not even the Linux kernel with its careful and throughout patch review process is not able to achieve.
- identity0 6y ago
  I believe calling C from Go is a massive pain, and is slow, because of goroutines. Go makes the OS syscalls directly to avoid going through libc.
identity0 6y ago
-Wimplicit, UBSan, ASan,... The idea that "you can't write safe C" is a big joke. C is as safe as you make it.
- pjmlp 6y ago
  Right, and the CVE database doesn't exist either, it is just a conspiracy theory created by those of us against C mythical lack of security. https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro... https://www.chromium.org/Home/chromium-security/memory-safety https://www.chromium.org/Home/chromium-security/memory-safet... https://cwe.mitre.org/data/definitions/416.html https://cwe.mitre.org/data/definitions/416.html https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/chrome-70-of-all-security-bugs...
noch 6y ago
> UB, memory leaks, memory corruption, implicit conversions,[...] > In C, 100% of the source code is unsafe Is it perhaps better to focus on context? That is,cost vs benifit wrt context: - How much safety and what kind and level of safety assurances does the specific application need? - How much does it cost in development time/friction, application performance, engineering complexity, [insert other relevant cost axes] to achieve the desired level of safety and safety assurances?
- pjmlp 6y ago
  As proven by the high integrity security standards, if you want to write safety proven code in C, there is no way around something like MISRA-C, Frama-C, alongside certification tooling like the one sold by LDRA. https://www.ldra.com/ https://www.ldra.com/ Naturally this is a kind of expenses that 99% of the companies aren't going to spend until it finally becomes a legal liability to have security exploits on the software.