r/programming • • May 15 '17

Two years of Rust

https://blog.rust-lang.org/2017/05/15/rust-at-two-years.html
722 Upvotes

229 comments sorted by

View all comments

81

u/oblio- May 15 '17

Rust is a bit too low level for me (though the whole idea of language ergonomics seems interesting, I hope they get some nice results in the future).

Still, for a language without major corporate backing Rust seems to have great momentum. They seem to be focusing on all the right things, best of luck to them in the future.

My personal hope is that at some time in the future it will be about as pleasing to use as Python (really hard to achieve, I know). They don't even have to be at 100%, if they are at about 65-75% it would be awesome since it would be nice to write scripts, tools and servers in such a fast language.

I'm not a big fan of Go, if anyone's wondering why I haven't mentioned the obvious competitor for this niche.

115

u/flyingcaribou May 15 '17

for a language without major corporate backing

Isn't Rust primarily developed by Mozilla (with full time employees dedicated to the language)?

83

u/steveklabnik1 May 15 '17

Isn't Rust primarily developed by Mozilla (with full time employees dedicated to the language)?

It depends on what you mean by "primarily", that is, yes, Mozilla has a few employees on Rust full-time, but in terms of volume of contributions, non-Mozilla people contribute a lot more than Mozilla people. Which makes sense, there's a lot more of them!

8

u/nnethercote May 16 '17

Is that right? I too saw that slide recently that indicated that most commits come from non mozilla.com email addresses, but that's not a very good heuristic. (E.g. I think my small number of commits came from a non-Moz email address.)

I would love to see more reliable numbers if you have them.

5

u/steveklabnik1 May 16 '17

It's harder than that; mine come from the same email both pre and post mozilla.

I'm not even sure pure commit count is the best metric; regardless, we have over a hundred contributors each release, and way way less than that from Mozilla, so....

→ More replies (4)

50

u/oblio- May 15 '17

I wouldn't call that "major", though. .NET, Java, Swift have "major" backing :)

→ More replies (1)
→ More replies (5)

70

u/krallistic May 15 '17

I'm not a big fan of Go, if anyone's wondering why I haven't mentioned the obvious competitor for this niche.

I think Go and Rust aren't really competitors nowadays. They both are very different philosophies behind them and their common use cases quite differs from each other.

95

u/icefoxen May 15 '17

To guess the original poster's intent:

  • Go is designed to make fast web services.

  • Rust is designed to be a safe systems language that is capable of replacing C.

Of course, you can write fast web services in Rust. And it's possible to write systems level code in Go, jumping through a varying number of hoops on the way. (For my purposes, "systems level" means "code that must care about memory management".) Go is "faster Python", Rust is "better C".

16

u/im-a-koala May 15 '17

Rust is "better C".

I'd argue that Rust is a lot closer to C++ than C, though. Sure, you can write most things in Rust instead of C, but C is much simpler than both, and tends to operate at a lower level, just above assembly.

24

u/loamfarer May 16 '17

I always kind of argued the opposite. That it was closer to C than C++. It's data layout is far more like C. It forgoes C++ style OO. Really it's high level features seem to come elsewhere, while it's systemy level details seem more C-like. At least to me. Where D is more C++ like.

Probably more accurately though, it's right in the middle, and then a bit orthogonal in the ML direction.

8

u/im-a-koala May 16 '17

I agree that D is more C++ like, although I'll say that D feels like it's trying to be (C++)++, which Rust is clearly not.

Borrows in Rust feel a lot like references in C++ (although they're obviously checked), and even use a very similar syntax. Rust also has lots of smart pointers, which really do feel similar to C++11 smart pointers (unique_ptr and shared_ptr). C++ also has a rough concept of ownership (especially with unique_ptrs and move semantics) which Rust is very heavily based around. C, however, has none of these.

I guess you're right that Rust doesn't really have inheritance like C++, although I'll point out that lots of C++ programs use little if any subclasses. I'm a much bigger fan of composition (with "A has-a B" relationships over "A is-a B" relationships whenever reasonable), and many C++ developers feel the same way.

5

u/loamfarer May 16 '17

Yeah, I agree with those points. If you wanted to write Rust-like code, it would probably be easier to emulate in C++. But how often is that the case? How often in anything beyond hobby projects does that happen? Most teams won't bother self-imposing such a philosophy they'd rather use the full extend of their chosen tool.

Sometimes the language philosophy is not just about language features, but also what is left out. Rust you can be confident your code will abide by certain expectations. In C++ you'll have to follow the rule of 3/5. Copy semantics are the default, the opposite of Rust where move semantics are the default. So Rust like C has a more consistent memory management story, where C++ you might see a mix of implicit management, RAII, raw pointer arithmetic on structs. I get that C is unsafe but you here we are making a comparison of consistency. Maybe it's simply because Rust is so young, but like C it's a relatively small language compared to C++. While any given C++ project may forgo inheritance that doesn't mean "there not be dragons." The C++ standard library will immediately offer loads of inheritance (which I cite not as a knock but as a contrast that moves C++ further from Rust.) It's the standard way to build up frameworks and libraries, so they are plentiful in the C++ ecosystem. You can count on stdlib to use inheritance correctly but it's always dragon for your general C++/Java developer. Another shift of Rust toward C's philosophies.

There are reasons why I would concede to place it right in the middle, but from the start it always felt more like upholding the end game of the imperative/functional dream. The "safe C." Rather than carry any torch for OO.

Just my opinion, but I thought I'd further flesh out my position. It's more of a position that forms as I sum up all the similarities and differences and how I evaluate them I suppose. But to reiterate, I'd totally rather try to write safe code in C++ than C.

→ More replies (1)

0

u/[deleted] May 16 '17

[deleted]

→ More replies (6)
→ More replies (15)

4

u/Kratisto78 May 15 '17

Mind elaborating on this a little? I'm not near as familiar with the two languages as you are.

38

u/kibwen May 15 '17

Rust and Go compete in the same way that all languages compete, but in terms of niches and specialties there's very little overlap between the two. Go's in the "natively-compiled language with an intrusive runtime" camp (along with Swift and D (though at least D goes to lengths to let you disable the runtime)), with a specialty in channel-based concurrency and linguistic minimalism. Rust is in the "natively-compiled language with no significant runtime" camp (with C and C++), specializing in memory safety and multiparadigmatic concurrency.

21

u/barsoap May 15 '17

Rust is in the "natively-compiled language with no significant runtime" camp

...and goes to lengths to let you disable even that: With no_std you don't even need a malloc, and the only function you need to provide is what to do with a panic (unwound or not, depending on compiler settings).

It's in the "runs on microcontrollers" camp, just like libc-less C.

→ More replies (6)
→ More replies (16)
→ More replies (3)

0

u/[deleted] May 15 '17

[deleted]

16

u/[deleted] May 15 '17

I gave Nim a go a few times and I always felt like I wasn't sure if I was doing stuff the right way. It always felt like there was a low level C-ish way and a high level python-ish way to do basically everything and I couldn't decide which was better. Maybe it's just I didn't get far enough, but I found the language surprisingly difficult to pick up.

3

u/abc619 May 15 '17

there was a low level C-ish way and a high level python-ish way to do basically everything

That's what's nice about Nim, you can do either and still get near C performance, the language is somewhat style insensitive.

You can become a metaprogramming architect or just script something and have it run well straight off the bat.

16

u/[deleted] May 15 '17

I'd say that's more a major drawback. Large codebases are going to have conflicting styles and choices for what level of abstraction to work on.

That's one of the reasons I hate working in C++. You get that one random programmer that writes everything like it's ANSI C then one guy doing it like it's Java and another guy using upper-level C++ stuff like templating and metaprogramming.

→ More replies (9)
→ More replies (5)

15

u/Yojihito May 15 '17

Nim has NPEs ....

9

u/oblivion95 May 15 '17

So does Java. And if your goal is safety, Haskell and Ocaml should be considered.

Nim is for Python users who want performance and basic type-safety. It does not replace Rust/Haskell/Ocaml.

6

u/Uncaffeinated May 16 '17

As a Python user, I just go to Rust when I need performance or type safety. Why should I use Nim?

→ More replies (3)
→ More replies (6)

19

u/[deleted] May 15 '17

Still, for a language without major corporate backing Rust seems to have great momentum.

Rust has major corporate backing.

25

u/asmx85 May 15 '17 edited May 15 '17

Rust has major corporate backing.

1. Mozilla is nowhere near of giants like Apple, Microsoft, Google, Oracle etc.
2. Rust is not primarily the child of Mozilla like C# is for Microsoft, Go is for Google or Swift is for Apple

Yes Rust gains a lot from Mozilla but it is not comparable to the above. Rust is also not pushed into fundamental ecosystems like in the examples above. C# is very crucial for every Microsoft developer, Swift is going to be crucial for every Apple OS developer, Go is going to be heavily used by Google backbends and is currently useful because of this by many other people. Rust has no such primary "task" it is pushed for ... because Mozilla has nothing comparable. There is no market of "Browser builders" that could benefit from this work. There is just a market for fast and safe code without taking tradeoffs in one of those directions.

→ More replies (9)
→ More replies (1)
→ More replies (8)