1. 29

  2. 15

    Part of the struggle for us adopting something like rust internally is the syntax is too complex.

    Even the “hello world” example:

    fn main() {
        println!("hello world")

    Involves understanding what a macro is vs. a normal function call. The cognitive overhead of the language is a huge barrier and something we’ve eschewed for golang.

    1. 20

      I hear you; we strive to not make Rust more complex than it has to be; unfortunately, the job it’s attempting to do is inherently complicated. A big focus of this year was on lowering the learning curve; it hasn’t all landed yet though.

      That said, I’d hope that this particular example isn’t the biggest barrier, it boils down to “macros have a ! at the end.” In my ~five years with Rust, I’ve written exactly two macros, and they were less than 5 lines, and I mostly copy/paste/tweak’d them. They’re so minor we are even putting them in an appendix of the book, rather than giving them their own chapter.

      That said, use the tools that work for you! Rust isn’t for everyone, and that’s 100% okay.

      1. 4

        As I said above I think really good libraries will help a lot with this, but in a sense @bigdubs is saying what I was trying to say but more eloquently. I look forward to seeing the results of all the awesome work the Rust community is doing to ease the onboarding experience and smooth out the learning curve.

      2. 4

        Sorry to be kinda pendantic, but it’s wrong to say that for the hello world example, rust is more complicated than other languages such as golang which you mentioned. Compare the two:

        package main // What's a package?
        import "fmt" // Why do I need to import something to print to the screen?
        func main() {
            fmt.Println("hello world") // Why do I need to prefix this with fmt? Why is Println capitalized?

        To be fair I’ve never coded in rust and absolutely love coding in go for its simplicity and functionality, but your example doesn’t make a good comparison

        1. 2

          you can use println in golang w/o the prefix / package name.

          in action here: https://play.golang.org/p/y5XX4RDTW5

          further what you’re nitting is “what is a package” which is a feature of the language you will have to explore countless times, vs. macros which as steve said are a niche feature of the rust language.

          there is still plenty of magic with golang though. the thing that tripped me up personally at first was lower case letters on structs == package private, which is a weird isolation level to begin with but even then the only thing that governs the protection is the first letter of a name.

          1. 1

            As an aside, according to the golang spec, one should not rely on println. “These functions are documented for completeness but are not guaranteed to stay in the language”

      3. 10

        I wanted to shout-out https://conduit.io/ here, but didn’t know when this was coming out relative to Conduit’s release.

        1. 10

          I love Rust and I know this is gonna get the whole “Python is boring. STFU” crowd down on me, but I’m honestly not sure that Rust’s level of abstraction is ideal for the vast majority of devops tasks. Sure there are plenty of performance intensive cases where Rust could really shine, but I think languages like Python and Go (which I have the same abstraction issue with FWIW but it’s at least a bit higher up the stack AFAICT) may retain the advantage for a while at least until a set of very solid libraries to perform common tasks become mature and stable.

          1. 7

            I definitely agree that often, working at a higher level of abstraction can be more useful. One of the things that I love about Rust is that it doens’t have to be either/or; for example, the new Conduit tool uses Rust at its core, but with Go layered on top.

            https://www.reddit.com/r/programming/comments/7hx3lk/the_rise_of_rust_in_devops/dqut2cl/ is an interesting thread developing where some people are talking about why they would or wouldn’t choose Rust here; I think there’s many viable answers!

            1. 3

              Surely there’s some middle ground between Rust’s “we’re going to use a language designed to minimize runtime costs for a task that is inherently IO-bound” and Python/Go’s “we’re going to basically throw out types”.

              1. 2

                What about something like mypy ?

              2. 2

                Can you say more about in what ways you feel rust is too low in the stack compared to Python? One reason I like Rust a lot is I can easily make great higher level abstractions in my programs, and still retain the safety around types and borrowing. I’ve been bitten too many times with bad concurrency implemented in “simple devops scripts” to want to return to that world.

                1. 5

                  I think if you’re doing concurrency then traditional very high level procedural languages like Ruby and Python are a very poor choice.

                  In concurrent applications, any of the abstraction complaints I might have with Rust fade away because you MUST think about things like memory allocation and structure in the concurrent problem space.

                  This is the danger in (my) speaking in generalities. In my 25 years of doing infrastructure work, I have yet to encounter a problem that truly demands a solution involving concurrency. I recognize that this is merely anecdotal evidence, but be that as it may, I prefer to work in languages that handle the details of memory allocation for me, because in every use case I’ve thus far encountered, that level of performance is Good Enough.

                  That said, a couple of examples of aspects of Rust I would feel are in the way for the kind of work I mostly need to do:

                  • Pointers and dererencing / destructuring
                  • The ownership and borrowing memory model

                  I am not a Rust expert, but I read and worked through the entire Rust book 1.0 a couple of years back, which left me with a deep abiding respect for the power of Rust. I just don’t feel that it’s suited to the kinds of work I do on a day to day basis.

                  1. 1

                    In my 25 years of doing infrastructure work, I have yet to encounter a problem that truly demands a solution involving concurrency.

                    I have, though I’ve generally still used python to handle it (the multiprocessing standard library is super-handy). My use cases have been simple, though. All of them can boil down to: process a big list of things individually, but in parallel, and make sure the result gets logged. No need for memory sharing, just use a queue (or even split the list into X input files for X processes).

                    That said, I don’t think rust would be a bad language to handle those problems. In fact, python might have been a terrible one. Just wanted to say that even workloads that require concurrency often end up very simple.