1. 34

tedu made a good point about the Rust community that got me thinking about things we can collectively do to improve how we represent ourselves and Rust. This post is a collection of thoughts on the issue that hopefully will spur some discussion within the Rust community, but whose arguments I believe are more broadly applicable to tech evangelism.

  1.  

  2. 15

    Scattered thoughts:

    I think “killing” C and C++ is a noble goal. How many buffer overflow exploits does our industry have to deal with before we collectively say enough is enough? Before Rust there wasn’t a good language that fit the C family niche, but now there is. That being said, I doubt Rust will be able to “kill” them off–I’m just saying it isn’t a bad thing to want to.

    I’m surprised you do not mention garbage collection here. There have been many times where I’ve seen Rust newbies sucked into the hype (it’s as ergonomic as Python and Ruby!) and then felt tricked/disappointed because manually dealing with object lifetimes is a pain. Overall I don’t mind the hype, as I think Rust is a language that should be widely adopted, but sometimes I think that when the topic of GC comes up “hype” quickly turns into “misinformation.”

    Maybe the complexity of dealing with Rust’s safety guarantees isn’t worthwhile for the domain

    I think this misses the point. The “complexity” comes from the additional bookkeeping necessary to support GC-less operation. Your reward for managing the complexity is improved performance, not safety. I know the Rust team likes to say the borrow checker also enables safe concurrency but this is a stretch–there are “safe” higher-level concurrency patterns that can be used without having ownership in the type system, such as transactional memory. Or, in other words, once again the point of the ownership system is performance, not safety.

    We don’t need to tear them down for Rust to succeed. In fact doing so only makes success harder.

    I think it is good to be candid about what Rust offers over other languages. You don’t need to be rude about it, but that’s generally applicable advice.

    1. 11

      I agree with pretty much all of this, except I would like to say that I really do think Rust is trying to replace (“kill” is an ugly word) C++. That is not to say that C++ is the enemy or that it isn’t more appropriate for a wide variety of circumstances, but in the very long run I see Rust directly competing with C++. It certainly was designed for that purpose specifically in the context of Servo - to replace C++ because C++ was inappropriate for their constraints. And the FFI and C compatibility make it uniquely positioned to be an incremental replacement as well.

      1. 9

        I agree that Rust is probably going to displace C++ in a number of areas, and definitely compete in others. My point was simply that this relationship doesn’t need to be antagonistic. Whatever language people choose, we’re all interested in making quality software that accomplishes its goals while reducing maintenance and security headaches during its life cycle. There’s no need for animus.

      2. 5

        Well said.

        1. 5

          I hope every programming language community takes these points to heart.

          1. 4

            This is well put.

            1. 3

              I’m glad you like it! Thanks for your initial comments about your perception of the Rust community. Problems like this can’t be addressed if people don’t point them out.

            2. 3

              A problem that you face is that it’s an open community, so you can’t stop people from “representing Rust” who either have repulsive personalities or who are all-around nitwits. For example, belittling and demeaning other programming languages is a good thing – if it’s useful information, and not banal or ignorantly wrong, as some fanboys tend to be. Ultimately it’s on other people to recognize that the sharks can’t control the remoras, it’s on them to make technical decisions based on technical merits.

              Also, this blog post slips (edit: I only mean slightly) into an anti-intellectual mindset by stating things that are flat-out false and pretending they are true (edit: that might be taking things a bit dramatically). Because Rust is trying to kill C and C++, to the extent that means something. And other people are, in fact, wrong for making certain technical decisions. It’s so convenient to fall into a mindset where nobody ever has to be wrong! Unfortunately, that’s not how reality is. Between any two choices, one is going to be better than the other. And in making decisions, you’re best off with both positive and negative information about both. The thing is, nobody needs you to tell them how C++ is bad. But they might benefit from being told ways in which D or Nim is bad.

              1. 6

                Technical decisions can be wrong, but “I can’t believe they’re not using rust!” is a poor way to communicate that one understands the design constraints on a solution.

                1. 4

                  I absolutely agree with the first point. It’s an unavoidable difficulty of open communities. The best we can do is hope to set a consistent example within the core of the community, and hope that example is followed by newcomers.

                  I’m surprised to hear you think the claims about killing other languages are anti-intellectual. As tedu’s already commented, there’s a difference between attacking another language as being wrong (and its users ethically wrong to use it) and encouraging people to try your language based on technical arguments. We should never do the first. We should always try for the second.

                  1. 3

                    If you really think Rust isn’t trying to, and cannot, kill C or C++, as you said, then that’s not anti-intellectual of you. But right after that, can other people really never be wrong for choosing something that isn’t Rust? If it is possible to give an “honest assessment” and say that Rust is the best choice, that means it’d be wrong to go with something else. That doesn’t mean anybody has to be an insufferable fanboy about it.

                    Now there, I’m afraid, I might be acting the blowhard over a wisp of rhetorical flourish, but regarding belittling and demeaning other programming languages, I don’t think so. How do you make “technical arguments” without attacking other languages? For example, thanks to what you might call “attacks,” I learned that a good reason not to use Nim is (or was) because of buggy concurrency and a compile-via-C implementation that put C’s undefined behavior bugs into the compiler. A reason not to use D is because it has a buggy compiler. And I’d attack C++ by saying C++’s implicit conversions are bad and should be avoided. The Nim example is one that people later whined about, as if Rust people shouldn’t share information they have about Nim. It is useful to me as a third-party to hear these things. It is impossible to make a technical argument that says X is better than Y, without saying Y is worse than X.

                    1. 4

                      It is impossible to make a technical argument that says X is better than Y, without saying Y is worse than X.

                      Ah, but you choose which side of that coin you say.

                  2. 3

                    Between any two choices, one is going to be better than the other.

                    That’s not always true. It can depend of what goals you’re trying to achieve.

                    1. 1

                      I strongly agree with your first point, its true for almost every technology these days.

                    2. 2

                      I think there’s a general trend, most likely due to social media and other things, for folks to be very vocal about their tools. This is particularly annoying with the JS community, but I’ve seen it with Ruby and Scala and Go–at least the Haskell folks seem to at least kinda understand that they’re weirdos so they don’t always offer it as a suggestion for whatever problem I’m talking about. I haven’t noticed it at all with Erlang (mostly because there aren’t a lot of those devs and they’re too busy to goof around on Twitter or wherever), Java, Elixir (though that’ll happen as more Rails folks adopt Phoenix), PHP, or whatever.

                      It’s like there’s two types of developers today: people busy building applications, and people chasing shiny. I am noticing that the people in the second category are more vocal: I suspect this is because they are genuinely excited to share their findings with others.

                      Unfortunately, with Rust, this manifests as hearing Rust as a solution to any problem. Talking about threading stuff? Rust. Looking at implementing an API for native stuff? Rust. Complaining about slow performance? Rust. Worse, a lot of the people suggesting this don’t know much about the language at all–they’re just parroting what they’ve heard other folks say.

                      It’s like that old joke about being on a date with a really self-absorbed person: “Well, that’s enough me talking about Rust. What do you think about Rust?”

                      1. -1

                        There have been many languages in the past who claimed of themselves to be the future “C killer”. If you look at the TIOBE-index, you can still see that C is doing pretty well. If Rust goes beyond 1% usage, we can talk again. Until that, the aggressive and arrogant mindset of the Rust community is very off-putting to say the least.

                        I bet my cards on Go. It’s actually readable, has a simple language specification and the community behind it is friendly and open. The only reason why I am not using it (yet) is because they still need to bring down the binary size reasonably.

                        Static linking by default is a big plus though! Don’t underestimate this factor unless you’ve already done a software-rollout across many multiple systems.

                        In regard to C: You can write horrible software in any language. With the right carefulness and using good data-structures, you can actually write safe code. It’s not C’s fault that OpenSSL is such a horrible mess.

                        1. 4

                          Go and C aren’t similar languages, and therefore I wouldn’t consider Go and Rust competitors. The fact that Rust can easily run freestanding is proof enough of this.

                          In regard to C: You can write horrible software in any language. With the right carefulness and using good data-structures, you can actually write safe code.

                          This isn’t an argument for preferring one language to another, it is just a way for one to rationalize their investment in C. You hear the same thing from the PHP crowd.

                          1. -2

                            I respect your opinion in this regard, but Go and C are definitely similar languages. One design goal of Go actually was to provide a C-like syntax. This argument alone honestly cannot make me respect the words following what you said.

                            It’s a joke you compare PHP and C. It’s common sense that an ability to create proper data structures is a core aspect of a language. PHP doesn’t give you nearly the same functionality and power.

                            1. 7

                              Syntactical similarity is not a good measure of semantical similarity, which is what most people (myself incl.) mean by “similarity.” That Go looks like C has little to do with how each language works, and for what tasks it is useful for. Go simply isn’t suited for the kind of low-level programming that has historically been C’s domain, such as:

                              • embedded programming, which requires precise control of time and space, disqualifying all GC’s except the (rare) real-time ones

                              • developing system libraries, which generally requires a runtime-less language, since these libraries will be linked into languages without runtimes or languages with different runtimes

                              • developing operating systems, unless you are from the Lisp language-as-OS school (but even then Go isn’t good at loading Go code dynamically into a process)

                              • developing language runtimes, which requires precise control of memory

                              FWIW Rust happens to be suitable for these tasks, which is why people compare it to C. Rust also happens to be memory safe by default, which is why people hope that it will kill C.

                              It’s a joke you compare PHP and C. It’s common sense that an ability to create proper data structures is a core aspect of a language. PHP doesn’t give you nearly the same functionality and power.

                              That’s irrelevant to my point.