13 ms·

The DB space for Rust is a bit young, though there are several good projects like sqlx making it much more pleasant. Rust shares many of the benefits of Go: -

• rob74 5y ago
  > When I compare my Rust and Go code, the Rust code ends up being much smaller (LoC) and much more dense/terse. Yes, but is it more readable too? The obfuscated C contest also tends to produce a lot of dense/terse code, but you probably wouldn't want to use that in a production system...
  • cjg 5y ago
    In my experience, Rust code is relatively easy to read, even by developers with no Rust experience. Of course, you can write hard to read code. But that's not typically what comes out of a process of writing production software. That's not to say that someone with no experience will fully understand the ownership transfer & borrowing that's happening, but that's just stuff you need to do for the compiler. Reading code that already compiles, you can mostly ignore that and focus on the program logic.
    • cogman10 5y ago
      Yeah, readability is high, it's writing that can be a bit harder IMO. Especially for someone unfamiliar with rust, it can be hard to really know why someone is using self, &self, or &mut self. Yet the code reads the same. That's the funny thing about rust.
      • zozbot234 5y ago
        The compiler is supposed to tell you when you get it wrong. This does leave design issues on the table, but it's also good for those to be addressed explicitly, by the more senior people on the project.
    • Thaxll 5y ago
      Rust is one the hardest language to read. Take two people that never used Go or Rust and make them read code, good luck with Rust.
      • timeon 5y ago
        So I have opened golang.org: v1, ok1 := <-c1 Not sure what is difference between := and = and what is that arrow. But if I'm going to do something with the language - I guess it will be easy to find out. Like with Rust.
        • rob74 5y ago
• foobarbazetc 5y ago
  I personally prefer Rust to Go for things that have hard resource requirements/limits, but there’s no denying that Go is much easier to program than Rust. You don’t need to know much more than Python/Ruby to get something done in Go, whereas Rust needs a C++ or Scala or Haskell or whatever background. Rust places too much mental workload on a programmer to make the compiler happy. The Go compiler is much more human friendly. Swift is a nice mix of all worlds, IMHO. Would be nice to see that get more server-side use. At our Scala-centric company, Go gets used a lot more for one off tasks and microservices. We rebuilt one Go service in Rust just to get familiar with it and no one has written more Rust since.
  • Cyph0n 5y ago
    Can you expand on “needs a C++ or Scala or Haskell background”? C++ would probably help you appreciate what Rust brings to the table, but I don’t see how any of them fit in when learning to use Rust in practice.
    • steveklabnik 5y ago
      One way of looking at Rust is that it is kinda at the intersection of three different language families: {Ruby,Python,JavaScript} x {C,C++} x {OCaml, Haskell, Scala} “Needs” is a bit strong but “may find some things familiar and therefore easier” is a common refrain.
      • Cyph0n 5y ago
        That makes more sense. I'd probably phrase it as: "if you are familiar with a lower-level language and a functional language, you'll likely have an easier time learning Rust".
        • steveklabnik 5y ago
          Yup, I’d agree with that.
    • ibraheemdev 5y ago
• Thaxll 5y ago
  "good concurrency" Async rust is very messy and a pretty big issue atm. The tooling on the IDE side is subpar compared to Go.
  • cjg 5y ago
    I'd be interested in hearing what you think is a problem in async Rust.
    • Xevi 5y ago
      I'm not the one you responded to, and I haven't used Rust much myself, but one of the issues I've seen raised several times is that its async ecosystem is fractured. You have to select an async stack, and sometimes different libraries and frameworks use competing stacks, causing problems. It's not like JavaScript or Go where everything is just built into the language afaik.
      • lstamour 5y ago
        There’s been a decent amount of standardization on top of Tokio’s implementation of async (green threads). If a library didn’t support it at first, they probably now do using features in your project.toml requirements.[1][2] That said, I agree the standard library isn’t the size or utility of Go’s nor is the ecosystem as wide as Go or npm. Personally, I’m looking forward to the next few years when more and more companies reveal what patterns they use with Rust development. I think Rust is missing the kind of boost that Rails gave Ruby, for example, or that TypeScript and React gave Node/SSR. Or that Pandas gave Python. 1. https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#choosing-features https://doc.rust-lang.org/cargo/reference/specifying-depende... 2. https://doc.rust-lang.org/cargo/reference/features.html#dependency-features https://doc.rust-lang.org/cargo/reference/features.html#depe...
  • jkelleyrtp 5y ago
    To write custom futures? Yes, you need to understand Pin and some advanced stuff. To use? Eh - I just turn on async_std with the Tokio flag and write go-like code with async tasks. No issues thus far.
• pqb 5y ago
  Your reply has piqued my attention, because as a person who develops in Go (and in other programming languages) I cannot put any > or < between Rust and Go - they are clearly tools dedicated for other type of applications. I won't try to play as a Go devil advocate, because I don't feel good enough today to start such discussion. What is the worst thing I have experienced in Rust? Lack of good packages, especially if we speak about cloud stuff (rusoto and google-api-rs). Human resources put from cloud providers are very scarce. As longer I dived into the Rust the more I felt I am alone freak, because I had to work more hours to achieve the same result as in Go, PHP, Kotlin, TypeScript, C#. My use case of Rust was a GraphQL gateway (gRPC+HTTP) and after few weeks of idea verification the project was dropped. Mostly because instead of developing business logic the team was focused to implement own libraries for Google Cloud and other SaaS offerings on their own. Ridiculous, but Mozilla devs [0] went the same way by taking the whole job on their shoulders and they were generating subsets of APIs, because they cannot find any good, official libraries. It is frustrating and time consuming making Rust completely no-go for many teams. > I've worked a decent amount with Go, but I'm also frustrated with the size of projects balloon. When I compare my Rust and Go code, the Rust code ends up being much smaller (LoC) and much more dense/terse. I can exactly the same about the Rust. I think it was not the problem with tool but with something between chair and keyboard. I had a pleasure to see and refactor very bad Go code and actual ballooning was never a case if you have applied Clean / Solid architecture. The "ballooning" was actual something nice, because anyone in the team could pick the repository and take care of implementing new business logic. The number of lines of code is quite bad metric for Golang, because famous "if err != nil" takes a nasty 3 lines, while in many languages you can write it using single liner. In my humble experience, the number of lines of most Go web apps can be often compared to TypeScript apps. Also many web apps that I have developed usually had hefty 2-5k LoC and it is not bad result if we consider C# or Java web apps. > - Powerful hygienic and non-hygienic macros Yeah, having marcros in Rust is a gem. > - Builtin benchmarking Same as in Go. See testing.B. It is weird you have pointed out > - Builtin documentation Same as in Go. See godoc. > - FFI with Swift, C, C++, Node, etc to share code everywhere. I rarely see the case for FFI in web app - I don't imagine even using it like that. It was common case for chart, TeX document or other web to image rendering to embed some library. I think it is a bad approach and the best currently is just run that code as separate binary, because it helps in maintainability of a third party dependency and your devops teams will love that decision. As a person who rewrote the rxi/lite [1] to Rust I can only say I am terrified how many times I had to sacrifice having unsafe calls to just use some C code in my Rust application. > - Crates.io is like NPM - really discoverable and easy to upload (with its goods and bads) Personally, I feel Go/Deno/Docker flow of the installing dependencies is more convenient. I don't project names that do not sound what they provide. Naming thing is bad and I often see many developers are scratching head to find some unique name, so it could be easier findable in NPM or other repository. They are wasting time at looking for something short and funny and not something that is easily discoverable. For many years, my only way of looking for dependency is GitHub. It helps to verify and investigate the quality of the code before adopting it in the application. It sometimes also results in contributing back to the project, because I already know where the project is located. > - Really good project management through modules/Cargo.toml It is really complex I'd say. But Cargo.rs would be nice to have :P > - Generics make Map/Reduce/Filter really easy and readable Matter of time in Go. :) > - Serde is fantastic at automatically serializing/deserializing datastructures Oh, that's true. Go has numerous serializers (for only JSON there are about 20+ nice looking implementations) and it is still interesting to see new ones, especially because they bring many non-obvious optimizations. Kotlin serializer is also top notch thingy. I recommend to use protobufs types in Go - even for domain models. It is interesting how with Go2 can improve the situation. > - Very pleasant logging and tracing The log package is nice, together with macro log! is really pleasant to look at it how concise it is to fill some context parameters around the message. I think it is like Logrus in Go, except the syntax it has the same features. There is also Zap package that sacrifices readability for performance. There is no problem to embed number of line of code, calling function in Go logs either. Tracing? Yep, it feels the same for both languages I think. I had used OpenTracing (Jaeger) and I hardly can say I miss something from one or other language. Maybe some macro/annotation wrapper that will be added on compile time? However, I rarely see any use case right now for complicating such thing like tracing. > - Like, really really good error handling, esp compared to Go Hey, it is not that bad! :D But well, as long as you use Goland you don't care about the if-err-non-nil. If you switch for few days to Java-world you will be like in hell after developing in Go, because the error-over-exception flow is really helpful to provide code that does not have any kind of error and you, as a developer, can guess what happens in specific line without any println("1") or debugger. Monads are nice but I will not trade current if-err for them. > - builtin testing framework AFAIK all modern programming languages includes some testing framework: Kotlin (kotlin.test), Zig (std.test), Elixir (ExUnit) etc. I am glad both Rust and Go joined that club. > If you're looking into using Rust for web, I recommend https://github.com/http-rs/tide https://github.com/http-rs/tide - it's the most pleasant web framework I've ever used. It is interesting, but I think even today there is nothing that I could label as a "framework" in Go world. You wisely choose the best packages matching your needs. The situation has improved with many libraries providing a GraphQL endpoint. > I've worked a decent amount with Go Reading your post, made me think you don't have good Go experience and it sounded bad IMHO. I guess you had nobody proficient enough in production-ready Go apps to evangelize it within the team or there was no reason to use Go (yep, it is not a perfect tool). ;) [0]: https://github.com/mozilla-services/syncstorage-rs https://github.com/mozilla-services/syncstorage-rs [1]: https://github.com/rxi/lite https://github.com/rxi/lite