13 ms·

Still in love with Rust

183 points by adamnemecek 8y ago

inamberclad 8y ago
I'd still love to see a good tutorial on setting up Vim to work well with rls and all the other plugins. I only really keep VSCode around since it works with rls and sometimes I want to use the autocomplete for codebases that are large enough to really need good autocomplete, but not so large that rls gets bogged down and doesn't work at all anymore.
- vbezhenar 8y ago
  Idea worked wonderfully for me with tiny pet projects.
- lkurusa 8y ago
  Does vim-racer[0] not work for you? I don't exactly know what you mean by "good autocomplete", but if you are more specific, then maybe we can help you a little more? :-) FWIW, my Rust setup in vim is mostly the following plugins: * NERDCommenter, for commenting stuff * rust.vim, for general rust things (like integration with rustfmt, playground, and the next two plugins) * tagbar, for showing the list of tags (of the ctags-esque sense) in a sidebar. * syntastic, for on-the-go syntax checking. [0]: https://github.com/racer-rust/vim-racer https://github.com/racer-rust/vim-racer
- bhengaij 8y ago
  Same. Rust needs a one-click install "integrated de"
- mcjiggerlog 8y ago
  For language server autocompletion, install coc.nvim - https://github.com/neoclide/coc.nvim https://github.com/neoclide/coc.nvim Then :CocInstall coc-rls and should work out of the box. I also use https://github.com/w0rp/ale https://github.com/w0rp/ale to provide linting. Also works out of the box. You can get these things running on vim8, but honestly it's easier to just use neovim. If it's of any use, you can check out my full config at https://github.com/tom-james-watson/dotfiles https://github.com/tom-james-watson/dotfiles.
onhn 8y ago
“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” I think this hits the nail on the head for me: abstract structure first, the choice of language C/C++/Rust/... is then a secondary consideration.
- pepper_sauce 8y ago
  I don't think that holds, given the potential scale and severity of memory safety bugs in systems programming. I'm not saying Rust is the right answer but not paying attention to, or worse, putting our heads in the sand, when it comes to our tools is not the answer.
- _i_think_ 8y ago
  let me tell you that Rust forces you to very carefully consider data structures and their relationships. The point of a programming tool is to help the programmer to be a better programmer, there is indeed no point using a very strict language, statically typed with lot of constraints attached for a perfect programmer. But for commoners it would certainly help to have some guiding.
- a_imho 8y ago
  Which brings up the question when/why to pick Rust? There are a plethora of languages which from my layman perspective seem more interesting. OTOH there are a plethora of languages with rich ecosystems, proven pedigree and with a high demand for such developers.
  - seren 8y ago
    I am working on medical devices, where a bug can have catastrophic consequences. Essentially the ecosystem today is C and C++ for embedded FW and middleware. Even if we are careful, we rely on static analysis tools to avoid some categories of bug. (Plus a humongous amount of tests). Typically bugs that would be caught (mostly) by the Rust compiler at compile time. I think it is a great idea to have some safety guarantee at compile time. Would Rust fixes every problem ? Absolutely not, you'll always get logical bug or implementation not conform to the requirements but I think it is a move in the right direction, and I hope that slowly in next 10 years Rust will grow in the embedded space. And overall cargo is nice, C/C++ don't have standard package manager. The test infrastructure is there by default, this is a breeze to add them in your code, rather than relying on an external framework, so this is also good. I don't really see an alternative today for small footprint SW where C and C++ is king, and I hope that embedded toolchain vendors are taking notes. If today you mostly code in javascript or python, unless you need bare metal like performance or to have stronger safety guarantee, maybe it does not make sense to move to Rust.
hasahmed 8y ago
Rust sounds like the dream. I gotta check it out sometime
hbbio 8y ago
Rust is a wonderful language, but I still have the impression that it is not stable as of 2018. All the toys I've made to play with it during the last years went deprecated quickly, especially if you rely on the ecosystem of packages (web server, database, ...). In addition, there was this thread: https://internals.rust-lang.org/t/concerned-about-rust-2018-stability/7932 https://internals.rust-lang.org/t/concerned-about-rust-2018-... All in all, Rust will be great when stable (including the ecosystem).
- danieldk 8y ago
  I think it depends a bit on which in part of the ecosystem you work. I do not do web applications at all, but use Rust for machine learning. Things like ndarray, petgraph, and the Tensorflow bindings have been very stable for me. The only large change that I had to make over the last year due to ecosystem changes was going from error-chain to failure. Of course, this was not strictly necessary, but failure seems to be more popular now and I generally prefer it over error-chain.
  - rqs 8y ago
    > depends a bit on which in part of the ecosystem you work This is also my experience. The feeling towards Rust is highly depends on the dependency of choice. Rust itself is mostly very stable though. I've implemented few pure algorithms in Rust a little over two years ago, and it still compile and runs today without having to change a single letter. Wish one day I can say the same thing to my other Rust projects :)
- the_mitsuhiko 8y ago
  > All the toys I've made to play with it during the last years went deprecated quickly In which sense? That dependencies evolved?
  - hbbio 8y ago
    Languages features, dependencies, etc. For instance one project: error[E0010]: allocations are not allowed in constants error[E0015]: calls in constants are limited to tuple structs and tuple variants Another: error: could not find native static library `brotli`, perhaps an -L flag is missing? error: aborting due to previous error error: Could not compile `brotli-sys`. And I'm not talking what happens if you don't fix versions in Cargo.toml.
Svip 8y ago
Thank you for this piece. I am working on a game, that I am prototyping in Go. In my prototype, I have just entered the realm of multiple threads, and for this project to work out, it needs to handle quite a lot of threads working on the same resources. While I have not personally dappled this far into concurrency in Go myself, I have read plenty of articles where developers recommend using the mutex package rather than the goroutines themselves. But I've also read about Rust's thread and resource handling -- and I'll admit, I've been looking for an excuse to write some Rust again -- and so inspired by this entry, I've decided to finish the prototype in Go, and build the real version in Rust.
- monocasa 8y ago
  There was a great talk recently about how to properly build an entity component framework in Rust if you haven't seen it yet. https://youtu.be/aKLntZcp27M https://youtu.be/aKLntZcp27M
  - Svip 8y ago
    Thank you for that link. Very useful. It already highlighted a solution in Rust for a problem that I've run into with my Go prototype. And I appreciate there also was a blog post to read.[0] I personally prefer articles over videos. [0] https://kyren.github.io/2018/09/14/rustconf-talk.html https://kyren.github.io/2018/09/14/rustconf-talk.html
vaylian 8y ago
> Rust will force you to be a good programmer, > [if] you like it or not. This is probably the best in-a-nutshell statement that describes what a good programming language is for me. I had similar moments in the past. Before Python I cared about indention to some degree. But once I got used to the way Python forces you to indent your code, I came to the realization that this is pretty much the way I should format my code anyway and it influenced my coding style in all other block-based languages for the better. Clojure was another language that showed me how functional programming should be done. My code in all languages changed and I used a lot less variables and a lot more constants and parameters. My code and the systems I created became a lot simpler and much more robust as a consequence. I had used Haskell before but it never really transformed my mind the way Clojure did. I also got a really good grasp on destructuring and list comprehension. Rust offered me several relevations. I finally understood test-driven-development because the language has excellent support for it. I also understood RAII more deeply. Traits became clear to me (Clojure protocols and Haskell type classes felt strange to me). I finally understood why the Maybe monad in Haskell/ML is one of the simplest and yet bests ideas in programming. And there is the borrow checker. I already had a functional programming mindset when I picked up Rust. But having a clear owner of data takes the mindset of functional programming even further[1], even when mutability is involved. It is a lot easier to reason about your code when you know exactly which operations can (and should) change a variable. An aspect that the Python, Clojure and Rust communities have in common is that they emphasize idiomatic code a lot. Therefore it is much easier for newcomers to find examples of professional-level code and learn things the right way. And it is much easier to dive into a new codebase. Clojure is actually a very extreme case of this, because Clojure code tends to use a lot of 1-letter parameter names. In most programming languages you are allowed to have the variable "i" for looping over numbers. But not much more. In contrast, Clojure has a list of well-established 1-letter variables that are recognized by everyone in the community. [1] This does not adhere to the classical definition of functional programming but I feel that it is a natural extension to it.
- goldfeld 8y ago
  Python formatting is egregious though, with hopelessly long lines and no sign of where to break them up, or at the most weird places. Yes I'm one of those persons who adheres to the terminal 80 column rule, it's neat for splitting and cascades into many benefits. Python often looks like unkempt code to me, like the developer has no care for how it looks or layouts (which isn't true, it's Python's fault.) The forced indentation (I love proper formatting with consistency and indentation in languages) is among the first reasons I never liked or used Python, until recently when I gave in because it's such a great ecosystem to build scripts and such, but I still hate the formatting everyday. Clojure is beautiful though. Even C is gorgeous compared to a Python 'forced' program layout. I'll start adding Hy to the mix and touch vanilla Python as little as possible, but I still have to read library code.
EugeneOZ 8y ago
"No race conditions, leaking resources, dangling pointers, unhandled exceptions, ..., the list goes on." Except of dangling pointers, Rust has everything else from this list. About compilation time issue: it doesn't exist anymore. Current versions do "cargo check" in a few seconds even for big projects (my biggest project is 45k LoC) and it takes a couple of minutes to compile it because of incremental compilation. For libraries it takes seconds to compile and 1-2 seconds to run "cargo check" (or clippy).
- Laaas 8y ago
  It is indeed true that you can unintentionally leak resources, but it is still much harder. Also, what do you mean that it has unhandled exceptions and race conditions? Rust doesn't even have exceptions (although there are panics, which is not the same thing), and race conditions are statically prevented in safe code due to how a mutable reference works.
  - EugeneOZ 8y ago
    Theoretically they are different, in practice they are the same (it's just more difficult to handle panicking - sometimes you can't use catch_unwind because of it's trait limitations). About race conditions: https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html
    - setr 8y ago
      I feel like its quite difficult to call them the same in practice, when they serve very different roles: errors that are likely to be recoverable are not panics! in a sane rust api, whereas they very much are exceptions in sane C++. You recover from either in similar fashion, but panics! are intended to serve a much different role than exceptions (the common usage of exceptions in C++ being covered by Result<> in rust).
      - EugeneOZ 8y ago
        I hate when people use exceptions for regular errors, it triggers me hard. Please let's don't start this topic :)
z3t4 8y ago
Can't have a Rust post without a mention of D.
geo_mer 8y ago
Native async/await support is really great. I haven't gotten very far with Rust but it already made me rethink many things that I thought I had understood.
LukaD 8y ago
The comment about "no race conditions" is not accurate. Rust guarantees an absence of data races which are not the same as race conditions. https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html
kungtotte 8y ago
Another point against Rust is binary size. If you write the Fibonacci generator in one of the first chapters of the Rust book it will create a 4MB binary. Even stripped it's over 400KB. If you write the same code in Nim it compiles down to 112KB with debug symbols, unstripped. Statically linked against libc (still with debug symbols) it's only 850KB. 850KB statically linked versus ~450KB dynamically linked and stripped. For code that is virtually identical.
- danieldk 8y ago
  Rust binaries include jemalloc. However, jemalloc is removed in nightly and by default Rust will use the system allocator: https://internals.rust-lang.org/t/jemalloc-was-just-removed-from-the-standard-library/8759 https://internals.rust-lang.org/t/jemalloc-was-just-removed-... This should reduce binary sizes quite a bit.
  - vesak 8y ago
    And some rough numbers, rustc-1.30.1 vs rustc-1.32.0-2018-11-21, building a hello world with --release... Mac OS: - 1.30.1 before strip: 573K, after strip: 380K - 1.32.0 before strip: 267K, after strip: 178K Ubuntu 18.04 LTS: - 1.30.1 before strip: 3.9M, after strip: 407K - 1.32.0 before strip: 2.3M, after strip: 191K
    - kungtotte 8y ago
      I'm on Void Linux right now running Nim 0.19 compiling the following code: when isMainModule: echo "Hello World" nim c hello.nim: Before strip: 113k After strip: 92k nim c -d:release hello.nim: Before strip: 79k After strip: 63k nim c -d:release --opt:size hello.nim: Before strip: 46k After strip: 30k Kind of a toy example but it illustrates my point. An unstripped version of the Nim program with full debug symbols is still 78k smaller than the stripped, release version of the Rust equivalent. But it's great that they're trying to work on this problem.
      - nimmer 8y ago
jerrre 8y ago
> Let's face it – typically developers are familiar with OOP, garbage collected, dynamic programming languages. I think most of these programmers, and their project are not the target of Rust? If you're writing Java/C# or higher level languages, you already made the choice to sacrifice some computing efficiency for programming efficiency. I always thought Rust was more destined to convert C and C++ (and D/Swift/Go ?) programmers, that need the raw power and control.
- projektir 8y ago
  > I think most of these programmers, and their project are not the target of Rust? If you're writing Java/C# or higher level languages, you already made the choice to sacrifice some computing efficiency for programming efficiency. Or you just don't know any better, as was the case for me. There are many benefits to Rust that are not related to runtime efficiency.
- otikik 8y ago
  I don't know the demographics/targets, but I come to rust from ruby. So does Steve Kabnick, the author of the Rust book.
  - jerrre 8y ago
    Cool! What kind of projects do you work on, and what made you switch?
    - otikik 8y ago
      Well, I have not "switched". For now I am just learning (at a very slow pace). My current job is not in ruby any more, now I do Lua - I'm a core dev at Kong - https://konghq.com/ https://konghq.com/ . It's much lower-level than ruby, but still not as low as you can go with rust.
- steveklabnik 8y ago
  We have three major audiences: * "systems programmers", aka the C and C++ folk * "functional programmers", largely Haskell folk * "scripting programmers", mostly Ruby/Python/JavaScript folk Each has gotten something out of Rust, and also brought some things to Rust.
leni536 8y ago
I tried Rust a few weeks ago. Is my understanding correct that Rust doesn't have the equivalents to the following C++ features yet? - non-type and template template parameters - constexpr functions I understand that Rust macros can replace them some of the time, and they are much better then the C preprocessor, but that's quite a low bar to meet. Last time I checked non-type template parameters (called "const generics" in Rust) is on the roadmap, so it is promising.
- th0br0 8y ago
  A `const fn` RFC is accepted and somwhat available when using nightly compilers, also see https://github.com/rust-lang/rust/issues/24111 https://github.com/rust-lang/rust/issues/24111
- steveklabnik 8y ago
  The equivalent of "constexpr functions" has a design, and is usable in nightly. The equivalent of "non-type template parameters" has a design, but is not yet implemented. It's being worked on. There's no direct design for the equivalent of "template template parameters", but a similar feature has a design, but is not yet implemented. It's being worked on.
arendtio 8y ago
> Barriers to entry So far I had two faltering attempts to learn Rust but somehow I didn't find good enough material to get me hooked. I am looking for something similar to the Tour of Go[1], where you can interactively try the language by solving minimal tasks. Does someone know of such material? [1]: https://tour.golang.org https://tour.golang.org
- bugmen0t 8y ago
  https://github.com/carols10cents/rustlings https://github.com/carols10cents/rustlings
- steveklabnik 8y ago
  https://doc.rust-lang.org/rust-by-example/ https://doc.rust-lang.org/rust-by-example/
  - arendtio 8y ago
    That looks pretty good. Thanks :-)
- majewsky 8y ago
  I found The Book [1] to be pretty good, but it suffers the same problem that I find infuriating about programming language books in general. They have to target one specific proficiency level, so someone less experienced is going to get left behind, and someone more experienced is going to get bored out of their mind. As a somewhat experienced Rustacean, my biggest frustration as of now is the lack of a comprehensive reference where I can look up very specific things (e.g. the syntax for byte string literals, or an exact definition of how borrowing works in some particular edge case). There is [2] but as it says on the first page it's incomplete. [1] https://doc.rust-lang.org/book/2018-edition/index.html https://doc.rust-lang.org/book/2018-edition/index.html [2] https://doc.rust-lang.org/reference/introduction.html https://doc.rust-lang.org/reference/introduction.html
- kieckerjan 8y ago
  I come from C. What got me started was the O'Reilly book, Programming Rust by Blandy & Orendorff. (It cultivates the your sense of snobbery too. Imagine code examples using lists of "murderous Renaissance artists".)
Vogtinator 8y ago
Am I the only one who really can't stand rust? I was and still am very much in favor of the ideas and concepts, but when I actually tried to use it my opinion on it turned by 180°: - The syntax is awful - No dynamic libraries - Slow compile times - Many checks are too stupid to figure out some valid cases (maybe that improved meanwhile)
- steveklabnik 8y ago
  You are not. - No dynamic libraries This is technically incorrect, but practically correct, by the way. > (maybe that improved meanwhile) The next version, released on December 6th, ships "non-lexical lifetimes", which does make the borrow checker smarter.
- _pmf_ 8y ago
  No. I wanted to like it, but a lot of stuff (standard type names, syntax) is different just for the sake of being different. I wish D would have won the C++-successor race.
- vesak 8y ago
  > No dynamic libraries While I understand that some people prefer this, I prefer static linking to dynamic linking. So much in fact that I refuse to use environments that only do dynamic linking in any of my projects. Yes, I have to make a few concessions to that because of the idiocy of glibc, but other than that.
- andrenth 8y ago
  I have really tried to like it. Coming from OCaml, it has many of the things I’ve come to expect in a modern language, but with better tooling and more libraries. I generally do not mind syntax. I like OCaml’s and Erlang’s, for example, which are usually considered ugly, but for some reason I can’t enjoy the look of Rust code. I think all the nested <<<>>> and the use of :: are a large part of this. But the real issue for me was refactoring owned struct fields into borrowed ones. The ‘a lifetimes leak everywhere; you have to add them to the struct field, after its “impls”, and everywhere the struct name appears. I’ve found that Pony provides the same level of safety in a much more lightweight manner with its capabilities system. Interestingly, if I’m not mistaken, early Rust was somewhat similar to Pony. Unfortunately Pony doesn’t have the same development resources and thus the ecosystem is somewhat lacking.
jjgreen 8y ago
I was going to try out Rust, then I saw this on the download page curl https://sh.rustup.rs -sSf | sh Really?
- steveklabnik 8y ago
  Yes. The script is less than 400 lines, and is pretty easy to audit. We wrote it in such a way to prevent some issues like "if the download gets cut off only part of the script gets run." It's served over HTTPS. You can also probably get an install from whatever package manager you use, if you prefer that.
  - tpxl 8y ago
    You can detect whether the script is being piped into sh, so downloading the script via for example FF might produce different results than piping it to shell, making audits useless.
    - steveklabnik 8y ago
      Sure. If you're worried about that, it's easy enough to download it first, and then run it, without the pipe. If you're auditing it, you've already downloaded it, so it's unclear to me why you'd re-download and pipe rather than just running it.
      - nimmer 8y ago
        You still have zero guarantee that other people are getting the same code. Encouraging people to run code from some random URL on the Internet is always bad.
- _pmf_ 8y ago
  Would you like to download your script wrapped in a .deb post-install/pre-install section? Would that make you feel superior?
- ElBarto 8y ago
woile 8y ago
How does data-centric work? How is it different from OOP? Can someone elaborate for a person using python? Also, what opinion rust devs have over golang?
- steveklabnik 8y ago
  > How does data-centric work? How is it different from OOP? Rust doens't have objects. You have structs, which are purely data, and functions, which are purely behavior. OOP puts the two together. So in Rust, you don't tend to design things by saying "what are the objects I need?" but rather "what is the data I am manipulating and how do I manipulate it?" > Also, what opinion rust devs have over golang? I am not 100% sure what you're asking here, could you maybe re-phrase? Are you asking why Rust is better than Go?
  - woile 8y ago
    Oh nice, good to know. > Are you asking why Rust is better than Go? No, just the opinion in general, why rust over go? I know go is more oriented to distributed systems, but it seems like rust eventually will be used for that as well. And I also see golang being used to build just anything, like gopass for example.
    - steveklabnik 8y ago
      Ah. That's a more interesting question, for sure. :) I got involved with Rust over Go because if I'm going to use a statically typed language, I need generics. That was the initial thing, but other things ended up going similar ways (I think package management is extremely important, for example.) I think Go has made great choices to accomplish its goals, but I'm personally more interested in a different set of tradeoffs.
snrji 8y ago
Rust still lacks an effect system, though. Any plans?
- steveklabnik 8y ago
  No current plans.
axilmar 8y ago
The moment a programmer conflates OOP with 'complicated graphs with lots of interdependencies between nodes', it's the moment I stop reading their writings. OOP does not force one write complicated graphs of objects. OOP has its applicability, FP has its applicability and well-written code in conventional languages is a mixture of those two.
insulanian 8y ago
Can someone familiar with both Rust and F# (or OCaml) type systems write few words about the expressiveness aspect of the language? What would I miss in Rust if coming from the F# background?
- steveklabnik 8y ago
  Fun fact: Rust was originally implemented in OCaml, and takes a lot of inspiration from it. Rust was originally described to me by someone as "C meets OCaml." The biggest thing missing in Rust that are in both are higher kinded types. The biggest thing missing from OCaml is parameterized modules.
  - insulanian 8y ago
    F# doesn't actually have HKTs either, unfortunately.
    - steveklabnik 8y ago
      I thought it did, my mistake!
- mamcx 8y ago
  In the surface you can say yes or no (only looking at types and such). But summing all the features, F# is far more immediately productive. I take rust after 2 years on F# (that I continue to use). I have like 2 months of Rust now. I still struggle to solve things that are "no-brainers" in F# or swift (mainly, because Rust is VERY strict about know statically all about the code, and VERY hard to build generic, dynamic code). So, it will look less expresive, IMHO. I still ramping-up and start to get more a more of the rust style of programming, so the pain is reduce. With the additions for rust in the near future it will reduce it more, I hope.
millstone 8y ago
> Now I see how before Rust I was often writing my code in a typical OOP-way: forming complicated graphs, with many objects referencing each other, with unclear relationships. The class APIs, inheritance hierarchies, were there, but they were just obstructing the core problem: structuring and manipulating data... Rust will force you to be a good programmer, you like it or not. Rust today demands static knowledge of all relationships. But class APIs, inheritance hierarchies, and the like are powerful tools for dealing with dynamic relationships: code that runs together yet evolves separately, where Rust is feeble. Good programmers recognize that different problems require different solutions!
- Dowwie 8y ago
  Rust is feeble at patterns it wasn't made for (OOP), absolutely. :). Composition over inheritance.
Dowwie 8y ago
dpc, the author, is such a helpful, positive force at the #rust-beginners IRC channel
Dowwie 8y ago
Rust core development is working on many important features in parallel. The feature I have been most excited about, and wish was here already, is async/await. I wrote quite a bit of asyncio using futures and it was a bloody, exhausting experience. Lack of documentation or examples made the experience even more challenging. Much of what I wrote could be trivially refactored to async/await syntax, but I may keep some around to honor hard-earned gains. It's not clear to me yet whether the first stable release in Q1 2019 will allow me to port everything but I look forward to finding out.
purplezooey 8y ago
Bad programmers worry about the code. Good programmers worry about data structures and their relationships. Mildly horse shit. It takes both on a team.

183 points by adamnemecek 8y ago

I'd still love to see a good tutorial on setting up Vim to work well with rls and all the other plugins. I only really keep VSCode around since it works with rls and sometimes I want to use the autocomplete for codebases that are large enough to really need good autocomplete, but not so large that rls gets bogged down and doesn't work at all anymore.

vbezhenar 8y ago
Idea worked wonderfully for me with tiny pet projects.
lkurusa 8y ago
Does vim-racer[0] not work for you? I don't exactly know what you mean by "good autocomplete", but if you are more specific, then maybe we can help you a little more? :-) FWIW, my Rust setup in vim is mostly the following plugins: * NERDCommenter, for commenting stuff * rust.vim, for general rust things (like integration with rustfmt, playground, and the next two plugins) * tagbar, for showing the list of tags (of the ctags-esque sense) in a sidebar. * syntastic, for on-the-go syntax checking. [0]: https://github.com/racer-rust/vim-racer https://github.com/racer-rust/vim-racer
bhengaij 8y ago
Same. Rust needs a one-click install "integrated de"
mcjiggerlog 8y ago
For language server autocompletion, install coc.nvim - https://github.com/neoclide/coc.nvim https://github.com/neoclide/coc.nvim Then :CocInstall coc-rls and should work out of the box. I also use https://github.com/w0rp/ale https://github.com/w0rp/ale to provide linting. Also works out of the box. You can get these things running on vim8, but honestly it's easier to just use neovim. If it's of any use, you can check out my full config at https://github.com/tom-james-watson/dotfiles https://github.com/tom-james-watson/dotfiles.

onhn 8y ago

“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” I think this hits the nail on the head for me: abstract structure first, the choice of language C/C++/Rust/... is then a secondary consideration.

pepper_sauce 8y ago
I don't think that holds, given the potential scale and severity of memory safety bugs in systems programming. I'm not saying Rust is the right answer but not paying attention to, or worse, putting our heads in the sand, when it comes to our tools is not the answer.
_i_think_ 8y ago
let me tell you that Rust forces you to very carefully consider data structures and their relationships. The point of a programming tool is to help the programmer to be a better programmer, there is indeed no point using a very strict language, statically typed with lot of constraints attached for a perfect programmer. But for commoners it would certainly help to have some guiding.
a_imho 8y ago
Which brings up the question when/why to pick Rust? There are a plethora of languages which from my layman perspective seem more interesting. OTOH there are a plethora of languages with rich ecosystems, proven pedigree and with a high demand for such developers.
- seren 8y ago
  I am working on medical devices, where a bug can have catastrophic consequences. Essentially the ecosystem today is C and C++ for embedded FW and middleware. Even if we are careful, we rely on static analysis tools to avoid some categories of bug. (Plus a humongous amount of tests). Typically bugs that would be caught (mostly) by the Rust compiler at compile time. I think it is a great idea to have some safety guarantee at compile time. Would Rust fixes every problem ? Absolutely not, you'll always get logical bug or implementation not conform to the requirements but I think it is a move in the right direction, and I hope that slowly in next 10 years Rust will grow in the embedded space. And overall cargo is nice, C/C++ don't have standard package manager. The test infrastructure is there by default, this is a breeze to add them in your code, rather than relying on an external framework, so this is also good. I don't really see an alternative today for small footprint SW where C and C++ is king, and I hope that embedded toolchain vendors are taking notes. If today you mostly code in javascript or python, unless you need bare metal like performance or to have stronger safety guarantee, maybe it does not make sense to move to Rust.

hasahmed 8y ago

Rust sounds like the dream. I gotta check it out sometime

hbbio 8y ago

Rust is a wonderful language, but I still have the impression that it is not stable as of 2018. All the toys I've made to play with it during the last years went deprecated quickly, especially if you rely on the ecosystem of packages (web server, database, ...). In addition, there was this thread: https://internals.rust-lang.org/t/concerned-about-rust-2018-stability/7932 https://internals.rust-lang.org/t/concerned-about-rust-2018-... All in all, Rust will be great when stable (including the ecosystem).

danieldk 8y ago
I think it depends a bit on which in part of the ecosystem you work. I do not do web applications at all, but use Rust for machine learning. Things like ndarray, petgraph, and the Tensorflow bindings have been very stable for me. The only large change that I had to make over the last year due to ecosystem changes was going from error-chain to failure. Of course, this was not strictly necessary, but failure seems to be more popular now and I generally prefer it over error-chain.
- rqs 8y ago
  > depends a bit on which in part of the ecosystem you work This is also my experience. The feeling towards Rust is highly depends on the dependency of choice. Rust itself is mostly very stable though. I've implemented few pure algorithms in Rust a little over two years ago, and it still compile and runs today without having to change a single letter. Wish one day I can say the same thing to my other Rust projects :)
the_mitsuhiko 8y ago
> All the toys I've made to play with it during the last years went deprecated quickly In which sense? That dependencies evolved?
- hbbio 8y ago
  Languages features, dependencies, etc. For instance one project: error[E0010]: allocations are not allowed in constants error[E0015]: calls in constants are limited to tuple structs and tuple variants Another: error: could not find native static library `brotli`, perhaps an -L flag is missing? error: aborting due to previous error error: Could not compile `brotli-sys`. And I'm not talking what happens if you don't fix versions in Cargo.toml.

Svip 8y ago

Thank you for this piece. I am working on a game, that I am prototyping in Go. In my prototype, I have just entered the realm of multiple threads, and for this project to work out, it needs to handle quite a lot of threads working on the same resources. While I have not personally dappled this far into concurrency in Go myself, I have read plenty of articles where developers recommend using the mutex package rather than the goroutines themselves. But I've also read about Rust's thread and resource handling -- and I'll admit, I've been looking for an excuse to write some Rust again -- and so inspired by this entry, I've decided to finish the prototype in Go, and build the real version in Rust.

monocasa 8y ago
There was a great talk recently about how to properly build an entity component framework in Rust if you haven't seen it yet. https://youtu.be/aKLntZcp27M https://youtu.be/aKLntZcp27M
- Svip 8y ago
  Thank you for that link. Very useful. It already highlighted a solution in Rust for a problem that I've run into with my Go prototype. And I appreciate there also was a blog post to read.[0] I personally prefer articles over videos. [0] https://kyren.github.io/2018/09/14/rustconf-talk.html https://kyren.github.io/2018/09/14/rustconf-talk.html

vaylian 8y ago

> Rust will force you to be a good programmer, > [if] you like it or not. This is probably the best in-a-nutshell statement that describes what a good programming language is for me. I had similar moments in the past. Before Python I cared about indention to some degree. But once I got used to the way Python forces you to indent your code, I came to the realization that this is pretty much the way I should format my code anyway and it influenced my coding style in all other block-based languages for the better. Clojure was another language that showed me how functional programming should be done. My code in all languages changed and I used a lot less variables and a lot more constants and parameters. My code and the systems I created became a lot simpler and much more robust as a consequence. I had used Haskell before but it never really transformed my mind the way Clojure did. I also got a really good grasp on destructuring and list comprehension. Rust offered me several relevations. I finally understood test-driven-development because the language has excellent support for it. I also understood RAII more deeply. Traits became clear to me (Clojure protocols and Haskell type classes felt strange to me). I finally understood why the Maybe monad in Haskell/ML is one of the simplest and yet bests ideas in programming. And there is the borrow checker. I already had a functional programming mindset when I picked up Rust. But having a clear owner of data takes the mindset of functional programming even further[1], even when mutability is involved. It is a lot easier to reason about your code when you know exactly which operations can (and should) change a variable. An aspect that the Python, Clojure and Rust communities have in common is that they emphasize idiomatic code a lot. Therefore it is much easier for newcomers to find examples of professional-level code and learn things the right way. And it is much easier to dive into a new codebase. Clojure is actually a very extreme case of this, because Clojure code tends to use a lot of 1-letter parameter names. In most programming languages you are allowed to have the variable "i" for looping over numbers. But not much more. In contrast, Clojure has a list of well-established 1-letter variables that are recognized by everyone in the community. [1] This does not adhere to the classical definition of functional programming but I feel that it is a natural extension to it.

goldfeld 8y ago
Python formatting is egregious though, with hopelessly long lines and no sign of where to break them up, or at the most weird places. Yes I'm one of those persons who adheres to the terminal 80 column rule, it's neat for splitting and cascades into many benefits. Python often looks like unkempt code to me, like the developer has no care for how it looks or layouts (which isn't true, it's Python's fault.) The forced indentation (I love proper formatting with consistency and indentation in languages) is among the first reasons I never liked or used Python, until recently when I gave in because it's such a great ecosystem to build scripts and such, but I still hate the formatting everyday. Clojure is beautiful though. Even C is gorgeous compared to a Python 'forced' program layout. I'll start adding Hy to the mix and touch vanilla Python as little as possible, but I still have to read library code.

EugeneOZ 8y ago

"No race conditions, leaking resources, dangling pointers, unhandled exceptions, ..., the list goes on." Except of dangling pointers, Rust has everything else from this list. About compilation time issue: it doesn't exist anymore. Current versions do "cargo check" in a few seconds even for big projects (my biggest project is 45k LoC) and it takes a couple of minutes to compile it because of incremental compilation. For libraries it takes seconds to compile and 1-2 seconds to run "cargo check" (or clippy).

Laaas 8y ago
It is indeed true that you can unintentionally leak resources, but it is still much harder. Also, what do you mean that it has unhandled exceptions and race conditions? Rust doesn't even have exceptions (although there are panics, which is not the same thing), and race conditions are statically prevented in safe code due to how a mutable reference works.
- EugeneOZ 8y ago
  Theoretically they are different, in practice they are the same (it's just more difficult to handle panicking - sometimes you can't use catch_unwind because of it's trait limitations). About race conditions: https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html
  - setr 8y ago
    I feel like its quite difficult to call them the same in practice, when they serve very different roles: errors that are likely to be recoverable are not panics! in a sane rust api, whereas they very much are exceptions in sane C++. You recover from either in similar fashion, but panics! are intended to serve a much different role than exceptions (the common usage of exceptions in C++ being covered by Result<> in rust).
    - EugeneOZ 8y ago
      I hate when people use exceptions for regular errors, it triggers me hard. Please let's don't start this topic :)

z3t4 8y ago

Can't have a Rust post without a mention of D.

geo_mer 8y ago

Native async/await support is really great. I haven't gotten very far with Rust but it already made me rethink many things that I thought I had understood.

LukaD 8y ago

The comment about "no race conditions" is not accurate. Rust guarantees an absence of data races which are not the same as race conditions. https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html

kungtotte 8y ago

Another point against Rust is binary size. If you write the Fibonacci generator in one of the first chapters of the Rust book it will create a 4MB binary. Even stripped it's over 400KB. If you write the same code in Nim it compiles down to 112KB with debug symbols, unstripped. Statically linked against libc (still with debug symbols) it's only 850KB. 850KB statically linked versus ~450KB dynamically linked and stripped. For code that is virtually identical.

danieldk 8y ago
Rust binaries include jemalloc. However, jemalloc is removed in nightly and by default Rust will use the system allocator: https://internals.rust-lang.org/t/jemalloc-was-just-removed-from-the-standard-library/8759 https://internals.rust-lang.org/t/jemalloc-was-just-removed-... This should reduce binary sizes quite a bit.
- vesak 8y ago
  And some rough numbers, rustc-1.30.1 vs rustc-1.32.0-2018-11-21, building a hello world with --release... Mac OS: - 1.30.1 before strip: 573K, after strip: 380K - 1.32.0 before strip: 267K, after strip: 178K Ubuntu 18.04 LTS: - 1.30.1 before strip: 3.9M, after strip: 407K - 1.32.0 before strip: 2.3M, after strip: 191K
  - kungtotte 8y ago
    I'm on Void Linux right now running Nim 0.19 compiling the following code: when isMainModule: echo "Hello World" nim c hello.nim: Before strip: 113k After strip: 92k nim c -d:release hello.nim: Before strip: 79k After strip: 63k nim c -d:release --opt:size hello.nim: Before strip: 46k After strip: 30k Kind of a toy example but it illustrates my point. An unstripped version of the Nim program with full debug symbols is still 78k smaller than the stripped, release version of the Rust equivalent. But it's great that they're trying to work on this problem.
    - nimmer 8y ago

jerrre 8y ago

> Let's face it – typically developers are familiar with OOP, garbage collected, dynamic programming languages. I think most of these programmers, and their project are not the target of Rust? If you're writing Java/C# or higher level languages, you already made the choice to sacrifice some computing efficiency for programming efficiency. I always thought Rust was more destined to convert C and C++ (and D/Swift/Go ?) programmers, that need the raw power and control.

projektir 8y ago
> I think most of these programmers, and their project are not the target of Rust? If you're writing Java/C# or higher level languages, you already made the choice to sacrifice some computing efficiency for programming efficiency. Or you just don't know any better, as was the case for me. There are many benefits to Rust that are not related to runtime efficiency.
otikik 8y ago
I don't know the demographics/targets, but I come to rust from ruby. So does Steve Kabnick, the author of the Rust book.
- jerrre 8y ago
  Cool! What kind of projects do you work on, and what made you switch?
  - otikik 8y ago
    Well, I have not "switched". For now I am just learning (at a very slow pace). My current job is not in ruby any more, now I do Lua - I'm a core dev at Kong - https://konghq.com/ https://konghq.com/ . It's much lower-level than ruby, but still not as low as you can go with rust.
steveklabnik 8y ago
We have three major audiences: * "systems programmers", aka the C and C++ folk * "functional programmers", largely Haskell folk * "scripting programmers", mostly Ruby/Python/JavaScript folk Each has gotten something out of Rust, and also brought some things to Rust.

leni536 8y ago

I tried Rust a few weeks ago. Is my understanding correct that Rust doesn't have the equivalents to the following C++ features yet? - non-type and template template parameters - constexpr functions I understand that Rust macros can replace them some of the time, and they are much better then the C preprocessor, but that's quite a low bar to meet. Last time I checked non-type template parameters (called "const generics" in Rust) is on the roadmap, so it is promising.

th0br0 8y ago
A `const fn` RFC is accepted and somwhat available when using nightly compilers, also see https://github.com/rust-lang/rust/issues/24111 https://github.com/rust-lang/rust/issues/24111
steveklabnik 8y ago
The equivalent of "constexpr functions" has a design, and is usable in nightly. The equivalent of "non-type template parameters" has a design, but is not yet implemented. It's being worked on. There's no direct design for the equivalent of "template template parameters", but a similar feature has a design, but is not yet implemented. It's being worked on.

arendtio 8y ago

> Barriers to entry So far I had two faltering attempts to learn Rust but somehow I didn't find good enough material to get me hooked. I am looking for something similar to the Tour of Go[1], where you can interactively try the language by solving minimal tasks. Does someone know of such material? [1]: https://tour.golang.org https://tour.golang.org

bugmen0t 8y ago
https://github.com/carols10cents/rustlings https://github.com/carols10cents/rustlings
steveklabnik 8y ago
https://doc.rust-lang.org/rust-by-example/ https://doc.rust-lang.org/rust-by-example/
- arendtio 8y ago
  That looks pretty good. Thanks :-)
majewsky 8y ago
I found The Book [1] to be pretty good, but it suffers the same problem that I find infuriating about programming language books in general. They have to target one specific proficiency level, so someone less experienced is going to get left behind, and someone more experienced is going to get bored out of their mind. As a somewhat experienced Rustacean, my biggest frustration as of now is the lack of a comprehensive reference where I can look up very specific things (e.g. the syntax for byte string literals, or an exact definition of how borrowing works in some particular edge case). There is [2] but as it says on the first page it's incomplete. [1] https://doc.rust-lang.org/book/2018-edition/index.html https://doc.rust-lang.org/book/2018-edition/index.html [2] https://doc.rust-lang.org/reference/introduction.html https://doc.rust-lang.org/reference/introduction.html
kieckerjan 8y ago
I come from C. What got me started was the O'Reilly book, Programming Rust by Blandy & Orendorff. (It cultivates the your sense of snobbery too. Imagine code examples using lists of "murderous Renaissance artists".)

Vogtinator 8y ago

Am I the only one who really can't stand rust? I was and still am very much in favor of the ideas and concepts, but when I actually tried to use it my opinion on it turned by 180°: - The syntax is awful - No dynamic libraries - Slow compile times - Many checks are too stupid to figure out some valid cases (maybe that improved meanwhile)

steveklabnik 8y ago
You are not. - No dynamic libraries This is technically incorrect, but practically correct, by the way. > (maybe that improved meanwhile) The next version, released on December 6th, ships "non-lexical lifetimes", which does make the borrow checker smarter.
_pmf_ 8y ago
No. I wanted to like it, but a lot of stuff (standard type names, syntax) is different just for the sake of being different. I wish D would have won the C++-successor race.
vesak 8y ago
> No dynamic libraries While I understand that some people prefer this, I prefer static linking to dynamic linking. So much in fact that I refuse to use environments that only do dynamic linking in any of my projects. Yes, I have to make a few concessions to that because of the idiocy of glibc, but other than that.
andrenth 8y ago
I have really tried to like it. Coming from OCaml, it has many of the things I’ve come to expect in a modern language, but with better tooling and more libraries. I generally do not mind syntax. I like OCaml’s and Erlang’s, for example, which are usually considered ugly, but for some reason I can’t enjoy the look of Rust code. I think all the nested <<<>>> and the use of :: are a large part of this. But the real issue for me was refactoring owned struct fields into borrowed ones. The ‘a lifetimes leak everywhere; you have to add them to the struct field, after its “impls”, and everywhere the struct name appears. I’ve found that Pony provides the same level of safety in a much more lightweight manner with its capabilities system. Interestingly, if I’m not mistaken, early Rust was somewhat similar to Pony. Unfortunately Pony doesn’t have the same development resources and thus the ecosystem is somewhat lacking.

jjgreen 8y ago

I was going to try out Rust, then I saw this on the download page curl https://sh.rustup.rs -sSf | sh Really?

steveklabnik 8y ago
Yes. The script is less than 400 lines, and is pretty easy to audit. We wrote it in such a way to prevent some issues like "if the download gets cut off only part of the script gets run." It's served over HTTPS. You can also probably get an install from whatever package manager you use, if you prefer that.
- tpxl 8y ago
  You can detect whether the script is being piped into sh, so downloading the script via for example FF might produce different results than piping it to shell, making audits useless.
  - steveklabnik 8y ago
    Sure. If you're worried about that, it's easy enough to download it first, and then run it, without the pipe. If you're auditing it, you've already downloaded it, so it's unclear to me why you'd re-download and pipe rather than just running it.
    - nimmer 8y ago
      You still have zero guarantee that other people are getting the same code. Encouraging people to run code from some random URL on the Internet is always bad.
_pmf_ 8y ago
Would you like to download your script wrapped in a .deb post-install/pre-install section? Would that make you feel superior?
ElBarto 8y ago

woile 8y ago

How does data-centric work? How is it different from OOP? Can someone elaborate for a person using python? Also, what opinion rust devs have over golang?

steveklabnik 8y ago
> How does data-centric work? How is it different from OOP? Rust doens't have objects. You have structs, which are purely data, and functions, which are purely behavior. OOP puts the two together. So in Rust, you don't tend to design things by saying "what are the objects I need?" but rather "what is the data I am manipulating and how do I manipulate it?" > Also, what opinion rust devs have over golang? I am not 100% sure what you're asking here, could you maybe re-phrase? Are you asking why Rust is better than Go?
- woile 8y ago
  Oh nice, good to know. > Are you asking why Rust is better than Go? No, just the opinion in general, why rust over go? I know go is more oriented to distributed systems, but it seems like rust eventually will be used for that as well. And I also see golang being used to build just anything, like gopass for example.
  - steveklabnik 8y ago
    Ah. That's a more interesting question, for sure. :) I got involved with Rust over Go because if I'm going to use a statically typed language, I need generics. That was the initial thing, but other things ended up going similar ways (I think package management is extremely important, for example.) I think Go has made great choices to accomplish its goals, but I'm personally more interested in a different set of tradeoffs.

snrji 8y ago

Rust still lacks an effect system, though. Any plans?

steveklabnik 8y ago
No current plans.

axilmar 8y ago

The moment a programmer conflates OOP with 'complicated graphs with lots of interdependencies between nodes', it's the moment I stop reading their writings. OOP does not force one write complicated graphs of objects. OOP has its applicability, FP has its applicability and well-written code in conventional languages is a mixture of those two.

insulanian 8y ago

Can someone familiar with both Rust and F# (or OCaml) type systems write few words about the expressiveness aspect of the language? What would I miss in Rust if coming from the F# background?

steveklabnik 8y ago
Fun fact: Rust was originally implemented in OCaml, and takes a lot of inspiration from it. Rust was originally described to me by someone as "C meets OCaml." The biggest thing missing in Rust that are in both are higher kinded types. The biggest thing missing from OCaml is parameterized modules.
- insulanian 8y ago
  F# doesn't actually have HKTs either, unfortunately.
  - steveklabnik 8y ago
    I thought it did, my mistake!
mamcx 8y ago
In the surface you can say yes or no (only looking at types and such). But summing all the features, F# is far more immediately productive. I take rust after 2 years on F# (that I continue to use). I have like 2 months of Rust now. I still struggle to solve things that are "no-brainers" in F# or swift (mainly, because Rust is VERY strict about know statically all about the code, and VERY hard to build generic, dynamic code). So, it will look less expresive, IMHO. I still ramping-up and start to get more a more of the rust style of programming, so the pain is reduce. With the additions for rust in the near future it will reduce it more, I hope.

millstone 8y ago

> Now I see how before Rust I was often writing my code in a typical OOP-way: forming complicated graphs, with many objects referencing each other, with unclear relationships. The class APIs, inheritance hierarchies, were there, but they were just obstructing the core problem: structuring and manipulating data... Rust will force you to be a good programmer, you like it or not. Rust today demands static knowledge of all relationships. But class APIs, inheritance hierarchies, and the like are powerful tools for dealing with dynamic relationships: code that runs together yet evolves separately, where Rust is feeble. Good programmers recognize that different problems require different solutions!

Dowwie 8y ago
Rust is feeble at patterns it wasn't made for (OOP), absolutely. :). Composition over inheritance.

Dowwie 8y ago

dpc, the author, is such a helpful, positive force at the #rust-beginners IRC channel

Dowwie 8y ago

Rust core development is working on many important features in parallel. The feature I have been most excited about, and wish was here already, is async/await. I wrote quite a bit of asyncio using futures and it was a bloody, exhausting experience. Lack of documentation or examples made the experience even more challenging. Much of what I wrote could be trivially refactored to async/await syntax, but I may keep some around to honor hard-earned gains. It's not clear to me yet whether the first stable release in Q1 2019 will allow me to port everything but I look forward to finding out.

purplezooey 8y ago

Bad programmers worry about the code. Good programmers worry about data structures and their relationships. Mildly horse shit. It takes both on a team.