8 ms·

Go bills itself as simple, but Rust, despite it's complexity (which is hidden from you with libraries like serde and others) is simpler to use at the higher lev

Go bills itself as simple, but Rust, despite it's complexity (which is hidden from you with libraries like serde and others) is simpler to use at the higher level. Rust has a near-best-of-class type system, better abstractions, and runs on everything from embedded to the browser. Go has captured the hearts of sysadmin types and those looking for something just a step up from python (as evidenced by much of the devops code written in it -- which I'm very grateful for, I don't think I'd use kubernetes if it was in Java still), so I can see it growing in that field. I don't see how Rust doesn't become the most important emerging systems language (C & C++ obviously aren't going anywhere just by virtue of being incumbents) of the next decade.

throwaway894345 6y ago
Because building things quickly is important and Rust makes you think a lot about memory management. This is a fine thing for performance critical systems, but for systems where Python’s performance could be described as adequate, the extra performance Rust offers is immaterial. Of course, Rust gives you a bit more type safety than Go as well, but still not enough to justify trading off so much development velocity (or rather, type safety and correctness simply aren’t nearly as important as velocity from an economic perspective). Rust is getting better all the time—non-lexical lifetimes and rust-analyzer have provided a surprising improvement in development velocity, but Go is still in another class. Personally I think Go is the best language for developing quickly—even better than Python for non-toy projects (I say that as one with 15 years of Python experience and almost a decade of ago experience).
- praveenperera 6y ago
  I really don't think Rust MAKES you think a lot about memory management. You CAN think a lot about memory management if you care about performance. If not, you can throw `clone()` around everywhere and still have a very fast program.
  - throwaway89456 6y ago
    It is not because you can that you should.
  - skohan 6y ago
    In my experience, 98% of the time, I don't have to think much about memory management in Rust. The other 2% of the time I am untangling some kind of tricky, arcane situation.
- yawaramin 6y ago
  I believe OCaml is the best language for fast development. It's got a super-fast compiler (faster than Go's), better type system than both Rust and Go (of course aside from lifetime analysis), and its performance is quite impressive (described as within xN of C where N can be counted with the fingers of one hand).
  - hardwaresofton 6y ago
    I don't think any ML languages are going to be able to qualify for best language for fast development. They are a paradigm shift for too many developers, which means you're going to pay a price getting up to speed. Compilation time is generally not the bounding factor for development speed these days. Theoretically, compile time is zero for scripting languages so that's at least one point against weighing compile time heavily. I think the key benefit of OCaml and other ML langauges over Rust right now is actually higher kinded types, dependent types, and things in that realm of abstraction -- which you're probably not going to be using unless they're built into some library you're making use of, so the benefit is kinda moot there. Feels like the best power/weight for abstractions in codebases is the typeclass (or Traits in rust), most of the stuff above that is not great for fast development unless it's already in place. And if we're talking about ML languages, I'm firmly in the Haskell camp because I think it has a better ecosystem (more than any research language should), an incredibly good runtime system (they've got the best native+green thread implementation I've ever seen), and fantastic abstractions for working with shared memory (when you need that). The whole "if it compiles, it works" is generally true. No need for a holy war, but if OCaml is in the race for fast development (which means that ML is in the race), then I'd pick Haskell over it to start on ecosystem/adoption, production readiness and features -- if you can manage to keep your developers from climbing the ladder of research-level abstraction.
  - bbkane 6y ago
    I haven't tried it, but I've heard OCaml has a much smaller community (fewer libraries and general knowledge) and a lack of tooling and corporate sponsorship- I know Jane Street works with it and they have their own version of a stdlib.
    - 6y ago
- hardwaresofton 6y ago
  > Because building things quickly is important and Rust makes you think a lot about memory management. This is a fine thing for performance critical systems, but for systems where Python’s performance could be described as adequate, the extra performance Rust offers is immaterial. Of course, Rust gives you a bit more type safety than Go as well, but still not enough to justify trading off so much development velocity (or rather, type safety and correctness simply aren’t nearly as important as velocity from an economic perspective). I think this really depends on the the higher level abstraction you get to use in rust -- case in point being the original post. I'm not sure if this is a result of the rust code just being done that much later but the Rust in there is much simpler to read and understand than getting stated with a golang codebase (whether via kubebuilder, or others) outside of scaffolding your code base -- there's just less moving parts and less noise. Golang shines when it comes to developer fungibility -- it's simpler to onboard, train, and hire go developers. It's also easier for those developers to make mistakes, but compile type typechecking will constrict the mistake "space" (more so than ruby/python/vanilla js), and performance will get a boost. If Java is the mouse trap because C/C++ were too hard, Go is a better mouse trap on almost every axis (though I think generics in Go 2 are sorely needed). > Rust is getting better all the time—non-lexical lifetimes and rust-analyzer have provided a surprising improvement in development velocity, but Go is still in another class. Personally I think Go is the best language for developing quickly—even better than Python for non-toy projects (I say that as one with 15 years of Python experience and almost a decade of ago experience). I agree here, though I personally favor Typescript for building quickly (at least it is for me) if you add Typescript to it. Performance is great because most simple things are not CPU bound at the API layer, ecosystem is enormous (finding value can be difficult), and it's relatively easy to deploy (though Go is easier). I largely stopped keeping track of Go once I'd written some stuff in rust, but I do still recognize it as an excellent choice for building systems quickly and with some (type) protection as opposed to other options, with easy deploys. I'd love to get your thoughts on recent "modern" Python and it's shiny parts and warts though. I used it last year for a client and found the modern stack to still be pretty disappointing compared to what I knew was possible with server-side JS -- typing use being sort of incomplete still (mypy was a little awkward to use), async still being a little bit awkward, GIL still being a thing.
  - 6y ago
- felipellrocha 6y ago
  You're missing his point. Rust is simpler, so it's easier to use. The language is designed in a way that you don't really think about memory management unless you want to, and if you want to, it'll be pretty straight forward.
  - moldavi 6y ago
    Either Rust improved dramatically while I wasn't looking the last few days, or that's some of the most beautiful trolling I've ever seen. Someone needs to be congratulated, either way ;) I love Rust. It's like a beautiful puzzle that keeps my mind sharp and lets me make things that are truly elegant and performant. But the borrow checker is omnipresent, inescapable, and complexity-inducing... far from straightforward.
  - skohan 6y ago
    Rust has a lot of great qualities but simplicity is certainly not one of them.
  - pjmlp 6y ago
    Try to write a GUI application or a game engine, and enjoy how pretty straightforward the whole experience is all about.
- skohan 6y ago
  > type safety and correctness simply aren’t nearly as important as velocity from an economic perspective In my experience type safety is one of the most factors in terms of being able to produce code quickly, at least once a project grows beyond a couple hundred lines. I agree with your overall point, and I think the advantages of Go are especially relevant in a team setting: Go's categorical aversion to complexity makes it much more difficult to write code that someone else will not understand, where Rust projects can become relatively impenetrable when they wade too far into getting "clever" with the more esoteric aspects of the type system. Also the learning curve is real: you can take a Javascript developer and get them writing Go code in a couple of weeks. If you hire someone who's not experienced with Rust for a Rust project, you may be paying them for months just to get up to speed. Don't get me wrong, I'm a huge fan of Rust and use it for almost all of my personal projects currently. But I think the idea that Rust can become the main programming language in all settings comes from a place of heavy bias. Rust is definitely on one extreme when it comes to complexity, and it's a more relevant trade-off for some use-cases than others. aside - I know it's a minority opinion, but I actually think that Swift is a sweet-spot language in terms being simple to program in like Python (by aggressively obviating away low-level details), but giving you many of the powerful tools for correctness which Rust has, like algebraic types. It's a shame that it's painful to use in all but a few "blessed" applications.
  - throwaway894345 6y ago
    > In my experience type safety is one of the most factors in terms of being able to produce code quickly, at least once a project grows beyond a couple hundred lines. I think it depends on your domain. If you are working in a mission-critical space where every bit of static analysis saves hours or days of testing, then yeah, the more static analysis the better. If you’re building web systems software (things like Kubernetes) or even ordinary application software, then you get benefit from a little static analysis, but returns quickly diminish beyond a certain point. I think Go hits the sweet spot and Rust is generally excessive (development is slowed down much more than necessary). Swift might also hit that same sweet spot; I haven’t used it much. I have heard that it has some maturing to do before it’s ready for more than Apple GUI apps, but that might be dated information.
throwaway89456 6y ago
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.
Thaxll 6y ago
And yet reading some giant lib.rs is a bigger mess / un-readable than duplicated Go code. I think people gives too much credit to Rust sometimes. You give some Go and Rust code to some team that never used either language, I can tell you right away that the Rust code will never be properly understand. Go is easy to read and to maintain, I can't say the same for some Rust code. Go itself has been stable for years, there is no new keyword, std lib is the same, almost no changes ( beside modules ). When you look at Rust they're adding thing much faster and it feels like C++ at times, the mental overhead to keep up with that is not trivial.
- FridgeSeal 6y ago
  I will take a longer on-boarding in return for better long-term code any day of the week. I’ve been down the “developer speed above all else” rabbit hole with Python, and I don’t think it ever ended up working out meaningfully better than the “think the problem through first” approach. Personally I don’t find go easy to read: the noise of the “mechanics” of the implementation gets in the way of the intent behind the code in my opinion. Also the error handling is far inferior to the more principled approach taken by Rust/Haskell. > ...I can tell you right away that the Rust code will never be properly understand. I think this is an unfair characterisation: if I did this with my c#-writing coworkers, I think they’d certainly get a cursory understanding of Go quicker, but it wouldn’t take that much longer to get a grip on Rust and they’d write better and more correct code in Rust.
  - throwaway89456 6y ago
    The “developer speed above all else” mindset is driven by economics rather than technic. There are no reasons why one should not produce a good design in a any language. In the end it's a "people problem" most of the time. > Personally I don’t find go easy to read: the noise of the “mechanics” of the implementation gets in the way of the intent behind the code in my opinion I'd add another dimension: reading go is slower than reading Rust, but it's easy. Rust may be faster to read, but you can hit some very rough patch and serious head scratchers. It's all a trade-off at the end of the day.

throwaway894345 6y ago

Because building things quickly is important and Rust makes you think a lot about memory management. This is a fine thing for performance critical systems, but for systems where Python’s performance could be described as adequate, the extra performance Rust offers is immaterial. Of course, Rust gives you a bit more type safety than Go as well, but still not enough to justify trading off so much development velocity (or rather, type safety and correctness simply aren’t nearly as important as velocity from an economic perspective). Rust is getting better all the time—non-lexical lifetimes and rust-analyzer have provided a surprising improvement in development velocity, but Go is still in another class. Personally I think Go is the best language for developing quickly—even better than Python for non-toy projects (I say that as one with 15 years of Python experience and almost a decade of ago experience).

praveenperera 6y ago
I really don't think Rust MAKES you think a lot about memory management. You CAN think a lot about memory management if you care about performance. If not, you can throw `clone()` around everywhere and still have a very fast program.
- throwaway89456 6y ago
  It is not because you can that you should.
- skohan 6y ago
  In my experience, 98% of the time, I don't have to think much about memory management in Rust. The other 2% of the time I am untangling some kind of tricky, arcane situation.
yawaramin 6y ago
I believe OCaml is the best language for fast development. It's got a super-fast compiler (faster than Go's), better type system than both Rust and Go (of course aside from lifetime analysis), and its performance is quite impressive (described as within xN of C where N can be counted with the fingers of one hand).
- hardwaresofton 6y ago
  I don't think any ML languages are going to be able to qualify for best language for fast development. They are a paradigm shift for too many developers, which means you're going to pay a price getting up to speed. Compilation time is generally not the bounding factor for development speed these days. Theoretically, compile time is zero for scripting languages so that's at least one point against weighing compile time heavily. I think the key benefit of OCaml and other ML langauges over Rust right now is actually higher kinded types, dependent types, and things in that realm of abstraction -- which you're probably not going to be using unless they're built into some library you're making use of, so the benefit is kinda moot there. Feels like the best power/weight for abstractions in codebases is the typeclass (or Traits in rust), most of the stuff above that is not great for fast development unless it's already in place. And if we're talking about ML languages, I'm firmly in the Haskell camp because I think it has a better ecosystem (more than any research language should), an incredibly good runtime system (they've got the best native+green thread implementation I've ever seen), and fantastic abstractions for working with shared memory (when you need that). The whole "if it compiles, it works" is generally true. No need for a holy war, but if OCaml is in the race for fast development (which means that ML is in the race), then I'd pick Haskell over it to start on ecosystem/adoption, production readiness and features -- if you can manage to keep your developers from climbing the ladder of research-level abstraction.
- bbkane 6y ago
  I haven't tried it, but I've heard OCaml has a much smaller community (fewer libraries and general knowledge) and a lack of tooling and corporate sponsorship- I know Jane Street works with it and they have their own version of a stdlib.
  - 6y ago
hardwaresofton 6y ago
> Because building things quickly is important and Rust makes you think a lot about memory management. This is a fine thing for performance critical systems, but for systems where Python’s performance could be described as adequate, the extra performance Rust offers is immaterial. Of course, Rust gives you a bit more type safety than Go as well, but still not enough to justify trading off so much development velocity (or rather, type safety and correctness simply aren’t nearly as important as velocity from an economic perspective). I think this really depends on the the higher level abstraction you get to use in rust -- case in point being the original post. I'm not sure if this is a result of the rust code just being done that much later but the Rust in there is much simpler to read and understand than getting stated with a golang codebase (whether via kubebuilder, or others) outside of scaffolding your code base -- there's just less moving parts and less noise. Golang shines when it comes to developer fungibility -- it's simpler to onboard, train, and hire go developers. It's also easier for those developers to make mistakes, but compile type typechecking will constrict the mistake "space" (more so than ruby/python/vanilla js), and performance will get a boost. If Java is the mouse trap because C/C++ were too hard, Go is a better mouse trap on almost every axis (though I think generics in Go 2 are sorely needed). > Rust is getting better all the time—non-lexical lifetimes and rust-analyzer have provided a surprising improvement in development velocity, but Go is still in another class. Personally I think Go is the best language for developing quickly—even better than Python for non-toy projects (I say that as one with 15 years of Python experience and almost a decade of ago experience). I agree here, though I personally favor Typescript for building quickly (at least it is for me) if you add Typescript to it. Performance is great because most simple things are not CPU bound at the API layer, ecosystem is enormous (finding value can be difficult), and it's relatively easy to deploy (though Go is easier). I largely stopped keeping track of Go once I'd written some stuff in rust, but I do still recognize it as an excellent choice for building systems quickly and with some (type) protection as opposed to other options, with easy deploys. I'd love to get your thoughts on recent "modern" Python and it's shiny parts and warts though. I used it last year for a client and found the modern stack to still be pretty disappointing compared to what I knew was possible with server-side JS -- typing use being sort of incomplete still (mypy was a little awkward to use), async still being a little bit awkward, GIL still being a thing.
- 6y ago
felipellrocha 6y ago
You're missing his point. Rust is simpler, so it's easier to use. The language is designed in a way that you don't really think about memory management unless you want to, and if you want to, it'll be pretty straight forward.
- moldavi 6y ago
  Either Rust improved dramatically while I wasn't looking the last few days, or that's some of the most beautiful trolling I've ever seen. Someone needs to be congratulated, either way ;) I love Rust. It's like a beautiful puzzle that keeps my mind sharp and lets me make things that are truly elegant and performant. But the borrow checker is omnipresent, inescapable, and complexity-inducing... far from straightforward.
- skohan 6y ago
  Rust has a lot of great qualities but simplicity is certainly not one of them.
- pjmlp 6y ago
  Try to write a GUI application or a game engine, and enjoy how pretty straightforward the whole experience is all about.
skohan 6y ago
> type safety and correctness simply aren’t nearly as important as velocity from an economic perspective In my experience type safety is one of the most factors in terms of being able to produce code quickly, at least once a project grows beyond a couple hundred lines. I agree with your overall point, and I think the advantages of Go are especially relevant in a team setting: Go's categorical aversion to complexity makes it much more difficult to write code that someone else will not understand, where Rust projects can become relatively impenetrable when they wade too far into getting "clever" with the more esoteric aspects of the type system. Also the learning curve is real: you can take a Javascript developer and get them writing Go code in a couple of weeks. If you hire someone who's not experienced with Rust for a Rust project, you may be paying them for months just to get up to speed. Don't get me wrong, I'm a huge fan of Rust and use it for almost all of my personal projects currently. But I think the idea that Rust can become the main programming language in all settings comes from a place of heavy bias. Rust is definitely on one extreme when it comes to complexity, and it's a more relevant trade-off for some use-cases than others. aside - I know it's a minority opinion, but I actually think that Swift is a sweet-spot language in terms being simple to program in like Python (by aggressively obviating away low-level details), but giving you many of the powerful tools for correctness which Rust has, like algebraic types. It's a shame that it's painful to use in all but a few "blessed" applications.
- throwaway894345 6y ago
  > In my experience type safety is one of the most factors in terms of being able to produce code quickly, at least once a project grows beyond a couple hundred lines. I think it depends on your domain. If you are working in a mission-critical space where every bit of static analysis saves hours or days of testing, then yeah, the more static analysis the better. If you’re building web systems software (things like Kubernetes) or even ordinary application software, then you get benefit from a little static analysis, but returns quickly diminish beyond a certain point. I think Go hits the sweet spot and Rust is generally excessive (development is slowed down much more than necessary). Swift might also hit that same sweet spot; I haven’t used it much. I have heard that it has some maturing to do before it’s ready for more than Apple GUI apps, but that might be dated information.

throwaway89456 6y ago

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.

Thaxll 6y ago

And yet reading some giant lib.rs is a bigger mess / un-readable than duplicated Go code. I think people gives too much credit to Rust sometimes. You give some Go and Rust code to some team that never used either language, I can tell you right away that the Rust code will never be properly understand. Go is easy to read and to maintain, I can't say the same for some Rust code. Go itself has been stable for years, there is no new keyword, std lib is the same, almost no changes ( beside modules ). When you look at Rust they're adding thing much faster and it feels like C++ at times, the mental overhead to keep up with that is not trivial.

FridgeSeal 6y ago
I will take a longer on-boarding in return for better long-term code any day of the week. I’ve been down the “developer speed above all else” rabbit hole with Python, and I don’t think it ever ended up working out meaningfully better than the “think the problem through first” approach. Personally I don’t find go easy to read: the noise of the “mechanics” of the implementation gets in the way of the intent behind the code in my opinion. Also the error handling is far inferior to the more principled approach taken by Rust/Haskell. > ...I can tell you right away that the Rust code will never be properly understand. I think this is an unfair characterisation: if I did this with my c#-writing coworkers, I think they’d certainly get a cursory understanding of Go quicker, but it wouldn’t take that much longer to get a grip on Rust and they’d write better and more correct code in Rust.
- throwaway89456 6y ago
  The “developer speed above all else” mindset is driven by economics rather than technic. There are no reasons why one should not produce a good design in a any language. In the end it's a "people problem" most of the time. > Personally I don’t find go easy to read: the noise of the “mechanics” of the implementation gets in the way of the intent behind the code in my opinion I'd add another dimension: reading go is slower than reading Rust, but it's easy. Rust may be faster to read, but you can hit some very rough patch and serious head scratchers. It's all a trade-off at the end of the day.