3 ms·

> 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, b

> 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.

throwaway894345 6y ago
> 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. I think people over-index on abstraction, especially in a professional setting. I think humans have a harder time understanding abstractions than they do in dealing with concrete problems, and I think Rust (and many other languages) encourage us toward the most abstract code we can conceive of whether or not that abstraction is actually necessary. And not only are people bad at understanding abstractions, but making good abstractions is a skill, and I’ve seen way too many bad abstractions created when no abstractions are necessary at all. On the other hand, sometimes abstraction really is necessary or helpful (and contrary to Go’s critics, these cases are not to elide error handling boilerplate or to facilitate generic map functions or other “hyper-localized-abstractions”) and in these cases Go can be quite painful. > 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. My opinion is that using Python these days is painting yourself into a corner. Developers need more rails to keep them from writing shitty code and Mypy isn’t yet mature enough (and its pace of development seems glacial). Further the package management is still worst-in-class. I’ve never worked on a Python project that didn’t hit some major performance bottleneck that the Go/.Net/Java tier of languages wouldn’t have struggled with at all, and unlike that tier of languages, Python leaves you with no better options. Async makes a lot of applications faster, but it also allows for some pernicious bugs (“Guess Who Is Blocking The Event Loop And Bringing The Whole Application Down!” is not a fun game to play even with Python’s tooling). It’s particularly unpleasant if you don’t have a type checker because you’ll find yourself forgetting “await” a lot even in the kind of code that you would think is so simple that it doesn’t need tests. Mostly I think we have better options these days—my go-to is Go (pun unintended) but I’ve heard good things about TypeScript as well. If you really need Python for some data science stuff or something else, I would try to contain that bit as much as possible by making it its own tiny microservice or calling into it as a sub process call or similar. I would not write more than necessary in Python.

throwaway894345 6y ago

> 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. I think people over-index on abstraction, especially in a professional setting. I think humans have a harder time understanding abstractions than they do in dealing with concrete problems, and I think Rust (and many other languages) encourage us toward the most abstract code we can conceive of whether or not that abstraction is actually necessary. And not only are people bad at understanding abstractions, but making good abstractions is a skill, and I’ve seen way too many bad abstractions created when no abstractions are necessary at all. On the other hand, sometimes abstraction really is necessary or helpful (and contrary to Go’s critics, these cases are not to elide error handling boilerplate or to facilitate generic map functions or other “hyper-localized-abstractions”) and in these cases Go can be quite painful. > 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. My opinion is that using Python these days is painting yourself into a corner. Developers need more rails to keep them from writing shitty code and Mypy isn’t yet mature enough (and its pace of development seems glacial). Further the package management is still worst-in-class. I’ve never worked on a Python project that didn’t hit some major performance bottleneck that the Go/.Net/Java tier of languages wouldn’t have struggled with at all, and unlike that tier of languages, Python leaves you with no better options. Async makes a lot of applications faster, but it also allows for some pernicious bugs (“Guess Who Is Blocking The Event Loop And Bringing The Whole Application Down!” is not a fun game to play even with Python’s tooling). It’s particularly unpleasant if you don’t have a type checker because you’ll find yourself forgetting “await” a lot even in the kind of code that you would think is so simple that it doesn’t need tests. Mostly I think we have better options these days—my go-to is Go (pun unintended) but I’ve heard good things about TypeScript as well. If you really need Python for some data science stuff or something else, I would try to contain that bit as much as possible by making it its own tiny microservice or calling into it as a sub process call or similar. I would not write more than necessary in Python.