3 ms·

How do you know they chose the wrong tool for the job without more context into the decision making process and important factors/constraints at the time?

by cle 6y ago

shmerl 6y ago
When you need to fight the garbage collector in a language that has one by design, it's a clear sign the wrong language was chosen, even if you'll find clever ways to fight it.
- cle 6y ago
  My point is that, even if that is true, there are many other factors that go into technical decisions than pure technical merits. These decisions happen in the context of a business, with existing systems, codebases, teams of people with different experiences and preferences, unique market dynamics, etc. To say "you used the wrong tool for the job" without considering the conditions under which that tool was chosen isn't a productive assertion.
  - shmerl 6y ago
    I've heard such argument before, and it's often misused to justify the choice of the wrong tool in my opinion, because it's not based on objective technical reasons. So it's easy to use it with vague logic of "there are some business needs".
    - cle 6y ago
      Are you saying the non-technical reasons they considered weren’t valid? What were they?
      - shmerl 6y ago
        I'm saying this argument is often misused in practice.
scottlamb 6y ago
I peeked at the reddit conversation earthboundkid mentioned. [1] The author wrote there: > Go’s code readability, concurrency model, fast compilation, gofmt, go profiler, go vet, performance and so on. Also, we didn’t ditch Go GC entirely. We’re still using it pretty expansively in all non-critical paths and wherever it’s hard to trace the memory ownership and release. > I see this as a no different than taking some pieces of your code and converting them to assembly (utilize SIMD instructions, for e.g.), which Go does as well. Also, note that the workload that databases need to incur are lot heavier than typical Go applications. I don't think most of those are too satisfying as reasons to choose Go over Rust for this program. I think Go's code readability and safety are significantly compromised by this kind of manual memory management, enough so that I'd consider Rust more readable in this context. Likewise Rust's performance is significantly better—the biggest reason Go is faster to compile is that it has a simple compiler that does almost no optimizations. Rust can do that, too, in debug mode, especially with the recent cranelift backend. And Rust has equivalents to "go fmt" and "go vet". Now it's quite possible that when they started this program years ago, Rust wasn't a good choice. Obviously at least the cranelift backend I just mentioned didn't exist at the time. Pragmatically, you often end up with this kind of "path-dependent design" / "for legacy reasons". Porting is a lot of effort, maybe more than is worth it. You can't always be chasing the hot new fashion or you'd get nothing else done. I think it still should be acknowledged however that a better tool exists now. I agree with them the concurrency model in Go is genuinely more pleasant than in Rust. In Go, you just write synchronous code and it gets translated to a green thread model for you. In Rust, there's the async stuff which is harder to program and an async ecosystem that is still settling today. That's a clear advantage for Go, and maybe also why they say Go is more readable. (I find Rust otherwise pleasant to read.) And maybe Go is more reasonable for the non-critical path stuff as they said, and maybe that does have to be in the same program. [1] https://www.reddit.com/r/golang/comments/jobgq9/manual_memory_management_in_go_with_jemalloc/ https://www.reddit.com/r/golang/comments/jobgq9/manual_memor...

How do you know they chose the wrong tool for the job without more context into the decision making process and important factors/constraints at the time?

by cle 6y ago

How do you know they chose the wrong tool for the job without more context into the decision making process and important factors/constraints at the time?

shmerl 6y ago

When you need to fight the garbage collector in a language that has one by design, it's a clear sign the wrong language was chosen, even if you'll find clever ways to fight it.

cle 6y ago
My point is that, even if that is true, there are many other factors that go into technical decisions than pure technical merits. These decisions happen in the context of a business, with existing systems, codebases, teams of people with different experiences and preferences, unique market dynamics, etc. To say "you used the wrong tool for the job" without considering the conditions under which that tool was chosen isn't a productive assertion.
- shmerl 6y ago
  I've heard such argument before, and it's often misused to justify the choice of the wrong tool in my opinion, because it's not based on objective technical reasons. So it's easy to use it with vague logic of "there are some business needs".
  - cle 6y ago
    Are you saying the non-technical reasons they considered weren’t valid? What were they?
    - shmerl 6y ago
      I'm saying this argument is often misused in practice.

scottlamb 6y ago

I peeked at the reddit conversation earthboundkid mentioned. [1] The author wrote there: > Go’s code readability, concurrency model, fast compilation, gofmt, go profiler, go vet, performance and so on. Also, we didn’t ditch Go GC entirely. We’re still using it pretty expansively in all non-critical paths and wherever it’s hard to trace the memory ownership and release. > I see this as a no different than taking some pieces of your code and converting them to assembly (utilize SIMD instructions, for e.g.), which Go does as well. Also, note that the workload that databases need to incur are lot heavier than typical Go applications. I don't think most of those are too satisfying as reasons to choose Go over Rust for this program. I think Go's code readability and safety are significantly compromised by this kind of manual memory management, enough so that I'd consider Rust more readable in this context. Likewise Rust's performance is significantly better—the biggest reason Go is faster to compile is that it has a simple compiler that does almost no optimizations. Rust can do that, too, in debug mode, especially with the recent cranelift backend. And Rust has equivalents to "go fmt" and "go vet". Now it's quite possible that when they started this program years ago, Rust wasn't a good choice. Obviously at least the cranelift backend I just mentioned didn't exist at the time. Pragmatically, you often end up with this kind of "path-dependent design" / "for legacy reasons". Porting is a lot of effort, maybe more than is worth it. You can't always be chasing the hot new fashion or you'd get nothing else done. I think it still should be acknowledged however that a better tool exists now. I agree with them the concurrency model in Go is genuinely more pleasant than in Rust. In Go, you just write synchronous code and it gets translated to a green thread model for you. In Rust, there's the async stuff which is harder to program and an async ecosystem that is still settling today. That's a clear advantage for Go, and maybe also why they say Go is more readable. (I find Rust otherwise pleasant to read.) And maybe Go is more reasonable for the non-critical path stuff as they said, and maybe that does have to be in the same program. [1] https://www.reddit.com/r/golang/comments/jobgq9/manual_memory_management_in_go_with_jemalloc/ https://www.reddit.com/r/golang/comments/jobgq9/manual_memor...