4 ms·

Rust complexity is not encapsulated in libraries that parses JSON or YAML, or others. Rust complexity is embedded in the following: in order to get something t

Rust complexity is not encapsulated in libraries that parses JSON or YAML, or others. Rust complexity is embedded in the following: in order to get something to work, you effectively need to solve a puzzle. Solving the puzzle is fun and feels very good once completed, and the prize is definitely worth it when performance and safety are critical. I highly doubt that "solving the puzzle" makes sense in the context of ad-hoc automation or boring sysadmin/devops stuff. Last time I checked, creating a static binary (a-la go) was not easy. It may sound stupid... but at the end of the day go is the king of pragmatism. I think exactly the opposite though about systems languages: Rust should take over C and C++.

throwaway894345 6y ago
Even with respect to dealing with JSON, good luck deserializing a structure with borrowed references. People will tell you not to use borrowed references, but sometimes you’re at the mercy of a library author and even if you’re not it kind of sucks to have to do a big refactor across your codebase to replace borrowed fields with owned fields, right after you got everything working just because you can’t figure out how to deserialize properly and no one else appears to know how either. This is one of many problems that make Rust more difficult and time consuming in practice than Go which doesn’t distinguish between owned and borrowed. Of course this borrow checker gives you a lot more thread safety than Go provides, but I write a lot less parallel code than code that must be deserialized (or any of the other areas where pernicious borrow-checker issues creep in). Rust improves quickly so I don’t think we should discount it, but I wish Rust folks would address these concerns when talking about how Rust is going to take over $x domain.
- throwaway89456 6y ago
  > it kind of sucks to have to do a big refactor across your codebase to replace borrowed fields with owned fields Some refactorings in Rust has brought back memories of refactoring struggles with highly coupled code bases, where one seemingly small change ends up requiring touching many many areas of the code. The omniscient need to define ownership across a code base seems to make it easy to introduce high coupling, which is unavoidable unless you start using shared_ptr/RC all over the place.
felipellrocha 6y ago
> Last time I checked, creating a static binary (a-la go) was not easy When was the last time you checked?
- throwaway89456 6y ago
  Today, go produces static binary by default, not Rust.
  - bombela 6y ago
    By default, Go dynamically link to libc on Linux if you use networking. I believe because of a dependency on nss. I recall it's truly static on MacOS though.

throwaway894345 6y ago

Even with respect to dealing with JSON, good luck deserializing a structure with borrowed references. People will tell you not to use borrowed references, but sometimes you’re at the mercy of a library author and even if you’re not it kind of sucks to have to do a big refactor across your codebase to replace borrowed fields with owned fields, right after you got everything working just because you can’t figure out how to deserialize properly and no one else appears to know how either. This is one of many problems that make Rust more difficult and time consuming in practice than Go which doesn’t distinguish between owned and borrowed. Of course this borrow checker gives you a lot more thread safety than Go provides, but I write a lot less parallel code than code that must be deserialized (or any of the other areas where pernicious borrow-checker issues creep in). Rust improves quickly so I don’t think we should discount it, but I wish Rust folks would address these concerns when talking about how Rust is going to take over $x domain.

throwaway89456 6y ago
> it kind of sucks to have to do a big refactor across your codebase to replace borrowed fields with owned fields Some refactorings in Rust has brought back memories of refactoring struggles with highly coupled code bases, where one seemingly small change ends up requiring touching many many areas of the code. The omniscient need to define ownership across a code base seems to make it easy to introduce high coupling, which is unavoidable unless you start using shared_ptr/RC all over the place.

felipellrocha 6y ago

> Last time I checked, creating a static binary (a-la go) was not easy When was the last time you checked?

throwaway89456 6y ago
Today, go produces static binary by default, not Rust.
- bombela 6y ago
  By default, Go dynamically link to libc on Linux if you use networking. I believe because of a dependency on nss. I recall it's truly static on MacOS though.