4 ms·

I’ve specifically gone hunting for this documentation and never found it. Thanks for the tip! I love C#, but I’ve been in PHP/Go land for awhile now. PHP is an

I’ve specifically gone hunting for this documentation and never found it. Thanks for the tip! I love C#, but I’ve been in PHP/Go land for awhile now. PHP is an interesting language, I’d have never thought I’d like it as much as I do. It’d also be cool to see a Go implementation, but there’s also cgo.

neonsunset 3y ago
:( But on occasion you go the first route, the docs are here: - https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/interop#native-exports https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... +adjacent sections - https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.unmanagedcallersonlyattribute https://learn.microsoft.com/en-us/dotnet/api/system.runtime.... This pretty much comes down to writing glue exports the way you would do in Rust and then 'dotnet publish'ing it as .dll/.so (you could also produce .lib/.a for static linking but it is trickier). Overall, I feel like the ungodly amount of projects of this kind (albeit of lower complexity) written in Go (which is a weaker platform) could have benefitted from using C# instead - it has zero-cost abstractions through struct generics like Rust and allows expressing complex data structures in a terser way.
- withinboredom 3y ago
  I think a lot of what go has going for it is in static compilation. Things just work. The C# community leans a lot further from open source (paid libraries vs. free).
  - neonsunset 3y ago
    Go receives so much unjustified good will it is almost unbelievable... Either way, if you do look at current state of .NET ecosystem, you may get surprised. But I guess, such is the perception of the public that may have read a bit too much into Go's promises (it would have abysmal performance should FASTER have been written in Go) - C#, seen as less popular weird Java, is now an underdog after all (look at Github LOC statistics).
    - withinboredom 3y ago
      > Go receives so much unjustified good will it is almost unbelievable... Yes. Yes it does and it really is annoying. I can't tell if it is the language or just people not deeply understand the abstractions it provides because it doesn't use sane defaults (or the defaults are geared towards high-throughput, google scale nonsense). I help out a lot on FrankenPHP, and lately I've been digging into a weird bug, deep in Go, that causes FIN_ACK packets to get delayed by hundreds and hundreds of ms. There are so many layers of abstractions (nearly 100) to dig through. I know for a fact in the C# there are less than 10 to the CLR, then after you can rule out the language, you are just tracing IR. But no, I'm digging through hand-written asm, hunting for a bug or at least figure out how to report it with enough information that it doesn't sound like "my email can't be sent more than 500 miles" (google that one btw).
      - apgwoz 3y ago
        > I've been digging into a weird bug, deep in Go, that causes FIN_ACK packets to get delayed by hundreds and hundreds of ms. Just going to put it out there: have you considered the problem might actually be [Nagle’s Algorithm](https://en.wikipedia.org/wiki/Nagle's_algorithm) https://en.wikipedia.org/wiki/Nagle's_algorithm)? This algorithm is the source of 10s of thousands of hours of wasted debugging time of “weird bugs related to latency of networking.” Even the “greats” have wasted time debugging something that ended up being “I forgot about Nagle.”
        withinboredom 3y ago
        Yes. Go doesn't even offer the ability to use Nagle's algorithm: https://withinboredom.info/2022/12/29/golang-is-evil-on-shitty-networks/ https://withinboredom.info/2022/12/29/golang-is-evil-on-shit... Nagle's algorithm is dealing with connections. These are FIN_ACK. Meaning the connection was told to close and we need to ack the closed connection.
        kjksf 3y ago
        Of course it does: just call TCPConn.SetNoDelay(false). See https://github.com/golang/go/blob/master/src/net/tcpsock.go#L258C19-L258C29 https://github.com/golang/go/blob/master/src/net/tcpsock.go#...

neonsunset 3y ago

:( But on occasion you go the first route, the docs are here: - https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/interop#native-exports https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... +adjacent sections - https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.unmanagedcallersonlyattribute https://learn.microsoft.com/en-us/dotnet/api/system.runtime.... This pretty much comes down to writing glue exports the way you would do in Rust and then 'dotnet publish'ing it as .dll/.so (you could also produce .lib/.a for static linking but it is trickier). Overall, I feel like the ungodly amount of projects of this kind (albeit of lower complexity) written in Go (which is a weaker platform) could have benefitted from using C# instead - it has zero-cost abstractions through struct generics like Rust and allows expressing complex data structures in a terser way.

withinboredom 3y ago
I think a lot of what go has going for it is in static compilation. Things just work. The C# community leans a lot further from open source (paid libraries vs. free).
- neonsunset 3y ago
  Go receives so much unjustified good will it is almost unbelievable... Either way, if you do look at current state of .NET ecosystem, you may get surprised. But I guess, such is the perception of the public that may have read a bit too much into Go's promises (it would have abysmal performance should FASTER have been written in Go) - C#, seen as less popular weird Java, is now an underdog after all (look at Github LOC statistics).
  - withinboredom 3y ago
    > Go receives so much unjustified good will it is almost unbelievable... Yes. Yes it does and it really is annoying. I can't tell if it is the language or just people not deeply understand the abstractions it provides because it doesn't use sane defaults (or the defaults are geared towards high-throughput, google scale nonsense). I help out a lot on FrankenPHP, and lately I've been digging into a weird bug, deep in Go, that causes FIN_ACK packets to get delayed by hundreds and hundreds of ms. There are so many layers of abstractions (nearly 100) to dig through. I know for a fact in the C# there are less than 10 to the CLR, then after you can rule out the language, you are just tracing IR. But no, I'm digging through hand-written asm, hunting for a bug or at least figure out how to report it with enough information that it doesn't sound like "my email can't be sent more than 500 miles" (google that one btw).
    - apgwoz 3y ago
      > I've been digging into a weird bug, deep in Go, that causes FIN_ACK packets to get delayed by hundreds and hundreds of ms. Just going to put it out there: have you considered the problem might actually be [Nagle’s Algorithm](https://en.wikipedia.org/wiki/Nagle's_algorithm) https://en.wikipedia.org/wiki/Nagle's_algorithm)? This algorithm is the source of 10s of thousands of hours of wasted debugging time of “weird bugs related to latency of networking.” Even the “greats” have wasted time debugging something that ended up being “I forgot about Nagle.”
      - withinboredom 3y ago
        Yes. Go doesn't even offer the ability to use Nagle's algorithm: https://withinboredom.info/2022/12/29/golang-is-evil-on-shitty-networks/ https://withinboredom.info/2022/12/29/golang-is-evil-on-shit... Nagle's algorithm is dealing with connections. These are FIN_ACK. Meaning the connection was told to close and we need to ack the closed connection.
        kjksf 3y ago
        Of course it does: just call TCPConn.SetNoDelay(false). See https://github.com/golang/go/blob/master/src/net/tcpsock.go#L258C19-L258C29 https://github.com/golang/go/blob/master/src/net/tcpsock.go#...