11 ms·

Three months of Rust

244 points by abecedarius 11y ago

voltagex_ 11y ago
Coming from C#, that syntax looks completely alien to me. I need to write a very small monitoring app to run on a tiny armel box so I may try Go. I will still miss Visual Studio's debugger, though.
- d4rkph1b3r 11y ago
  Go is shit. Trust me, Rust will suit you better. Coming from C# it will be a lot closer to what you're used to than the bizzaro-world of Go.
  - ryenus 11y ago
    I'm not against you, but to convince, you need to tell why, why the sh*t? why to trust you?
    - lectrick 11y ago
      Lack of a runtime exception model would be one huge thing. So you basically have to check for errors after every operation, and whatever errors you don't check for just... get lost.
  - arthursilva 11y ago
    Nonsense, go is fine, so is rust.
    - andrewchambers 11y ago
      Both are really great. I think Go is better for servers and rust can be great on embedded and high performance applications.
      - arthursilva 11y ago
        The truth is that rust is in its infancy its all guesses at this point. Go didn't attract c++ people as people first guessed.
        bsder 11y ago
        I saw them talking about that, but it's completely obvious. Nobody today is running C/C++ unless they need either A) complete speed or B) bare metal. Go can't do either, so there was going to be very little transfer from C/C++ to Go.
        prewett 11y ago
        C++ is still mostly what I use, but I need neither speed nor bare metal. Maybe add C) people doing UI and applications? There aren't many other good options: Java: UI looks terrible; it's annoying living in Noun-land when CPUs are, if anything, more about verbs than nouns; and running properly on Windows is not trivial. C#: Up until recently, not cross-platform unless you're ok with Mono. (But, might be worth looking in to now) Python: great for scripts and experiments. The lack of static typing is a real problem when working with code other people wrote. Also, UI is not a strong point. Go: what UI libraries? (I'm sure they exist) Objective-C: even on iOS/Mac-only projects, I still prefer C++, because it's so much easier to use STL objects than NS data structures. C++: you can pretty much get it done, and often you can use Qt to get it done quickly and cross-platformy. I'm hoping Rust will be the C++ I always wanted.
        kibwen 11y ago
        Most GUI toolkits for Rust are in their infancy, but I hear that Gnome will be working on integrating Rust with GObject this year, which should allow Rust to leverage Gtk: https://wiki.gnome.org/GUADEC/2015/BOFs/Rust https://wiki.gnome.org/GUADEC/2015/BOFs/Rust Some preliminary work towards this: https://github.com/gi-rust/glib-sys https://github.com/gi-rust/glib-sys
        11y ago
  - voltagex_ 11y ago
    I need more info than that.
- Ruud-v-A 11y ago
  When I tried to write my first program in Rust, I failed miserably. With a strong background in C# as well, I tried to write a function that returns an interface (a trait in Rust), which was apparently not something you do in Rust. (With an unboxed trait that is, but there are some proposals to add support for this.) The compiler diagnostics have improved tremendously since then. I don’t think the syntax is that much different. You use `let` instead of `var` and types go after the argument instead of before. After some time I got the hang of it, and I am sure you can do it too. It is surprising how much I _didn’t_ miss the Visual Studio debugger. The VS debugger is amazing and in my opinion there is no debugger that comes close, but Rust has a much higher “if it compiles it works”-factor than C#. There are still times where I wish for a debugger like that of Visual Studio, but this is relatively rare. Instead of spending time debugging, you spend your time staring at compiler errors in denial until you eventually accept that the compiler is right and your code is wrong.
  - voltagex_ 11y ago
    Apparently Visual Rust [1] is a thing now. VS2015 will support GDB as a debugger, too (!) [1]: https://github.com/PistonDevelopers/VisualRust https://github.com/PistonDevelopers/VisualRust
d4rkph1b3r 11y ago
Great to see some feedback on Rust, I've only played a bit but was quite impressed, dsepite being a mostly high level programmer. However, it sounds like Eve is a simple, dynamically typed programming language/environment. So it's super weird to me to see him rave about the safety and type system of Rust...
- jamii 11y ago
  Right tool for the job. Static typing works well for systems software. Eve is aimed at scripting / knowledge work, where you are mostly manipulating collections of messy data and it's useful to be able to start with a loosely specified program and only nail it down with types once it settles down. Imagine a relational database where you can vary between setting every column to Any and not caring about relationships, or strictly typing everything and adding integrity constraints all over the place.
andrewchambers 11y ago
"For our 2400 loc it takes 20s for a dev build and 70s for a release build. " I have played with rust, but not written any large amounts of code. This makes me a bit sad though, I have 7000 lines of go which takes less than a second. I think there is a bunch of bloat in software compilation which the plan9/Go people were wise to stamp out. Compare gcc/clang/rustc build times from source with building go 1.5 from source which bootstraps itself. It comes down to something like 20 minutes vs 20 seconds.
- pcwalton 11y ago
  The advantage, of course, is that LLVM has probably over a hundred man-years of optimizations in it, including two IRs (SSA LLVM IR, SelectionDAG), tons of target-specific optimizations (ScheduleDAG, Machine-level optimizations), great tooling (e.g. DWARF support, Address/Thread Sanitizer), and lots of community support. None of it is bloat as far as Rust is concerned. I optimize bare-metal Rust code nearly every day and if I had to spend time fixing suboptimal codegen due to missing optimization passes in the compiler I'd never get my job done. Especially since I work on ARM, where bad codegen punishes you hard. There's certainly a lot of room for improvement in Rust's build times, but LLVM was completely indispensable for the language to get off the ground, and I don't regret using it for a minute.
  - andrewchambers 11y ago
    What would benchmarking say the slowest part of rustc is? Typechecking/semantic analysis, llvm, or something else. LLVM is a great innovation when it comes to making new languages from scratch, High performance will hopefully be one of rusts strong points, so its good to have so many companies working on llvm performance for free.
    - mbrubeck 11y ago
      The slowest part is LLVM. (You can pass "-Z time-passes" to rustc to get detailed timing info.) This isn't just an "LLVM is slow" problem, though. It's also a "rustc generates extremely verbose LLVM IR" problem. Optimizing the IR before it gets to LLVM is part of the plan for solving it.
jwmerrill 11y ago
"Modern machines are a huge pile of opaque and unreliable heuristics and the current trend is to add more and more layers on top. The vast majority of systems are built this way and it is by all accounts a successful strategy. That doesn’t mean I have to like it." This is a really valuable observation. "Smart" compilers seem great for letting you write code without thinking too hard when performance requirements are loose, but they make it difficult to achieve peak performance in two ways: 1. The fact that details of the machine are abstracted away from you means that you may never learn them well. 2. It ends up being insufficient just to know the details of the machine, because you also need to know how to coax the compiler into producing the low level result that you want, and then you need to be vigilant that later changes to the compiler don't break your assumptions.
- pron 11y ago
  I think the opposite is true. Modern hardware is so complex[1], made even more so by its constant interaction with a complex OS, that any sense of familiarity with the actual performance model is illusory, unless you're doing something very controlled and very specific (like, say, DSP). Modern hardware itself is an abstraction, hiding its operation away from you. We can no longer hope to tame hardware with meticulous control over instructions as we were able to up until the nineties. Forget about clever compilers; forget even about smart JITs; even if you look at such a big abstraction as GCs and only consider large pauses (say anything over a few tens of milliseconds), it is now the case that in a well-tuned application using good a GC, most large pauses aren't even due to GC, but to the OS stopping your program to perform some bookkeeping. Careful control over the instruction stream doesn't even let you avoid 100ms pauses, let alone trying to control nanosecond level effects. [1]: http://www.infoq.com/presentations/click-crash-course-modern-hardware http://www.infoq.com/presentations/click-crash-course-modern...
  - dly 11y ago
    And yet I consistently find that checksum tools, compression libraries, and things like video decoders (such as H264 decoders) written in assembly consistently outperform all other implementations I've had to deal with. "Sufficiently smart compiler" is a tired meme at this point. There are few programs that benefit from being entirely written in assembly, but quite a lot who do having parts of them hand optimized. Some, like game emulators, particularly one man job like No$GBA, are still fully written in assembly and its performance is a sight to behold. No$GBA would lose a lot if it were rewritten into a high level language.
glandium 11y ago
The take-away for me is this: "Despite the restrictions of the type system, I am more productive in Rust than I am in either Javascript or Haskell. It manages somehow to hit a sweet spot between safety and ease of use." When I toyed with Rust last year (so, I'll admit my knowledge is outdated, I need to refresh it), I had a pleasant experience on the productivity side. The big reward for me, coming from C/C++, is that my programs simply worked as expected once I was past fixing all the errors the compiler reported. That usually doesn't happen this way in C/C++, where you spend additional time fixing whatever null deref and whatnot that break your program in subtle ways at runtime.
- shmerl 11y ago
  Doesn't using C++ RAII eliminate some of that? Or you use raw pointers often?
  - steveklabnik 11y ago
    Rust uses RAII too. But borrowing makes it much more powerful.
    - shmerl 11y ago
      Yeah, Rust controls much more than C++ RAII does.
  - the_why_of_y 11y ago
    Anything in C++ generally comes with its very own footgun. The one for RAII looks like this: { mutex_guard(some_mutex); foo(); } What does this do? It locks some_mutex, then immediately unlocks it, then calls foo().
    - kluge 11y ago
      I don't understand the example. Why would it do that and not unlock after foo()?
Manishearth 11y ago
> The Rust community seems to be populated entirely by human beings. :D <3 Regarding your borrow checker example, note that your code is now prone to blowing up if `step` is modified too much. You have created the necessity of an invariant (step should not pop out of the vector) which may be broken by later cleverness. See http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ http://manishearth.github.io/blog/2015/05/17/the-problem-wit... for more details. Note that in this specific case you could just use `&str` over `&String` everywhere and push "some new thing" directly; `&String` is a double-pointer, whereas &str is a fat pointer. > Nor am I totally sure what the tradeoffs are between having a self argument and not. It's not a tradeoff thing; it's a "do I want a static method, or a member method" thing. > Some kinds of constraints cannot be used in where clauses, so I believe the former is strictly more powerful. Actually where clauses are much more powerful. With the type constraints stuff like `A: Foo` works but not `Vec<A>: Foo`, but the latter is allowed in where clauses. Overall, loved reading this post! It identified some areas of diagnostics that we can try to improve (I'm very interested in fixing diagnostics), and is a pretty accurate picture of the language :)
- jamii 11y ago
  > Note that in this specific case you could just use `&str` over `&String` everywhere It's an awkwardly construed example. Here is the actual code - https://gist.github.com/jamii/ae46e8e0c9757330e9ea https://gist.github.com/jamii/ae46e8e0c9757330e9ea . There the borrow makes more sense since the value is being created by calling a function on the current solver state. I've edited the post to include a solution that was suggested in the reddit discussion - replace &'a Value with Cow<'a, Value>. > It's not a tradeoff thing; it's a "do I want a static method, or a member method" thing. > Actually where clauses are much more powerful. I really don't understand this part of the language yet, but... I linked to an active rfc about constraints that cannot currently be expressed in where clauses (https://github.com/rust-lang/rfcs/blob/master/text/0135-where.md https://github.com/rust-lang/rfcs/blob/master/text/0135-wher...), including the example you gave. In cases where a function takes two arguments it isn't always obvious which argument should be self. If that affects whether constraints end up being A: Foo<B> or B: Foo<A> or `where Foo<A,B>` it seems like one could run up against those limitations?
vph 11y ago
A Rust programmer can't seem to be Rusty. The more he's Rusty, the more he knows about it, which seems like a contradiction.
tatterdemalion 11y ago
This is a super interesting read! Having come into Rust from an experience with mostly object-oriented languages (Python, Java, C++), what you seem to have taken for granted, I found surprising and new, and what you are surprised by (such as self parameters), I found quite normal. It's great to see the other side of this.
- jamii 11y ago
  I've actually written a ton of python too. The self parameter didn't confuse me because of OO, but because traits can actually dispatch on the types of all of their arguments so it wasn't clear to me what the meaning of the self argument was and how much it should affect my design. Manishearth cleared up most of my confusion - it affects namespacing and auto-borrow but doesn't interact with constraints. Traits are very similar to typeclasses and I was just thrown by the surface level syntax.
cpp098 11y ago
New languages always are trap. Programmers always waste too much time on new languages or some tricky language syntax. They should focus on the business. I will never try Rust.
- crazypyro 11y ago
  Why can't you practice Rust in a non-business environment?
  - cpp098 11y ago
    Programmers always spend too much time on studying which hammer is better, but they forget what they really want to do, right?
    - insulanian 11y ago
      I agree there is some truth in what you're saying. However, without programmer's curiosity and desire to create new interesting and beautiful languages, we would still be "focused on business" and writing code in COBOL, Fortran, C, Pascal...
    - AlisdairO 11y ago
      I agree with you generally -for me, given that I already know java well, it's clearly not worth the effort to spend much time on (say) Go. I make an exception here, because I think Rust has genuinely useful new ideas brought to the table.
    - b0b_d0e 11y ago
      I don't think that was the case for me at least. I felt like (using your own analogy) the more I studied Rust, the better I learned how to use every other hammer. Learning a new programming language helped me learn c++ better since I was constantly on the lookout for potential memory leaks and other common pitfalls that Rust prevents. Now when I code in c++, I always try to write the code with safety in mind.
    - Retra 11y ago
cassandranot 11y ago
I wasted three months on rust then got sober, and went back to c++, then life was good!
- outworlder 11y ago
  Are you performing a social experiment to see how low your karma can get?
- getsat 11y ago
  I ported a project to Rust and then ported it to C++14 (which is awesome!), but I only did that because Rust was in a state of massive flux at the time and I got tired of the project breaking every two days due to changes to the compiler/syntax/stdlib. I plan to reevaluate Rust once it's settled down a bit.
phren0logy 11y ago
The Eve language is an offshoot of what started as LightTable, which was heavily focused on Clojure/Clojurescript. Interesting that Clojurescript was not the language of choice here, both given the roots of that project and the reputation of lisps for being languages to write other languages. I wonder if the team would be willing to comment on why they are moving away from Clojurescript?
- jamii 11y ago
  Writing a language runtime in javascript is hard enough, clojurescript adds yet more layers of runtime overhead that we have to work around. Clojurescript is a fine applications language, but it's not a good systems language. Most languages aren't.
halosghost 11y ago
+1, at the very least, because of the nod to Terra. Terra, imho, feels a lot like the perfect middle-ground between Lua and Rust. It has a clean syntax with some handy/fancy features but keeps a simple static typing system that makes me feel comfortable. Also, nice to read a review of Rust that didn't reduce to “C is the worst evar!” or “Haskell makes no sense!”. Reasoned and clearcut. I certainly disagree with various parts of the review, but I don't do any dev for webservices so it is unsurprising that the author and I have a differing of opinion.
- jamii 11y ago
  I would be interested to hear which parts you disagree with. > I don't do any dev for webservices so it is unsurprising that the author and I have a differing of opinion I don't either, I'm working on a database / language runtime. It happens to have a html interface rather than a console interface, but the majority of the work is very far away from normal web-dev :) > Terra, imho, feels a lot like the perfect middle-ground between Lua and Rust In particular, I really like the idea that the Terra type-system is just Lua code, so you can have different kinds of static analysis in different places instead of one-type-system-to-rule-them-all. Of course, it's a totally unproven idea at this point so it's hard to say how that would turn out in a real project.

244 points by abecedarius 11y ago

Coming from C#, that syntax looks completely alien to me. I need to write a very small monitoring app to run on a tiny armel box so I may try Go. I will still miss Visual Studio's debugger, though.

d4rkph1b3r 11y ago
Go is shit. Trust me, Rust will suit you better. Coming from C# it will be a lot closer to what you're used to than the bizzaro-world of Go.
- ryenus 11y ago
  I'm not against you, but to convince, you need to tell why, why the sh*t? why to trust you?
  - lectrick 11y ago
    Lack of a runtime exception model would be one huge thing. So you basically have to check for errors after every operation, and whatever errors you don't check for just... get lost.
- arthursilva 11y ago
  Nonsense, go is fine, so is rust.
  - andrewchambers 11y ago
    Both are really great. I think Go is better for servers and rust can be great on embedded and high performance applications.
    - arthursilva 11y ago
      The truth is that rust is in its infancy its all guesses at this point. Go didn't attract c++ people as people first guessed.
      - bsder 11y ago
        I saw them talking about that, but it's completely obvious. Nobody today is running C/C++ unless they need either A) complete speed or B) bare metal. Go can't do either, so there was going to be very little transfer from C/C++ to Go.
        prewett 11y ago
        C++ is still mostly what I use, but I need neither speed nor bare metal. Maybe add C) people doing UI and applications? There aren't many other good options: Java: UI looks terrible; it's annoying living in Noun-land when CPUs are, if anything, more about verbs than nouns; and running properly on Windows is not trivial. C#: Up until recently, not cross-platform unless you're ok with Mono. (But, might be worth looking in to now) Python: great for scripts and experiments. The lack of static typing is a real problem when working with code other people wrote. Also, UI is not a strong point. Go: what UI libraries? (I'm sure they exist) Objective-C: even on iOS/Mac-only projects, I still prefer C++, because it's so much easier to use STL objects than NS data structures. C++: you can pretty much get it done, and often you can use Qt to get it done quickly and cross-platformy. I'm hoping Rust will be the C++ I always wanted.
        kibwen 11y ago
        Most GUI toolkits for Rust are in their infancy, but I hear that Gnome will be working on integrating Rust with GObject this year, which should allow Rust to leverage Gtk: https://wiki.gnome.org/GUADEC/2015/BOFs/Rust https://wiki.gnome.org/GUADEC/2015/BOFs/Rust Some preliminary work towards this: https://github.com/gi-rust/glib-sys https://github.com/gi-rust/glib-sys
        11y ago
- voltagex_ 11y ago
  I need more info than that.
Ruud-v-A 11y ago
When I tried to write my first program in Rust, I failed miserably. With a strong background in C# as well, I tried to write a function that returns an interface (a trait in Rust), which was apparently not something you do in Rust. (With an unboxed trait that is, but there are some proposals to add support for this.) The compiler diagnostics have improved tremendously since then. I don’t think the syntax is that much different. You use `let` instead of `var` and types go after the argument instead of before. After some time I got the hang of it, and I am sure you can do it too. It is surprising how much I _didn’t_ miss the Visual Studio debugger. The VS debugger is amazing and in my opinion there is no debugger that comes close, but Rust has a much higher “if it compiles it works”-factor than C#. There are still times where I wish for a debugger like that of Visual Studio, but this is relatively rare. Instead of spending time debugging, you spend your time staring at compiler errors in denial until you eventually accept that the compiler is right and your code is wrong.
- voltagex_ 11y ago
  Apparently Visual Rust [1] is a thing now. VS2015 will support GDB as a debugger, too (!) [1]: https://github.com/PistonDevelopers/VisualRust https://github.com/PistonDevelopers/VisualRust

d4rkph1b3r 11y ago

Great to see some feedback on Rust, I've only played a bit but was quite impressed, dsepite being a mostly high level programmer. However, it sounds like Eve is a simple, dynamically typed programming language/environment. So it's super weird to me to see him rave about the safety and type system of Rust...

jamii 11y ago
Right tool for the job. Static typing works well for systems software. Eve is aimed at scripting / knowledge work, where you are mostly manipulating collections of messy data and it's useful to be able to start with a loosely specified program and only nail it down with types once it settles down. Imagine a relational database where you can vary between setting every column to Any and not caring about relationships, or strictly typing everything and adding integrity constraints all over the place.

andrewchambers 11y ago

"For our 2400 loc it takes 20s for a dev build and 70s for a release build. " I have played with rust, but not written any large amounts of code. This makes me a bit sad though, I have 7000 lines of go which takes less than a second. I think there is a bunch of bloat in software compilation which the plan9/Go people were wise to stamp out. Compare gcc/clang/rustc build times from source with building go 1.5 from source which bootstraps itself. It comes down to something like 20 minutes vs 20 seconds.

pcwalton 11y ago
The advantage, of course, is that LLVM has probably over a hundred man-years of optimizations in it, including two IRs (SSA LLVM IR, SelectionDAG), tons of target-specific optimizations (ScheduleDAG, Machine-level optimizations), great tooling (e.g. DWARF support, Address/Thread Sanitizer), and lots of community support. None of it is bloat as far as Rust is concerned. I optimize bare-metal Rust code nearly every day and if I had to spend time fixing suboptimal codegen due to missing optimization passes in the compiler I'd never get my job done. Especially since I work on ARM, where bad codegen punishes you hard. There's certainly a lot of room for improvement in Rust's build times, but LLVM was completely indispensable for the language to get off the ground, and I don't regret using it for a minute.
- andrewchambers 11y ago
  What would benchmarking say the slowest part of rustc is? Typechecking/semantic analysis, llvm, or something else. LLVM is a great innovation when it comes to making new languages from scratch, High performance will hopefully be one of rusts strong points, so its good to have so many companies working on llvm performance for free.
  - mbrubeck 11y ago
    The slowest part is LLVM. (You can pass "-Z time-passes" to rustc to get detailed timing info.) This isn't just an "LLVM is slow" problem, though. It's also a "rustc generates extremely verbose LLVM IR" problem. Optimizing the IR before it gets to LLVM is part of the plan for solving it.

jwmerrill 11y ago

"Modern machines are a huge pile of opaque and unreliable heuristics and the current trend is to add more and more layers on top. The vast majority of systems are built this way and it is by all accounts a successful strategy. That doesn’t mean I have to like it." This is a really valuable observation. "Smart" compilers seem great for letting you write code without thinking too hard when performance requirements are loose, but they make it difficult to achieve peak performance in two ways: 1. The fact that details of the machine are abstracted away from you means that you may never learn them well. 2. It ends up being insufficient just to know the details of the machine, because you also need to know how to coax the compiler into producing the low level result that you want, and then you need to be vigilant that later changes to the compiler don't break your assumptions.

pron 11y ago
I think the opposite is true. Modern hardware is so complex[1], made even more so by its constant interaction with a complex OS, that any sense of familiarity with the actual performance model is illusory, unless you're doing something very controlled and very specific (like, say, DSP). Modern hardware itself is an abstraction, hiding its operation away from you. We can no longer hope to tame hardware with meticulous control over instructions as we were able to up until the nineties. Forget about clever compilers; forget even about smart JITs; even if you look at such a big abstraction as GCs and only consider large pauses (say anything over a few tens of milliseconds), it is now the case that in a well-tuned application using good a GC, most large pauses aren't even due to GC, but to the OS stopping your program to perform some bookkeeping. Careful control over the instruction stream doesn't even let you avoid 100ms pauses, let alone trying to control nanosecond level effects. [1]: http://www.infoq.com/presentations/click-crash-course-modern-hardware http://www.infoq.com/presentations/click-crash-course-modern...
- dly 11y ago
  And yet I consistently find that checksum tools, compression libraries, and things like video decoders (such as H264 decoders) written in assembly consistently outperform all other implementations I've had to deal with. "Sufficiently smart compiler" is a tired meme at this point. There are few programs that benefit from being entirely written in assembly, but quite a lot who do having parts of them hand optimized. Some, like game emulators, particularly one man job like No$GBA, are still fully written in assembly and its performance is a sight to behold. No$GBA would lose a lot if it were rewritten into a high level language.

glandium 11y ago

The take-away for me is this: "Despite the restrictions of the type system, I am more productive in Rust than I am in either Javascript or Haskell. It manages somehow to hit a sweet spot between safety and ease of use." When I toyed with Rust last year (so, I'll admit my knowledge is outdated, I need to refresh it), I had a pleasant experience on the productivity side. The big reward for me, coming from C/C++, is that my programs simply worked as expected once I was past fixing all the errors the compiler reported. That usually doesn't happen this way in C/C++, where you spend additional time fixing whatever null deref and whatnot that break your program in subtle ways at runtime.

shmerl 11y ago
Doesn't using C++ RAII eliminate some of that? Or you use raw pointers often?
- steveklabnik 11y ago
  Rust uses RAII too. But borrowing makes it much more powerful.
  - shmerl 11y ago
    Yeah, Rust controls much more than C++ RAII does.
- the_why_of_y 11y ago
  Anything in C++ generally comes with its very own footgun. The one for RAII looks like this: { mutex_guard(some_mutex); foo(); } What does this do? It locks some_mutex, then immediately unlocks it, then calls foo().
  - kluge 11y ago
    I don't understand the example. Why would it do that and not unlock after foo()?

Manishearth 11y ago

> The Rust community seems to be populated entirely by human beings. :D <3 Regarding your borrow checker example, note that your code is now prone to blowing up if `step` is modified too much. You have created the necessity of an invariant (step should not pop out of the vector) which may be broken by later cleverness. See http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ http://manishearth.github.io/blog/2015/05/17/the-problem-wit... for more details. Note that in this specific case you could just use `&str` over `&String` everywhere and push "some new thing" directly; `&String` is a double-pointer, whereas &str is a fat pointer. > Nor am I totally sure what the tradeoffs are between having a self argument and not. It's not a tradeoff thing; it's a "do I want a static method, or a member method" thing. > Some kinds of constraints cannot be used in where clauses, so I believe the former is strictly more powerful. Actually where clauses are much more powerful. With the type constraints stuff like `A: Foo` works but not `Vec<A>: Foo`, but the latter is allowed in where clauses. Overall, loved reading this post! It identified some areas of diagnostics that we can try to improve (I'm very interested in fixing diagnostics), and is a pretty accurate picture of the language :)

jamii 11y ago
> Note that in this specific case you could just use `&str` over `&String` everywhere It's an awkwardly construed example. Here is the actual code - https://gist.github.com/jamii/ae46e8e0c9757330e9ea https://gist.github.com/jamii/ae46e8e0c9757330e9ea . There the borrow makes more sense since the value is being created by calling a function on the current solver state. I've edited the post to include a solution that was suggested in the reddit discussion - replace &'a Value with Cow<'a, Value>. > It's not a tradeoff thing; it's a "do I want a static method, or a member method" thing. > Actually where clauses are much more powerful. I really don't understand this part of the language yet, but... I linked to an active rfc about constraints that cannot currently be expressed in where clauses (https://github.com/rust-lang/rfcs/blob/master/text/0135-where.md https://github.com/rust-lang/rfcs/blob/master/text/0135-wher...), including the example you gave. In cases where a function takes two arguments it isn't always obvious which argument should be self. If that affects whether constraints end up being A: Foo<B> or B: Foo<A> or `where Foo<A,B>` it seems like one could run up against those limitations?

vph 11y ago

A Rust programmer can't seem to be Rusty. The more he's Rusty, the more he knows about it, which seems like a contradiction.

tatterdemalion 11y ago

This is a super interesting read! Having come into Rust from an experience with mostly object-oriented languages (Python, Java, C++), what you seem to have taken for granted, I found surprising and new, and what you are surprised by (such as self parameters), I found quite normal. It's great to see the other side of this.

jamii 11y ago
I've actually written a ton of python too. The self parameter didn't confuse me because of OO, but because traits can actually dispatch on the types of all of their arguments so it wasn't clear to me what the meaning of the self argument was and how much it should affect my design. Manishearth cleared up most of my confusion - it affects namespacing and auto-borrow but doesn't interact with constraints. Traits are very similar to typeclasses and I was just thrown by the surface level syntax.

cpp098 11y ago

New languages always are trap. Programmers always waste too much time on new languages or some tricky language syntax. They should focus on the business. I will never try Rust.

crazypyro 11y ago
Why can't you practice Rust in a non-business environment?
- cpp098 11y ago
  Programmers always spend too much time on studying which hammer is better, but they forget what they really want to do, right?
  - insulanian 11y ago
    I agree there is some truth in what you're saying. However, without programmer's curiosity and desire to create new interesting and beautiful languages, we would still be "focused on business" and writing code in COBOL, Fortran, C, Pascal...
  - AlisdairO 11y ago
    I agree with you generally -for me, given that I already know java well, it's clearly not worth the effort to spend much time on (say) Go. I make an exception here, because I think Rust has genuinely useful new ideas brought to the table.
  - b0b_d0e 11y ago
    I don't think that was the case for me at least. I felt like (using your own analogy) the more I studied Rust, the better I learned how to use every other hammer. Learning a new programming language helped me learn c++ better since I was constantly on the lookout for potential memory leaks and other common pitfalls that Rust prevents. Now when I code in c++, I always try to write the code with safety in mind.
  - Retra 11y ago

cassandranot 11y ago

I wasted three months on rust then got sober, and went back to c++, then life was good!

outworlder 11y ago
Are you performing a social experiment to see how low your karma can get?
getsat 11y ago
I ported a project to Rust and then ported it to C++14 (which is awesome!), but I only did that because Rust was in a state of massive flux at the time and I got tired of the project breaking every two days due to changes to the compiler/syntax/stdlib. I plan to reevaluate Rust once it's settled down a bit.

phren0logy 11y ago

The Eve language is an offshoot of what started as LightTable, which was heavily focused on Clojure/Clojurescript. Interesting that Clojurescript was not the language of choice here, both given the roots of that project and the reputation of lisps for being languages to write other languages. I wonder if the team would be willing to comment on why they are moving away from Clojurescript?

jamii 11y ago
Writing a language runtime in javascript is hard enough, clojurescript adds yet more layers of runtime overhead that we have to work around. Clojurescript is a fine applications language, but it's not a good systems language. Most languages aren't.

halosghost 11y ago

+1, at the very least, because of the nod to Terra. Terra, imho, feels a lot like the perfect middle-ground between Lua and Rust. It has a clean syntax with some handy/fancy features but keeps a simple static typing system that makes me feel comfortable. Also, nice to read a review of Rust that didn't reduce to “C is the worst evar!” or “Haskell makes no sense!”. Reasoned and clearcut. I certainly disagree with various parts of the review, but I don't do any dev for webservices so it is unsurprising that the author and I have a differing of opinion.

jamii 11y ago
I would be interested to hear which parts you disagree with. > I don't do any dev for webservices so it is unsurprising that the author and I have a differing of opinion I don't either, I'm working on a database / language runtime. It happens to have a html interface rather than a console interface, but the majority of the work is very far away from normal web-dev :) > Terra, imho, feels a lot like the perfect middle-ground between Lua and Rust In particular, I really like the idea that the Terra type-system is just Lua code, so you can have different kinds of static analysis in different places instead of one-type-system-to-rule-them-all. Of course, it's a totally unproven idea at this point so it's hard to say how that would turn out in a real project.