4 ms·

Why would you soil the name of Rust with the other two languages on the list? There are far superior options with way better ARM64 support.

yawboakye 3y ago
fwiw you’d find more web services written in ‘the other two languages on the list’ than rust. if there’s soiling at all, then the shoe is on the wrong foot.
- neonsunset 3y ago
  Will you also say that JavaScript semantics and gotchas are good because millions of developers use it? Even if something is widespread, it does not make it good, especially not in the context of a newcomer platform in a server market.
  - yawboakye 3y ago
    > will you also say that javascript semantics and gotchas are good because millions of developers use it? unrelated to your original argument and so i’ll treat it as diversionary and ignore. that said, it’s an important signal that you suffer a deficiency in clear, systematic thinking. i’m happy to re-engage when you rid your arguments of these ‘tin whiskers’ that are equally as damaging as actual tin whiskers.
    - neonsunset 3y ago
      That's rich coming from a go dev :)
      - yawboakye 3y ago
        and ruby. go and ruby. oh and javascript. go and ruby and javascript.
15155 3y ago
I use Rust across 6+ different target architectures - in webserver applications, in soft CPUs of my own design, constant no_std. I have the luxury of only using Rust in much of my work. With that being said, Go is easier and more consistent for cross-compilation than Rust for web server applications. This is a result of the stdlib being so expansive and also 100% golang - down to the DNS resolver. Every non-CGO application will behave similarly. This is not true for Rust.
- neonsunset 3y ago
  I disagree on the choice of Go and die a little inside whenever it is suggested as the prime language for back-end workloads. To quote the Rob Pike himself: "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." The better languages for this at ARM64 hosts are C# and Kotlin. One has a lot of investment in high-performance primitives (including the full set of ARM64 SIMD intrinsics), another one has the power of JVM ecosystem. Both have really nice frameworks you don't need to massage to reach high throughput: ASP.NET Core and Vert.X/ActiveJ.
  - 15155 3y ago
    The language not being semantically "good" does not change the webserver cross-compilation story being easier and more consistent than every other platform. I wouldn't voluntarily choose to use Go, but this is absolutely one of its "killer features." C# and JVM languages both require a substantial amount of tooling and runtime support to achieve this "cross-platform" status and it's still really not the same thing as being able to take a 100% Go source repository and releasing native Windows, OSX, and Linux binaries for both ARM64 and AMD64 machines with no additional tooling from any source machine with just a couple of CLI flags. With Go, I don't have to install a runtime on the target machine nor do I have to hackily bundle one into my binary. I don't have to make sure the runtime version installed on my system is compatible with whatever I am doing. I don't have to paper over the lack of this functionality with Docker.

yawboakye 3y ago

fwiw you’d find more web services written in ‘the other two languages on the list’ than rust. if there’s soiling at all, then the shoe is on the wrong foot.

neonsunset 3y ago
Will you also say that JavaScript semantics and gotchas are good because millions of developers use it? Even if something is widespread, it does not make it good, especially not in the context of a newcomer platform in a server market.
- yawboakye 3y ago
  > will you also say that javascript semantics and gotchas are good because millions of developers use it? unrelated to your original argument and so i’ll treat it as diversionary and ignore. that said, it’s an important signal that you suffer a deficiency in clear, systematic thinking. i’m happy to re-engage when you rid your arguments of these ‘tin whiskers’ that are equally as damaging as actual tin whiskers.
  - neonsunset 3y ago
    That's rich coming from a go dev :)
    - yawboakye 3y ago
      and ruby. go and ruby. oh and javascript. go and ruby and javascript.

15155 3y ago

I use Rust across 6+ different target architectures - in webserver applications, in soft CPUs of my own design, constant no_std. I have the luxury of only using Rust in much of my work. With that being said, Go is easier and more consistent for cross-compilation than Rust for web server applications. This is a result of the stdlib being so expansive and also 100% golang - down to the DNS resolver. Every non-CGO application will behave similarly. This is not true for Rust.

neonsunset 3y ago
I disagree on the choice of Go and die a little inside whenever it is suggested as the prime language for back-end workloads. To quote the Rob Pike himself: "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." The better languages for this at ARM64 hosts are C# and Kotlin. One has a lot of investment in high-performance primitives (including the full set of ARM64 SIMD intrinsics), another one has the power of JVM ecosystem. Both have really nice frameworks you don't need to massage to reach high throughput: ASP.NET Core and Vert.X/ActiveJ.
- 15155 3y ago
  The language not being semantically "good" does not change the webserver cross-compilation story being easier and more consistent than every other platform. I wouldn't voluntarily choose to use Go, but this is absolutely one of its "killer features." C# and JVM languages both require a substantial amount of tooling and runtime support to achieve this "cross-platform" status and it's still really not the same thing as being able to take a 100% Go source repository and releasing native Windows, OSX, and Linux binaries for both ARM64 and AMD64 machines with no additional tooling from any source machine with just a couple of CLI flags. With Go, I don't have to install a runtime on the target machine nor do I have to hackily bundle one into my binary. I don't have to make sure the runtime version installed on my system is compatible with whatever I am doing. I don't have to paper over the lack of this functionality with Docker.