48 ms·

First Impressions of Rust

274 points by jmillikin 6y ago

kanobo 6y ago
Once a Rustacean always a Rustacean - a first impression will inevitably lead you down a never ending road but luckily there is a great community to support you.
- rsa25519 6y ago
  Definitely. I must admit, I came to Rust with a lot of baggage from other languages. I've learned a lot from reading about why Rust doesn't let me do things, often causing me to no longer do those things in other languages.
- ncmncm 6y ago
  I gave Rust a good solid tryout. It turned out to be insufficiently expressive to put into libraries the semantics I want to encapsulate. I went back to C++, and have been very happy. (It's also nice that lots of people want to pay to have it done.) As with Rust, I can write 2000 lines and, once it compiles, it works. The hardest thing about going back to C++ from Rust was getting used to putting semicolons where Rust doesn't require them. Years later it still trips me.
  - supergirl 6y ago
    isn't C++ more like "once it compiles, it works, but later you discover 10 places where it segfaults"?
    - jdashg 6y ago
      This really depends on your development style and experience, but not in general, no.
    - brutt 6y ago
      Yep. It's why Mozilla invented Rust in first place.
    - ncmncm 6y ago
      That is how the propaganda goes. But in modern C++ style, memory errors just don't have many opportunities to happen. I.e., with the more powerful libraries C++14 and up enables, there is little temptation to drop to a risky level. And, anywhere you choose to, you can give it your full attention. So, overwhelmingly the bugs you do get are specification bugs: the code does what was asked, but the ask was wrong. The only way to avoid those is to pay attention. Anything that steals attention generates them, in C++ as in Rust. Old, pre-C++11 codebases (and codebases still written that way, or in C-with-classes style) suffer more. Mozilla and Google have a lot of old code.
      - ncmncm 6y ago
        You can down-vote all you like, but it remains true all the same.
    - ufmace 6y ago
      Kinda yeah, but more worryingly, 10 years later you discover it had an exploitable buffer overflow vulnerability the whole time. Now you have no idea who else has known about it, how long they've known, what systems they've compromised in what way using it, etc.
  - twic 6y ago
    What couldn't you express satisfactorily?
    - ncmncm 6y ago
      Almost every feature of C++ is there to aid making powerful libraries. It has dozens that Rust lacks, more added with each Standard, and they work in synergy. The primordial enabler in '98 was template partial specialization, that made the STL possible: same name with different types uses a different implementation.
deleted 6y ago
[deleted]
thenewwazoo 6y ago
I went into this expecting yet another barrage of complaints about lifetimes, but was very pleasantly surprised. This is probably one of the most thoughtful experienced-programmed new-to-Rust reviews I've read in a long, long time. I frankly don't have much to add, except to say that, once you really understand the language and start building complex projects, this article really does describe the real issues you run into.
- saagarjha 6y ago
  I think I am familiar with Rust–I spent a week or so working with it–and I ran into many of these exact issues. I appreciate it very much when someone can give a viewpoint of of using a language beyond the superficial one ("arrays start at one in Lua"), or complains about something core to the language ("C pointers are confusing") and actually says something you will run into but is not obvious from having a basic knowledge of the thing ("while Python supports functional programming, it does not do so very well"). Rust's (intentionally) anemic standard library, strange dance around nightly ("we never break things…except in nightly, which we know you are using for your project because we gated all the features behind it") and a general sort of superiority towards npm when cargo/crates.io shares many of the same issues are the ones I ran into personally. And again, you don't have to be an expert to see these, but they're in this sweet spot between nonobvious and "something that'll go away if you use the language more".
  - k__ 6y ago
    "we know you are using [nightly] for your project because we gated all the features behind it" yes, that kinda sucks.
    - ansible 6y ago
      The asm!() to llvm_asm!() was a pain.
      - nindalf 6y ago
        Shouldn't it have been a simple find-and-replace?
steveklabnik 6y ago
Hey hey, this post is great! A few small comments: > It's not obvious to me why they do this – it's a documentation generator, why does it care what version of the Rust compiler I'm using? rustdoc, being a part of the Rust distribution, has the same stability guarantees that Rust does: once it gains a feature, it will never go away. We (well, not me I don't really work on rustdoc, to be clear) need the capacity to try out new features without committing to them, same as features in the language. > PyPI launched in 2003, and CPAN has been running since 1995 Neither of these support namespacing though, right? > Cargo's unit of distribution is the crate, which is a problem because Rust's compilation unit is also the crate. Cargo's unit of distribution is a package, which is one or more crates. It is true that there can only be one library crate per package, however. This is one area where people don't use the correct words super often, honestly. > Of course build times are slow if changing one line of a leaf file requires rebuilding dozens of modules. This shouldn't change based on if you're using Cargo or not; if it's re-building dependencies every time you touch a file, that is a bug.
- jmillikin 6y ago
  > rustdoc, being a part of the Rust distribution, > has the same stability guarantees that Rust does: > once it gains a feature, it will never go away. We > (well, not me I don't really work on rustdoc, to be > clear) need the capacity to try out new features > without committing to them, same as features in the > language. I guess I expect rustdoc and rustc to be much less tightly coupled, so that I could use (for example) stable rustc and nightly rustdoc on the same code. In the current model, I can't use nightly rustdoc features without also using nightly rustc, because the annotations are processed by both systems. You could imagine an alternate model where rustc stabilizes `#[doc(...)]` and leaves everything in there up to rustdoc's interpretation, and nightly rustdoc might enable new parameters to the #[doc] annotation. > Neither of these support namespacing though, right? That's correct. I meant that mostly in terms of "package registries are not a new and untested idea". It's like using strings for file paths: not obviously a bad idea, turns out to be unworkable for obscure reasons, and as a new language Rust got to avoid that particular mistake. It feels like crates.io didn't (/ doesn't) have a similar process of avoiding known mistakes. > This shouldn't change based on if you're using Cargo > or not; if it's re-building dependencies every time > you touch a file, that is a bug. Given a crate with a hundred files, each one fairly independent of the other (i.e. a broad shallow build graph), changing one requires (if I understand rustc correctly) recompiling them all. Otherwise the `crate::` references can't be type-checked.
adamnemecek 6y ago
Unix-stuff as a part of the standard library is a terrible idea. Making your own crate is simple enough. Same with OS-dependent functionality. Re: crates namespaces, that is a crates decision, not necessarily Rust'. You can always publish your crate on github and include it with "package = { git = ... }" and you'll get the same thing as in go.
- jmgao 6y ago
  Why is that not true for the rest of the standard library? You don't really need a HashMap in your standard library, or mutexes, just a memory allocator and atomics.
  - steveklabnik 6y ago
    Historically, the criteria for inclusion in the standard library is, does it fall under one of these three categories: * Used in the vast majority of Rust programs. * Reasonably common things that require a lot of unsafe to implement. * Traits for interoperation purposes. HashMap and mutexes fall under #2. The idea is that they'll receive significantly more scrutiny, and this is a good thing for the ecosystem. (These are guidelines, not hard and fast rules, so not literally everything fits here, but that's the framework that was used to think about what should be included or not, generally.)
    - ChrisSD 6y ago
      To be honest I think #2 was applied a bit too broadly. Sure rustc gets scrutiny but the std isn't the easiest library to contribute to. Not only is it large (by rust crate standards) but it's also tied to the compiler which adds another barrier to contributions. Mind you, increasingly parts of the std are more like wrappers around third party crates e.g. hashbrown and parking_lot.
      - steveklabnik 6y ago
        Yes, I think this calculus changes over time. Back in the day, I think this reason was more important than it is now.
erickt 6y ago
> Closed-world ("sealed") traits. Rust's rules against private types in the public API are good civilization but they make it difficult to define pseudo-private traits like Mount that I want users to name but not implement or call into. Rust actually supports sealed traits by using public traits in private modules. See this for how to use it, and how it works: https://rust-lang.github.io/api-guidelines/future-proofing.html https://rust-lang.github.io/api-guidelines/future-proofing.h...
- jmillikin 6y ago
  I'm aware of that workaround and do use it in `rust-fuse`[0], but I'm not satisfied for two reasons: * It's not understood by rustdoc, so I have to manually document that the trait is sealed. * It technically violates Rust's rules against private symbols in the public API, so a future version of rustc might deprecate or remove that functionality. [0] https://github.com/jmillikin/rust-fuse/blob/a6ad16d1127d36f80e6d02f36e48da56920ca693/fuse/src/server.rs#L53-L57 https://github.com/jmillikin/rust-fuse/blob/a6ad16d1127d36f8...
  - swsieber 6y ago
    I could see it being deprecated with an edition transition and a blessed solution.
  - oconnor663 6y ago
    > a future version of rustc might deprecate or remove that functionality Are you sure about this? My understanding is that stable Rust limits itself to compatibility breaks that are both rare and trivially worked around. (Like adding a new inherent method to a standard type that happens to have the same name as your trait method.) Even in a new edition, I think there's a very heavy leaning towards changes that can be automated by `cargo fix`. Removing this idiom seems like it would be much too big of a change. (The obvious automatic fix -- just inserting `pub` as needed -- would presumably make a bunch of currently safe APIs unsound.)
  - eddyb 6y ago
    > * It technically violates Rust's rules against private symbols in the public API, so a future version of rustc might deprecate or remove that functionality. It's public though, just not externally reachable, the private module doesn't make the trait private. For example, if you wanted to, you could reexport the trait in the parent module (and I guess the drawback with the "sealed" pattern is accidentally doing that when it would be unsound do because of how you relied on it being "sealed", in unsafe code). I don't think I've heard anything about plans to restrict anything based on reachability, and it would be massively backwards-incompatible so I doubt it would even be considered for an edition.
anonova 6y ago
I find it absolutely frustrating that Rust packaging/crates.io doesn't support namespaces. The arguments I've read are always theoretical/what ifs, but I've yet to be convinced the current situation is better than the practical benefits of namespaces.
- TheCycoONE 6y ago
  Conversely the arguments I've heard for namespaces is that multiple people want to reimplement or make bindings for the same C library. In maven central, in my anecdotal experience, namespaces usually either distinguish forks of the same library, or to group related libraries. There has never been, in my experience, a case where I wanted two packages with the same name in different namespaces. I think a better system of handling unmaintained crates; with the possibility of reclaiming a name would go a long way with the author's use case. I don't have any great ideas here: package with no update in some time (a year?) is eligible. Someone requests to take over name - the author is notified and has a period of time to click an "I'm still here" button. If they don't - new author gets the name. Some 'super version' number is incremented so crate authors opt into the new or old foo. That last part is where I'm the most hesitant.
  - mlindner 6y ago
    There's a bigger problem that someone has reserved a ton of common names and they're all empty projects with nothing in them.
    - viraptor 6y ago
      Or even in a non-malicious case: https://crates.io/crates/logger https://crates.io/crates/logger "logger" is now forever a middleware for the iron framework. Same with "router". Iron is pretty much obsolete now.
    - rat87 6y ago
      that sounds like a good thing. It might have been good if the rust team themseleves had pre-squated get rid of all the common names arguments and have everyone use prefixed or unique names
svnpenn 6y ago
This guys website is weird. I first noticed as scrolling doesnt work with the keyboard. Upon inspection of HTML hes using weird shadow dom stuff. Why do people do stuff like this? Its a static site, modern HTML and CSS are huge and can handle nearly any situation.
- rat9988 6y ago
  Scrolling works with keyboard. There is nothing weird about shadow dom, it's part of the standard.
  - ssokolow 6y ago
    That's like saying "There's nothing wrong with using setjmp/longjmp. It's part of the standard." I firmly believe that you shouldn't need client-side JavaScript for anything fancier than things like progressively enhancing a form field into a clickable star-rating widget unless you're writing an actual "web app"... definitely not for a blog. I'm just glad the text of his articles remains readable under the influence of my default uMatrix settings, even if none of the site-navigation boilerplate is. Heck, if I thought it could be done without failing Lyndon Johnson's "the harm it would cause if improperly administered" test, I'd ask for laws that penalize people for pushing that sort of computating to the client where it can't be cached for more than just that one machine. They could be justified as a way to cut down on CO2 emissions. As-is, if I can ever find the time, I want to see how much performance gain and "model has desynced from visible rendering" resilience I can get in my Firefox by ripping out Tree Style Tab and replacing it with something that uses the sidebar's DOM as the authoritative data model, built using <details>/<summary> expander/collapser nesting. (I've already prototyped the HTML for that as a simple transformation of what Markdown or ReStructuredText renderers output for nested <ul> outlines.)
    - nybble41 6y ago
      This is one of the last sites that I would criticise for use of client-side JavaScript. It uses one small script to implement a few simple web components. The power required to run that script is negligible compared to what the browser itself requires merely to render static HTML. You probably produced more CO2 just breathing while writing that comment than can be cumulatively attributed to this script across all visitors to this site to date. The shadow-DOM thing svnpenn commented on is a red herring. It doesn't interfere with keyboard scrolling, which works perfectly well. The shadow DOM is merely used to isolate CSS styling rules so that they apply to an instance of a component rather than sharing a single global namespace. The elements are still rendered as part of the parent document.
wokwokwok 6y ago
Seems a little unfair to cargo to give it a scathing review when your alternative ecosystem is C++ or Haskell. The basic complaint boils down to "packages aren't namespaced" and "someone already took the 'fuse' package", which has been a long running controversy for exactly that name-squatting reason. However, Cargo is great. > Rust's default build system (Cargo) and package repository (crates.io) are the opposite. They combine the worst parts of Cabal/Hackage and NPM, resulting in a user experience that is somehow inferior to both. No. They don't. That's your opinion, not a fact, and I completely disagree. Lots of people disagree. Your arbitrary assertion is unsubstantiated and I reject it. :) Perhaps you meant "resulting in a user experience that I found somehow inferior to both". If you don't like it, and you prefer to use bazel, then by all means be welcome to do so... but I think a little bit of acknowledgement is in order that ... frankly, that behavior should be discouraged. We want a unified good build system for rust, not a ridiculous mess of difference package managers and build systems like in some other language ecosystems. Sometimes, conformity is a better approach, and I would be deeply saddened to see rust go that way. I'm very impressed with the efforts to bring wasm support to cargo, and the other initiatives. Be nice. Lots of people work really hard on cargo. They're doing a great job.
- nsm 6y ago
  > We want a unified good build system for rust, not a ridiculous mess of difference package managers and build systems like in some other language ecosystems. Sometimes, conformity is a better approach, and I would be deeply saddened to see rust go that way. I would like to disagree on this. I would prefer to see the Rust ecosystem play better with other build systems, instead of requiring all Rust to use Cargo. This becomes important when you are using Rust as part of a larger, multi-language code base. At my day job, we have Rust, Python and Typescript, and we use Bazel for much of the build, getting a bunch of advantages that Bazel brings to the table - remote caching, being able to query the dependency graph, selective testing and so on. These latter are not available in cargo, and would be significant work to re-implement infrastructure based on querying cargo instead of querying bazel. I think there are 3 different things that Cargo tries to do, which would be better of with strong (and well documented) boundaries between them, so that users could mix and match each of these. 1. Compiling a crate - This is usually one rustc call. I'd venture saying that build.rs files are another layer, but I haven't thought about it enough. It is pretty common in Bazel-land to have build.rs wrapped in a `rust_binary` that is a dependency for the crate itself (usually `rust_library`). This is the easiest to plug into other build systems. 2. Compiling a set of crates/packages - Assuming a system where all the crates are on-disk, Cargo does the job of invoking rustc correctly with the dependencies passed and the right set of features selected. For Bazel, this is what rules_rust implements. The thing is, rules_rust has to figure this out by inspection of Cargo, instead of being able to rely on editions or compiler versions. (FYI, I've never used rules_rust. We have our own internal rules for Rust and we had to figure out things by inspection. Particularly Cargo specific environment variables that are not a part of the Rust language/stdlib, but are assumed to exist by libraries). 3. Package management - i.e. how to get dependencies from the network/someplace else onto disk. I'd suspect this is one place most large orgs would prefer not to rely on Cargo, because it necessarily locks them into some kind of delivery mechanism that is specific to the ecosystem, instead of having a dumb file server. i.e. we would need one for npm/yarn, one for pypi and so on, where each of these frontends know how to go from the "language package name" to the file on disk. I much prefer Bazel here where external dependencies are specified just by HTTP URLs and a sha256 hash to verify contents. I'm almost _not_ on board with each language building their own compiler driver and package manager, because they end up duplicating so much work - some kind of caching mechanism, some kind of toolchain mechanism, some kind of resolver mechanism and so on...
Ericson2314 6y ago
Yes thank you for not fauning over Cargo like many other reviews. The simple fact is Cargo did not learn from prior art to the extent Rust did. Things have gotten better, but Rust is still better designed. Hopefully Cargo can someday catch up.
- kibwen 6y ago
  If this is referring to namespacing, that's a crates.io concern, not a Cargo concern. Cargo is fully capable of using other registries, and there's nothing stopping those registries from using namespaces to organize and disambiguate crates.
  - Ericson2314 6y ago
    I'm not referring to namespacing in particular, which indeed doesn't concern me so much for those reasons.
- avasthe 6y ago
  I would be curious to hear what are your criticisms of cargo, too. Recently I am trying to study about dependency management in different languages, and cargo, along with bundler seems to be praised quite a bit. I can't correlate it with quality because both rust and ruby camps are quite vocal.
breatheoften 6y ago
An insufficient auto-formatter is very frustrating ... I think there are very smart older programmers who don't appreciate this fact properly. They sort of have a belief that there does not exist a "sufficiently good" good code formatter for all users -- and so therefore code formatter should have tons of configuration options to satisfy a range of style choices. I think that opinion belongs in the past (with the discussion of tabs vs spaces). We have witnessed the existence of sufficiently high quality opinionated code formatters (java, gofmt, prettier, ...) -- and these code formatters without style choices produce a better world. The way to get there is to find and prefer the non controversial formatting choices -- that means style preferences are abstracted away and consensus building grows from examples of code that everyone agrees is wrong and wants to fix. The rust formatting issue he highlights makes me really annoyed -- the format chosen by the auto formatter for that sample code is not the best for that situation -- and I'm pretty sure it would be non-controversial for folks to agree on that ... am i right? I'm doing some swift in xcode after awhile using an ide that lets me have "reformat on save" and the experience of "reformat on save" is good enough that I think it probably should be adopted as a first class goal of language designers -- there should be a language level "reformat on save" story that language designers assume will be used ... Baking in reformat on save as an assumed feature at language design time could allow creation or recovery from "write only" syntaxes -- (nice to write but ambiguous to read) -- either added on purpose or by mistake. Would also allow for really powerful Language evolution cleanup opportunities and the opportunity to introduce semantic changes where old functionality is preserved with complete compatibility until the source file is interactively edited from within an editor (eg the semantic change produces a code diff) ...
- da39a3ee 6y ago
  Whether reformat is called on save is up to your text editor and has nothing to do with the language.
  - breatheoften 6y ago
    Yes but there is no reason a language ecosystem can't assumes that this functionality is present, implemented in canonical form, and that it is a language use error not to enable. If the language designers assume the capability exists and will be used -- they can specifically evolve the language based on this assumption. All thats needed is a super high quality, compiler-provided implementation of the functionality -- and to set the expectation -- "sorry you have to wire this functionality up -- otherwise your code is going to be more likely to break if you edit the source files over time while also upgrading your compiler over time." I'm benoaning the fact that no languages I'm aware of have advertised such a position as part of their evolution plan ...
zamalek 6y ago
> I eventually gave up on trying to make the formatted rust-fuse code look pretty, and settled for "consistent". Even though it's a bit ugly, this is a big win. As for why it does this, from my experience, rust-fmt will try to keep lines under a column limit but not greedily. e.g. if a params list would extend past the limit, then all params get a newline. It seems to try to balance horizontal estate and vertical estate and I've become used to that (even though it is inconsistent at times). Any formatting rule is going to fall over eventually. Rust-fmt seems to make sane choices the majority of the time.
- cgrealy 6y ago
  Consistency > prettiness
  - berkut 6y ago
    Is it just prettiness though? When I worked in the defence industry (~15 years ago now), a lot of the coding standards for C/C++ (which was starting to be used more and more over ADA at the time) were very strict on the matching alignment of things like open / closing braces, so things like hanging braces were not allowed, both opening and closing braces had to be on their own lines. The argument behind this was it made the code clearer, and more easy to match clauses / scoping - in a way arguing it was "safer" in terms of interpretation of the code.
    - hurrrrrrrr 6y ago
      Maybe, maybe not. Is the potential benefit even worth fighting over? Style is just full of so many subjective details that every discussion ends in. And everybody has their favorite it's un-fucking-readable. My oppinion converged on "Fight it out and tell me what options in $formatter I need to set. Don't even tell me reasonings, just the options. leaves room". I'd rather drink coffee than have the next horizontal real estate vs. parameter alignment debate. The argument to match clauses/scoping for example is weird in a world where a formatter automatically applies indentation. It might make sense when you have to manually check them on print-outs without an Editor. I'd argue GNU style fulfills that role even better or Horstmann if you care about vertical real estate (or be daring and combine the two). And now everyone hates me.
pcwalton 6y ago
You should be able to get the size of c_ulong without any dependencies using std::mem::size_of::<std::os::raw::c_ulong>(). I usually use std::os::raw instead of the libc dependency in my own crates, even though some people consider it bad style to do so. (Working in graphics it's often the case that I don't need anything from libc except a few data types.) Another note: The notion of a "compilation unit" in Rust is fuzzier than in C/C++, because of incremental compilation. The goal is to be able to point rustc at a crate and have rustc/cargo internally decide which parts of it should be recompiled and which can be cached. A good chunk of this is already done today—for example, rustc will internally split up single crates into multiple LLVM compilation units to get better parallelism during the codegen phase—but more can definitely be done. Basically, Rust leans more on "compiler heroics" than C/C++ traditionally has, in that the compiler effectively splits up source files automatically instead of the programmer manually doing so.
- jmillikin 6y ago
  > You should be able to get the size of c_ulong without > any dependencies using > std::mem::size_of::<std::os::raw::c_ulong>(). That's very useful, thank you! I hadn't noticed `std::os::raw` before, but it's exactly what I wanted.
wereHamster 6y ago
> [In Haskell] I spent a lot of time debugging dangling pointers and race conditions. Uhm, ok, pointers in Haskell… must be really low-level programming, because ordinary Haskell doesn't deal with pointers.
- jmillikin 6y ago
  For a self-contained example, see https://github.com/jmillikin/haskell-ncurses/blob/master/lib/UI/NCurses.chs https://github.com/jmillikin/haskell-ncurses/blob/master/lib... My Haskell binding to CPython is larger but of about the same shape.
AbuAssar 6y ago
Author’s opinion on rust: "I really really enjoy using Rust. It is nearly everything I want in a systems programming language, and the few parts it's missing are due to legitimate technical difficulty. The amount of careful thought I've seen put into its design – crafting async/await to work in no_std environments, or the new inline assembly syntax – has produced a language that is not only better than what I could have designed, it's better among axes I was not even aware existed prior to reading the Rust RFCs."
quietbritishjim 6y ago
> it doesn't even properly align the parenthesized expression after line-breaking it: Fair enough if that's not your preference for how parenthesized expressions should be broken across lines, but this quote makes it seem like it's objectively wrong. In fact it's very much a matter of opinion, and personally I hate the style of line breaking that he describes as "properly" aligned because you end up with a distracting pattern of indentation, and parameters get all squished into a tall narrow column: x = long_function_name(first_param, second_param, another_fn(x + y + z)) Yuck! In Clang-format, you can avoid this with the "AlignAfterOpenBracket: AlwaysBreak" option, which also wraps the first parameter / operand to the next line if it can't all fit onto one line: x = long_function_name( first_param, second_param, another_fn(x + y + z)) Just to reiterate: I appreciate that many people would still prefer the first style, and of course that's a legitimate opinion. My point is just that it's also a legitimate opinion to prefer the second style, not something you can describe as "not properly aligned". Of course this is a nitpick on an excellent article.
- rkangel 6y ago
  This was the key line: > I eventually gave up on trying to make the formatted rust-fuse code look pretty, and settled for "consistent". It turns out that most aspects of coding style are subjective and are fine once you get used to them. The *-fmt tools that are now the fashion get everyone past that initial stage of formatting things as you personally would and get you used to a common style. Maybe one person (the author of the style tool) is completely happy with the chosen style, but consistent is more important than personal preference on details.
  - arethuza 6y ago
    One thing I've learned over the years using a lot of different languages is to pretty much ignore my initial reaction to syntax or formatting conventions for any given language - there is a pain period and then you get used to things and move on... Edit: I'm particularly thinking of PostScript, Lisp and Python - which on first impression seemed crazy but I actually learned to really like.
panzerklein 6y ago
Suggestion for page styling: replace "overflow: scroll" with "overflow: auto" to get rid of unnecessary scrollbars in code blocks. Unless you like them the way they are, of course.
- jmillikin 6y ago
  CSS and I have a strained relationship. https://mstdn.io/@jmillikin/103158451151123313 https://mstdn.io/@jmillikin/103158451151123313 I'll put this on the list of things to fix next time I go digging at the stylesheet.
EamonnMR 6y ago
I'm surprised they didn't mention the elephant in the room: the borrow checking, boxes, and other ways that the code forces you to do the work of making sure your code is bug free before it will compile.
- ragnese 6y ago
  Probably because that's the entire point of Rust and has already been blogged to death. There's nothing new to say about the borrow checker or boxing heap-allocated objects.
Fiahil 6y ago
After working on rust for almost 2 years, I finally reached a point where I can see (and wait for) a few improvements. First is completing the `impl Trait` saga. I see a couple of areas where I'm obliged to box a trait to get the compiler to accept the code. Not the end of the world. Second is allowing conversions of AsyncRead to Stream. currently you have to do a weird dance to get chunks of tokio::File as Stream of Bytes. I think something is missing. Something as straightforward should be easy even if it's not part of std. Last, is adding support for Generators and their transformation into Stream. Then, getting a Stream of Val would be as simple as `yield val` in a function. I'm sure their current API on nightly will change before it's merged to stable rust, and I even hope they will get rid of the "return type" in gens (it complicates things a little bit). After that last point, I can see Rust replacing python for most of the data prep work we have in data science/AI.
boris 6y ago
> I've found Bazel and rules_rust provide a good alternative to Cargo, since Bazel can twist your build into any DAG you want, but most Rust users are unlikely to be excited about injecting 50MB of Java build system into the middle of their workflow. If anyone is interested in another alternative to Cargo that doesn't involve Java, there is build2[1] and it's libbuild2-rust[2] module. It's a general-purpose build system so you can have mixed-language projects, etc. [1] https://build2.org https://build2.org [2] https://github.com/build2/libbuild2-rust https://github.com/build2/libbuild2-rust
jganetsk 6y ago
> Closed-world ("sealed") traits. Rust's rules against private types in the public API are good civilization but they make it difficult to define pseudo-private traits like Mount that I want users to name but not implement or call into. What about a public type with no public fields nor public methods? Doesn't that accomplish exactly what the author is looking for?

274 points by jmillikin 6y ago

Once a Rustacean always a Rustacean - a first impression will inevitably lead you down a never ending road but luckily there is a great community to support you.

rsa25519 6y ago
Definitely. I must admit, I came to Rust with a lot of baggage from other languages. I've learned a lot from reading about why Rust doesn't let me do things, often causing me to no longer do those things in other languages.
ncmncm 6y ago
I gave Rust a good solid tryout. It turned out to be insufficiently expressive to put into libraries the semantics I want to encapsulate. I went back to C++, and have been very happy. (It's also nice that lots of people want to pay to have it done.) As with Rust, I can write 2000 lines and, once it compiles, it works. The hardest thing about going back to C++ from Rust was getting used to putting semicolons where Rust doesn't require them. Years later it still trips me.
- supergirl 6y ago
  isn't C++ more like "once it compiles, it works, but later you discover 10 places where it segfaults"?
  - jdashg 6y ago
    This really depends on your development style and experience, but not in general, no.
  - brutt 6y ago
    Yep. It's why Mozilla invented Rust in first place.
  - ncmncm 6y ago
    That is how the propaganda goes. But in modern C++ style, memory errors just don't have many opportunities to happen. I.e., with the more powerful libraries C++14 and up enables, there is little temptation to drop to a risky level. And, anywhere you choose to, you can give it your full attention. So, overwhelmingly the bugs you do get are specification bugs: the code does what was asked, but the ask was wrong. The only way to avoid those is to pay attention. Anything that steals attention generates them, in C++ as in Rust. Old, pre-C++11 codebases (and codebases still written that way, or in C-with-classes style) suffer more. Mozilla and Google have a lot of old code.
    - ncmncm 6y ago
      You can down-vote all you like, but it remains true all the same.
  - ufmace 6y ago
    Kinda yeah, but more worryingly, 10 years later you discover it had an exploitable buffer overflow vulnerability the whole time. Now you have no idea who else has known about it, how long they've known, what systems they've compromised in what way using it, etc.
- twic 6y ago
  What couldn't you express satisfactorily?
  - ncmncm 6y ago
    Almost every feature of C++ is there to aid making powerful libraries. It has dozens that Rust lacks, more added with each Standard, and they work in synergy. The primordial enabler in '98 was template partial specialization, that made the STL possible: same name with different types uses a different implementation.

deleted 6y ago

[deleted]

thenewwazoo 6y ago

I went into this expecting yet another barrage of complaints about lifetimes, but was very pleasantly surprised. This is probably one of the most thoughtful experienced-programmed new-to-Rust reviews I've read in a long, long time. I frankly don't have much to add, except to say that, once you really understand the language and start building complex projects, this article really does describe the real issues you run into.

saagarjha 6y ago
I think I am familiar with Rust–I spent a week or so working with it–and I ran into many of these exact issues. I appreciate it very much when someone can give a viewpoint of of using a language beyond the superficial one ("arrays start at one in Lua"), or complains about something core to the language ("C pointers are confusing") and actually says something you will run into but is not obvious from having a basic knowledge of the thing ("while Python supports functional programming, it does not do so very well"). Rust's (intentionally) anemic standard library, strange dance around nightly ("we never break things…except in nightly, which we know you are using for your project because we gated all the features behind it") and a general sort of superiority towards npm when cargo/crates.io shares many of the same issues are the ones I ran into personally. And again, you don't have to be an expert to see these, but they're in this sweet spot between nonobvious and "something that'll go away if you use the language more".
- k__ 6y ago
  "we know you are using [nightly] for your project because we gated all the features behind it" yes, that kinda sucks.
  - ansible 6y ago
    The asm!() to llvm_asm!() was a pain.
    - nindalf 6y ago
      Shouldn't it have been a simple find-and-replace?

steveklabnik 6y ago

Hey hey, this post is great! A few small comments: > It's not obvious to me why they do this – it's a documentation generator, why does it care what version of the Rust compiler I'm using? rustdoc, being a part of the Rust distribution, has the same stability guarantees that Rust does: once it gains a feature, it will never go away. We (well, not me I don't really work on rustdoc, to be clear) need the capacity to try out new features without committing to them, same as features in the language. > PyPI launched in 2003, and CPAN has been running since 1995 Neither of these support namespacing though, right? > Cargo's unit of distribution is the crate, which is a problem because Rust's compilation unit is also the crate. Cargo's unit of distribution is a package, which is one or more crates. It is true that there can only be one library crate per package, however. This is one area where people don't use the correct words super often, honestly. > Of course build times are slow if changing one line of a leaf file requires rebuilding dozens of modules. This shouldn't change based on if you're using Cargo or not; if it's re-building dependencies every time you touch a file, that is a bug.

jmillikin 6y ago
> rustdoc, being a part of the Rust distribution, > has the same stability guarantees that Rust does: > once it gains a feature, it will never go away. We > (well, not me I don't really work on rustdoc, to be > clear) need the capacity to try out new features > without committing to them, same as features in the > language. I guess I expect rustdoc and rustc to be much less tightly coupled, so that I could use (for example) stable rustc and nightly rustdoc on the same code. In the current model, I can't use nightly rustdoc features without also using nightly rustc, because the annotations are processed by both systems. You could imagine an alternate model where rustc stabilizes `#[doc(...)]` and leaves everything in there up to rustdoc's interpretation, and nightly rustdoc might enable new parameters to the #[doc] annotation. > Neither of these support namespacing though, right? That's correct. I meant that mostly in terms of "package registries are not a new and untested idea". It's like using strings for file paths: not obviously a bad idea, turns out to be unworkable for obscure reasons, and as a new language Rust got to avoid that particular mistake. It feels like crates.io didn't (/ doesn't) have a similar process of avoiding known mistakes. > This shouldn't change based on if you're using Cargo > or not; if it's re-building dependencies every time > you touch a file, that is a bug. Given a crate with a hundred files, each one fairly independent of the other (i.e. a broad shallow build graph), changing one requires (if I understand rustc correctly) recompiling them all. Otherwise the `crate::` references can't be type-checked.

adamnemecek 6y ago

Unix-stuff as a part of the standard library is a terrible idea. Making your own crate is simple enough. Same with OS-dependent functionality. Re: crates namespaces, that is a crates decision, not necessarily Rust'. You can always publish your crate on github and include it with "package = { git = ... }" and you'll get the same thing as in go.

jmgao 6y ago
Why is that not true for the rest of the standard library? You don't really need a HashMap in your standard library, or mutexes, just a memory allocator and atomics.
- steveklabnik 6y ago
  Historically, the criteria for inclusion in the standard library is, does it fall under one of these three categories: * Used in the vast majority of Rust programs. * Reasonably common things that require a lot of unsafe to implement. * Traits for interoperation purposes. HashMap and mutexes fall under #2. The idea is that they'll receive significantly more scrutiny, and this is a good thing for the ecosystem. (These are guidelines, not hard and fast rules, so not literally everything fits here, but that's the framework that was used to think about what should be included or not, generally.)
  - ChrisSD 6y ago
    To be honest I think #2 was applied a bit too broadly. Sure rustc gets scrutiny but the std isn't the easiest library to contribute to. Not only is it large (by rust crate standards) but it's also tied to the compiler which adds another barrier to contributions. Mind you, increasingly parts of the std are more like wrappers around third party crates e.g. hashbrown and parking_lot.
    - steveklabnik 6y ago
      Yes, I think this calculus changes over time. Back in the day, I think this reason was more important than it is now.

erickt 6y ago

> Closed-world ("sealed") traits. Rust's rules against private types in the public API are good civilization but they make it difficult to define pseudo-private traits like Mount that I want users to name but not implement or call into. Rust actually supports sealed traits by using public traits in private modules. See this for how to use it, and how it works: https://rust-lang.github.io/api-guidelines/future-proofing.html https://rust-lang.github.io/api-guidelines/future-proofing.h...

jmillikin 6y ago
I'm aware of that workaround and do use it in `rust-fuse`[0], but I'm not satisfied for two reasons: * It's not understood by rustdoc, so I have to manually document that the trait is sealed. * It technically violates Rust's rules against private symbols in the public API, so a future version of rustc might deprecate or remove that functionality. [0] https://github.com/jmillikin/rust-fuse/blob/a6ad16d1127d36f80e6d02f36e48da56920ca693/fuse/src/server.rs#L53-L57 https://github.com/jmillikin/rust-fuse/blob/a6ad16d1127d36f8...
- swsieber 6y ago
  I could see it being deprecated with an edition transition and a blessed solution.
- oconnor663 6y ago
  > a future version of rustc might deprecate or remove that functionality Are you sure about this? My understanding is that stable Rust limits itself to compatibility breaks that are both rare and trivially worked around. (Like adding a new inherent method to a standard type that happens to have the same name as your trait method.) Even in a new edition, I think there's a very heavy leaning towards changes that can be automated by `cargo fix`. Removing this idiom seems like it would be much too big of a change. (The obvious automatic fix -- just inserting `pub` as needed -- would presumably make a bunch of currently safe APIs unsound.)
- eddyb 6y ago
  > * It technically violates Rust's rules against private symbols in the public API, so a future version of rustc might deprecate or remove that functionality. It's public though, just not externally reachable, the private module doesn't make the trait private. For example, if you wanted to, you could reexport the trait in the parent module (and I guess the drawback with the "sealed" pattern is accidentally doing that when it would be unsound do because of how you relied on it being "sealed", in unsafe code). I don't think I've heard anything about plans to restrict anything based on reachability, and it would be massively backwards-incompatible so I doubt it would even be considered for an edition.

anonova 6y ago

I find it absolutely frustrating that Rust packaging/crates.io doesn't support namespaces. The arguments I've read are always theoretical/what ifs, but I've yet to be convinced the current situation is better than the practical benefits of namespaces.

TheCycoONE 6y ago
Conversely the arguments I've heard for namespaces is that multiple people want to reimplement or make bindings for the same C library. In maven central, in my anecdotal experience, namespaces usually either distinguish forks of the same library, or to group related libraries. There has never been, in my experience, a case where I wanted two packages with the same name in different namespaces. I think a better system of handling unmaintained crates; with the possibility of reclaiming a name would go a long way with the author's use case. I don't have any great ideas here: package with no update in some time (a year?) is eligible. Someone requests to take over name - the author is notified and has a period of time to click an "I'm still here" button. If they don't - new author gets the name. Some 'super version' number is incremented so crate authors opt into the new or old foo. That last part is where I'm the most hesitant.
- mlindner 6y ago
  There's a bigger problem that someone has reserved a ton of common names and they're all empty projects with nothing in them.
  - viraptor 6y ago
    Or even in a non-malicious case: https://crates.io/crates/logger https://crates.io/crates/logger "logger" is now forever a middleware for the iron framework. Same with "router". Iron is pretty much obsolete now.
  - rat87 6y ago
    that sounds like a good thing. It might have been good if the rust team themseleves had pre-squated get rid of all the common names arguments and have everyone use prefixed or unique names

svnpenn 6y ago

This guys website is weird. I first noticed as scrolling doesnt work with the keyboard. Upon inspection of HTML hes using weird shadow dom stuff. Why do people do stuff like this? Its a static site, modern HTML and CSS are huge and can handle nearly any situation.

rat9988 6y ago
Scrolling works with keyboard. There is nothing weird about shadow dom, it's part of the standard.
- ssokolow 6y ago
  That's like saying "There's nothing wrong with using setjmp/longjmp. It's part of the standard." I firmly believe that you shouldn't need client-side JavaScript for anything fancier than things like progressively enhancing a form field into a clickable star-rating widget unless you're writing an actual "web app"... definitely not for a blog. I'm just glad the text of his articles remains readable under the influence of my default uMatrix settings, even if none of the site-navigation boilerplate is. Heck, if I thought it could be done without failing Lyndon Johnson's "the harm it would cause if improperly administered" test, I'd ask for laws that penalize people for pushing that sort of computating to the client where it can't be cached for more than just that one machine. They could be justified as a way to cut down on CO2 emissions. As-is, if I can ever find the time, I want to see how much performance gain and "model has desynced from visible rendering" resilience I can get in my Firefox by ripping out Tree Style Tab and replacing it with something that uses the sidebar's DOM as the authoritative data model, built using <details>/<summary> expander/collapser nesting. (I've already prototyped the HTML for that as a simple transformation of what Markdown or ReStructuredText renderers output for nested <ul> outlines.)
  - nybble41 6y ago
    This is one of the last sites that I would criticise for use of client-side JavaScript. It uses one small script to implement a few simple web components. The power required to run that script is negligible compared to what the browser itself requires merely to render static HTML. You probably produced more CO2 just breathing while writing that comment than can be cumulatively attributed to this script across all visitors to this site to date. The shadow-DOM thing svnpenn commented on is a red herring. It doesn't interfere with keyboard scrolling, which works perfectly well. The shadow DOM is merely used to isolate CSS styling rules so that they apply to an instance of a component rather than sharing a single global namespace. The elements are still rendered as part of the parent document.

wokwokwok 6y ago

Seems a little unfair to cargo to give it a scathing review when your alternative ecosystem is C++ or Haskell. The basic complaint boils down to "packages aren't namespaced" and "someone already took the 'fuse' package", which has been a long running controversy for exactly that name-squatting reason. However, Cargo is great. > Rust's default build system (Cargo) and package repository (crates.io) are the opposite. They combine the worst parts of Cabal/Hackage and NPM, resulting in a user experience that is somehow inferior to both. No. They don't. That's your opinion, not a fact, and I completely disagree. Lots of people disagree. Your arbitrary assertion is unsubstantiated and I reject it. :) Perhaps you meant "resulting in a user experience that I found somehow inferior to both". If you don't like it, and you prefer to use bazel, then by all means be welcome to do so... but I think a little bit of acknowledgement is in order that ... frankly, that behavior should be discouraged. We want a unified good build system for rust, not a ridiculous mess of difference package managers and build systems like in some other language ecosystems. Sometimes, conformity is a better approach, and I would be deeply saddened to see rust go that way. I'm very impressed with the efforts to bring wasm support to cargo, and the other initiatives. Be nice. Lots of people work really hard on cargo. They're doing a great job.

nsm 6y ago
> We want a unified good build system for rust, not a ridiculous mess of difference package managers and build systems like in some other language ecosystems. Sometimes, conformity is a better approach, and I would be deeply saddened to see rust go that way. I would like to disagree on this. I would prefer to see the Rust ecosystem play better with other build systems, instead of requiring all Rust to use Cargo. This becomes important when you are using Rust as part of a larger, multi-language code base. At my day job, we have Rust, Python and Typescript, and we use Bazel for much of the build, getting a bunch of advantages that Bazel brings to the table - remote caching, being able to query the dependency graph, selective testing and so on. These latter are not available in cargo, and would be significant work to re-implement infrastructure based on querying cargo instead of querying bazel. I think there are 3 different things that Cargo tries to do, which would be better of with strong (and well documented) boundaries between them, so that users could mix and match each of these. 1. Compiling a crate - This is usually one rustc call. I'd venture saying that build.rs files are another layer, but I haven't thought about it enough. It is pretty common in Bazel-land to have build.rs wrapped in a `rust_binary` that is a dependency for the crate itself (usually `rust_library`). This is the easiest to plug into other build systems. 2. Compiling a set of crates/packages - Assuming a system where all the crates are on-disk, Cargo does the job of invoking rustc correctly with the dependencies passed and the right set of features selected. For Bazel, this is what rules_rust implements. The thing is, rules_rust has to figure this out by inspection of Cargo, instead of being able to rely on editions or compiler versions. (FYI, I've never used rules_rust. We have our own internal rules for Rust and we had to figure out things by inspection. Particularly Cargo specific environment variables that are not a part of the Rust language/stdlib, but are assumed to exist by libraries). 3. Package management - i.e. how to get dependencies from the network/someplace else onto disk. I'd suspect this is one place most large orgs would prefer not to rely on Cargo, because it necessarily locks them into some kind of delivery mechanism that is specific to the ecosystem, instead of having a dumb file server. i.e. we would need one for npm/yarn, one for pypi and so on, where each of these frontends know how to go from the "language package name" to the file on disk. I much prefer Bazel here where external dependencies are specified just by HTTP URLs and a sha256 hash to verify contents. I'm almost _not_ on board with each language building their own compiler driver and package manager, because they end up duplicating so much work - some kind of caching mechanism, some kind of toolchain mechanism, some kind of resolver mechanism and so on...

Ericson2314 6y ago

Yes thank you for not fauning over Cargo like many other reviews. The simple fact is Cargo did not learn from prior art to the extent Rust did. Things have gotten better, but Rust is still better designed. Hopefully Cargo can someday catch up.

kibwen 6y ago
If this is referring to namespacing, that's a crates.io concern, not a Cargo concern. Cargo is fully capable of using other registries, and there's nothing stopping those registries from using namespaces to organize and disambiguate crates.
- Ericson2314 6y ago
  I'm not referring to namespacing in particular, which indeed doesn't concern me so much for those reasons.
avasthe 6y ago
I would be curious to hear what are your criticisms of cargo, too. Recently I am trying to study about dependency management in different languages, and cargo, along with bundler seems to be praised quite a bit. I can't correlate it with quality because both rust and ruby camps are quite vocal.

breatheoften 6y ago

An insufficient auto-formatter is very frustrating ... I think there are very smart older programmers who don't appreciate this fact properly. They sort of have a belief that there does not exist a "sufficiently good" good code formatter for all users -- and so therefore code formatter should have tons of configuration options to satisfy a range of style choices. I think that opinion belongs in the past (with the discussion of tabs vs spaces). We have witnessed the existence of sufficiently high quality opinionated code formatters (java, gofmt, prettier, ...) -- and these code formatters without style choices produce a better world. The way to get there is to find and prefer the non controversial formatting choices -- that means style preferences are abstracted away and consensus building grows from examples of code that everyone agrees is wrong and wants to fix. The rust formatting issue he highlights makes me really annoyed -- the format chosen by the auto formatter for that sample code is not the best for that situation -- and I'm pretty sure it would be non-controversial for folks to agree on that ... am i right? I'm doing some swift in xcode after awhile using an ide that lets me have "reformat on save" and the experience of "reformat on save" is good enough that I think it probably should be adopted as a first class goal of language designers -- there should be a language level "reformat on save" story that language designers assume will be used ... Baking in reformat on save as an assumed feature at language design time could allow creation or recovery from "write only" syntaxes -- (nice to write but ambiguous to read) -- either added on purpose or by mistake. Would also allow for really powerful Language evolution cleanup opportunities and the opportunity to introduce semantic changes where old functionality is preserved with complete compatibility until the source file is interactively edited from within an editor (eg the semantic change produces a code diff) ...

da39a3ee 6y ago
Whether reformat is called on save is up to your text editor and has nothing to do with the language.
- breatheoften 6y ago
  Yes but there is no reason a language ecosystem can't assumes that this functionality is present, implemented in canonical form, and that it is a language use error not to enable. If the language designers assume the capability exists and will be used -- they can specifically evolve the language based on this assumption. All thats needed is a super high quality, compiler-provided implementation of the functionality -- and to set the expectation -- "sorry you have to wire this functionality up -- otherwise your code is going to be more likely to break if you edit the source files over time while also upgrading your compiler over time." I'm benoaning the fact that no languages I'm aware of have advertised such a position as part of their evolution plan ...

zamalek 6y ago

> I eventually gave up on trying to make the formatted rust-fuse code look pretty, and settled for "consistent". Even though it's a bit ugly, this is a big win. As for why it does this, from my experience, rust-fmt will try to keep lines under a column limit but not greedily. e.g. if a params list would extend past the limit, then all params get a newline. It seems to try to balance horizontal estate and vertical estate and I've become used to that (even though it is inconsistent at times). Any formatting rule is going to fall over eventually. Rust-fmt seems to make sane choices the majority of the time.

cgrealy 6y ago
Consistency > prettiness
- berkut 6y ago
  Is it just prettiness though? When I worked in the defence industry (~15 years ago now), a lot of the coding standards for C/C++ (which was starting to be used more and more over ADA at the time) were very strict on the matching alignment of things like open / closing braces, so things like hanging braces were not allowed, both opening and closing braces had to be on their own lines. The argument behind this was it made the code clearer, and more easy to match clauses / scoping - in a way arguing it was "safer" in terms of interpretation of the code.
  - hurrrrrrrr 6y ago
    Maybe, maybe not. Is the potential benefit even worth fighting over? Style is just full of so many subjective details that every discussion ends in. And everybody has their favorite it's un-fucking-readable. My oppinion converged on "Fight it out and tell me what options in $formatter I need to set. Don't even tell me reasonings, just the options. leaves room". I'd rather drink coffee than have the next horizontal real estate vs. parameter alignment debate. The argument to match clauses/scoping for example is weird in a world where a formatter automatically applies indentation. It might make sense when you have to manually check them on print-outs without an Editor. I'd argue GNU style fulfills that role even better or Horstmann if you care about vertical real estate (or be daring and combine the two). And now everyone hates me.

pcwalton 6y ago

You should be able to get the size of c_ulong without any dependencies using std::mem::size_of::<std::os::raw::c_ulong>(). I usually use std::os::raw instead of the libc dependency in my own crates, even though some people consider it bad style to do so. (Working in graphics it's often the case that I don't need anything from libc except a few data types.) Another note: The notion of a "compilation unit" in Rust is fuzzier than in C/C++, because of incremental compilation. The goal is to be able to point rustc at a crate and have rustc/cargo internally decide which parts of it should be recompiled and which can be cached. A good chunk of this is already done today—for example, rustc will internally split up single crates into multiple LLVM compilation units to get better parallelism during the codegen phase—but more can definitely be done. Basically, Rust leans more on "compiler heroics" than C/C++ traditionally has, in that the compiler effectively splits up source files automatically instead of the programmer manually doing so.

jmillikin 6y ago
> You should be able to get the size of c_ulong without > any dependencies using > std::mem::size_of::<std::os::raw::c_ulong>(). That's very useful, thank you! I hadn't noticed `std::os::raw` before, but it's exactly what I wanted.

wereHamster 6y ago

> [In Haskell] I spent a lot of time debugging dangling pointers and race conditions. Uhm, ok, pointers in Haskell… must be really low-level programming, because ordinary Haskell doesn't deal with pointers.

jmillikin 6y ago
For a self-contained example, see https://github.com/jmillikin/haskell-ncurses/blob/master/lib/UI/NCurses.chs https://github.com/jmillikin/haskell-ncurses/blob/master/lib... My Haskell binding to CPython is larger but of about the same shape.

AbuAssar 6y ago

Author’s opinion on rust: "I really really enjoy using Rust. It is nearly everything I want in a systems programming language, and the few parts it's missing are due to legitimate technical difficulty. The amount of careful thought I've seen put into its design – crafting async/await to work in no_std environments, or the new inline assembly syntax – has produced a language that is not only better than what I could have designed, it's better among axes I was not even aware existed prior to reading the Rust RFCs."

quietbritishjim 6y ago

> it doesn't even properly align the parenthesized expression after line-breaking it: Fair enough if that's not your preference for how parenthesized expressions should be broken across lines, but this quote makes it seem like it's objectively wrong. In fact it's very much a matter of opinion, and personally I hate the style of line breaking that he describes as "properly" aligned because you end up with a distracting pattern of indentation, and parameters get all squished into a tall narrow column: x = long_function_name(first_param, second_param, another_fn(x + y + z)) Yuck! In Clang-format, you can avoid this with the "AlignAfterOpenBracket: AlwaysBreak" option, which also wraps the first parameter / operand to the next line if it can't all fit onto one line: x = long_function_name( first_param, second_param, another_fn(x + y + z)) Just to reiterate: I appreciate that many people would still prefer the first style, and of course that's a legitimate opinion. My point is just that it's also a legitimate opinion to prefer the second style, not something you can describe as "not properly aligned". Of course this is a nitpick on an excellent article.

rkangel 6y ago
This was the key line: > I eventually gave up on trying to make the formatted rust-fuse code look pretty, and settled for "consistent". It turns out that most aspects of coding style are subjective and are fine once you get used to them. The *-fmt tools that are now the fashion get everyone past that initial stage of formatting things as you personally would and get you used to a common style. Maybe one person (the author of the style tool) is completely happy with the chosen style, but consistent is more important than personal preference on details.
- arethuza 6y ago
  One thing I've learned over the years using a lot of different languages is to pretty much ignore my initial reaction to syntax or formatting conventions for any given language - there is a pain period and then you get used to things and move on... Edit: I'm particularly thinking of PostScript, Lisp and Python - which on first impression seemed crazy but I actually learned to really like.

panzerklein 6y ago

Suggestion for page styling: replace "overflow: scroll" with "overflow: auto" to get rid of unnecessary scrollbars in code blocks. Unless you like them the way they are, of course.

jmillikin 6y ago
CSS and I have a strained relationship. https://mstdn.io/@jmillikin/103158451151123313 https://mstdn.io/@jmillikin/103158451151123313 I'll put this on the list of things to fix next time I go digging at the stylesheet.

EamonnMR 6y ago

I'm surprised they didn't mention the elephant in the room: the borrow checking, boxes, and other ways that the code forces you to do the work of making sure your code is bug free before it will compile.

ragnese 6y ago
Probably because that's the entire point of Rust and has already been blogged to death. There's nothing new to say about the borrow checker or boxing heap-allocated objects.

Fiahil 6y ago

After working on rust for almost 2 years, I finally reached a point where I can see (and wait for) a few improvements. First is completing the `impl Trait` saga. I see a couple of areas where I'm obliged to box a trait to get the compiler to accept the code. Not the end of the world. Second is allowing conversions of AsyncRead to Stream. currently you have to do a weird dance to get chunks of tokio::File as Stream of Bytes. I think something is missing. Something as straightforward should be easy even if it's not part of std. Last, is adding support for Generators and their transformation into Stream. Then, getting a Stream of Val would be as simple as `yield val` in a function. I'm sure their current API on nightly will change before it's merged to stable rust, and I even hope they will get rid of the "return type" in gens (it complicates things a little bit). After that last point, I can see Rust replacing python for most of the data prep work we have in data science/AI.

boris 6y ago

> I've found Bazel and rules_rust provide a good alternative to Cargo, since Bazel can twist your build into any DAG you want, but most Rust users are unlikely to be excited about injecting 50MB of Java build system into the middle of their workflow. If anyone is interested in another alternative to Cargo that doesn't involve Java, there is build2[1] and it's libbuild2-rust[2] module. It's a general-purpose build system so you can have mixed-language projects, etc. [1] https://build2.org https://build2.org [2] https://github.com/build2/libbuild2-rust https://github.com/build2/libbuild2-rust

jganetsk 6y ago

> Closed-world ("sealed") traits. Rust's rules against private types in the public API are good civilization but they make it difficult to define pseudo-private traits like Mount that I want users to name but not implement or call into. What about a public type with no public fields nor public methods? Doesn't that accomplish exactly what the author is looking for?