[HN Gopher] Rust After the Honeymoon
___________________________________________________________________
Rust After the Honeymoon
Author : psanford
Score : 361 points
Date : 2020-10-11 17:31 UTC (5 hours ago)
(HTM) web link (dtrace.org)
(TXT) w3m dump (dtrace.org)
| vaylian wrote:
| > Steve is using Windows as his daily driver, in part because of
| his own personal dedication to keeping Rust multi-platform.
|
| Thanks Steve!
| brundolf wrote:
| Personally I used to think I couldn't develop comfortably on
| Windows, but Rust's tooling is so integrated under the Cargo
| umbrella that I've never run into a real issue getting it
| working there, and I rarely even find myself needing to do
| "real command-line" stuff while working with Rust. A single
| tool has it all covered, so I don't really have to write
| scripts or anything. I'm sure the story is less simple for
| embedded, but I'm not surprised it's totally doable.
| steveklabnik wrote:
| It's not that far off for embedded; Cargo's weaknesses here
| affect all platforms equally :)
| steveklabnik wrote:
| You're welcome!
|
| We have a Windows working group that does far more work than I
| do; honestly, I mostly am just a visible person who uses
| Windows, more than an expert or someone who fixes a lot of big
| problems. I do file bugs and patch things where I can.
| boulos wrote:
| This is a good list of positives. I'm surprised there's no
| mention of bitfields though.
|
| I like the u32::from_le_bytes and into() and so on, but I feel
| like Rust would be a perfect match for explicit "u3" types when
| dealing with low-level protocols.
|
| https://immunant.com/blog/2020/01/bitfields/ and similar articles
| show some options, but none of them feel as natural (ergonomics
| wise) or even as "safe" as a C bitfield checked by clang.
|
| bcantrill (or others): am I just missing something here?
| bcantrill wrote:
| No, you're not missing something -- this is an area that I
| would say is (to use a winter weather term) "unsettled." The
| Immunant blog entry you pointed to is quite good, and lays out
| all of the existing solutions and the issues with them. Better
| solutions are definitely possible here, and I'm confident that
| we'll see them over time. Especially given the incredible
| obstacles that Rust has overcome with respect to low-level
| software (e.g., no_std, asm!), making bitfields more ergonomic
| seems like a very reasonable aspiration, especially considering
| how many others see the same problem!
| boulos wrote:
| Re-reading the end of that post, I'm reminded that Josh had a
| talk about potential improvements.
|
| I only return to Rust about once or twice a year (currently)
| and keep cutting myself on an ergonomics thing like this. But
| I've also seen it improve year over year at a remarkable
| pace. So I'm hopeful, but also always wondering "huh, am I
| holding the phone wrong?".
| steveklabnik wrote:
| (I work with bcantrill)
|
| We use https://crates.io/crates/bitfield, and some of our
| dependencies use https://crates.io/crates/bitflags. They're not
| perfect, but they get the job done.
| boulos wrote:
| Disclaimer: I haven't used bitflags (but I don't think it
| applies for my need).
|
| The nginx example in the above blog post seems like a
| bitfield! equivalent would be... unpleasant.
|
| For very small structs that are just only wire formats, I
| might use bitfield!. But encoding/decoding protocol headers
| (e.g., a VP8 header [1], which has a 19-bit "size" field) or
| interop with other systems where you'd like some checking a
| la serde, bitfield! seems more verbose than "fine, I'll do it
| myself right here against the u8".
|
| That is, even if that nginx example had a two-bit field in
| there, I'd take everything at the end and round up to a u8.
| Then read/write some of these "by hand", rather than pollute
| the struct with lots and lots of macro "noise".
|
| [1] https://tools.ietf.org/html/rfc6386#section-9.1
| steveklabnik wrote:
| Yes, this is what I mean by "it's not perfect", there's
| totally things that could be better. All I'm saying is that
| this works out well enough for our particular needs
| generally, and isn't a giant pain point, so that's probably
| why it wasn't mentioned.
| cryptonector wrote:
| Be careful with C and bitfields, as they can be a minefield
| too. First, always use an unsigned integral type for them, and
| second, be careful with bitfield packing rules -- maybe just
| use 1-bit fields only even.
| Animats wrote:
| Nice. This is Rust for people programming machines of Arduino
| size.
| ohazi wrote:
| {:#x?}
|
| omg!
| [deleted]
| kibwen wrote:
| It's a formatting sublanguage based on the one from C#.
|
| In the formatting sublanguage, braces denote a value to be
| formatted: `format!("{foo}", foo=42)`
|
| Instead of a name you can identify values positionally,
| counting from zero: `format!("{0}", 42)`
|
| You can omit the identifier entirely and the arguments will
| likewise be interpreted as positional: `format!("{}", 42)`
|
| To tell the formatter the manner in which you would like to
| format the value, you can give format specifiers. These are
| separated from the value's identifier by a colon. An example of
| a format specifier is `b`, which prints the value in binary:
| `format!("{foo:b}", foo=42)`
|
| As before, you can leave out the name to refer to the value
| positionally: `format!("{:b}", 42)`
|
| Other format specifiers are `?`, which tells the formatter to
| print the "debug" output (i.e. autogenerated output useful for
| debugging by programmers), `#` which tells the formatter to
| insert line breaks and indentation for easier reading, and `x`
| which tells the formatter to print numbers as hex.
| masklinn wrote:
| > autogenerated output useful for debugging by programmers
|
| Nit: not necessarily autogenerated, we can implement Debug by
| hand. It's just that, as the name indicates, this is aimed at
| debugging output rather than the possibly-user-facing output
| of Display.
| kibwen wrote:
| Indeed, though it's worth driving home that the salient
| difference between Debug and Display is that the former,
| unlike the latter, _can_ be autogenerated via derive (well,
| okay, I 've seen crates that add the ability to derive
| Display based on doc comments, which is pretty cool:
| https://github.com/yaahc/displaydoc ).
| jabedude wrote:
| Right! I've been using Rust for ~2 years now and just found out
| about the pretty print format.
| furyofantares wrote:
| This is the kind of review I love to see. Not just for languages,
| everything. In my experience, reviews almost exclusively come
| while something is still novel to the reviewer, not battle
| tested, and worse, conflated with whatever situations the
| reviewer just happens to find themselves in at that period of
| time.
|
| What a wonderful post to be able to read and not have to wonder
| how much of it will hold up given a little time.
| saagarjha wrote:
| Of course, since these often take months of up-front effort
| it's obvious why they're not as common :(
| bananaface wrote:
| It's a shame, though. Content aggregators at least should
| allow the ones that exist to bubble up.
| Waterluvian wrote:
| Yes!!! I was looking at exercise equipment this week and badly
| wanted to find reviews for when people had been using it for
| years. That's where 98% of the useful info is.
|
| Otherwise reviews are pointless things like the packaging
| quality and shipment speed.
| kbenson wrote:
| You might have missed this[1], earlier this week. Probably
| doesn't have what you like _yet_ , but is along the lines of
| what you're wishing for.
|
| 1: https://news.ycombinator.com/item?id=24707407
| Waterluvian wrote:
| Thank you for sharing! Yes that is definitely touching on a
| big gap (startup opportunity!!!) that I've been seeking.
| Just a matter of time.
| noneeeed wrote:
| I was thinking about this today in reference to Elixir. I've
| noticed there seems to be less of the unalloyed fanboyism, and
| more realism in people's reported experiences with it now
| they've had a chance to use it for a few years. Reports still
| seem to be positive, but more balanced, which I think is the
| sign of a language ecosystem maturing.
|
| I generally take breathless coverage of how brilliant some new
| language (or tech stack) is with a large pinch of salt. The
| foibles and pitfalls of modern languages are often hard to spot
| until people have code-bases that are at least a couple of
| years old. I think the good stuff is generally easier to see at
| first, while the problems (which are often consequences/side-
| effects of the good aspects) generally take longer to appear.
|
| Programming languages seem to follow a variation of the Gartner
| Hype Cycle, with the twist that just after you get to the
| Plateau of Productivity and lots of people are quietly getting
| stuff done with it everyone starts to declare that "language X
| is dead/dying".
| cxr wrote:
| On the other hand, if you wait too long, you run the risk of
| being afflicted with the kind of Stockholm syndrome/curse of
| expertise that explains how bad so much of everything is.
|
| When I start playing with something, once the number of
| papercuts I'm tracking in my head gets above 2-3, then I crack
| open a fresh notes.markdown file adjacent to the source repo
| (if there is one) and start recording all my thoughts in the
| vein of[1], including everything from outright bugs to
| opportunities for UI improvement. If the project has reasonable
| bugtracking infrastructure, I'll file them--or for small
| projects, I'll email the author along with any patches--but
| since most projects don't, I mostly don't end up doing anything
| with them. I've often thought that it would be nice if this
| exercise of "Let's Critique" became a thing, though. If nothing
| else, it could provide fuel for folks' blogs that have been
| lying dormant since that one post from 2017.
|
| 1. https://pointersgonewild.com/2019/11/02/they-might-never-
| tel...
| pjmlp wrote:
| I disagree with the pleasure of asm macro.
|
| Nothing beats PC / Amiga inline Assembly code blocks / compiler
| intrisics.
| kibwen wrote:
| Do you have a source for comparison?
| pjmlp wrote:
| These ones for example.
|
| Delphi/Free Pascal, VC++ inline Assembly and intrisics.
|
| https://www.freepascal.org/docs-html/prog/progch3.html
|
| https://docs.microsoft.com/en-
| us/cpp/assembler/inline/asm?vi...
|
| https://docs.microsoft.com/en-
| us/cpp/intrinsics/intrinsics-a...
| yjftsjthsd-h wrote:
| Could you point to an example, or give a more precise thing for
| me to search for?
| pjmlp wrote:
| The PC / Amiga compilers used to allow for explicit inline
| syntax as part of the language.
|
| The frontend compiler is intelligent enough to understand
| Assembly, instead of blindly giving it to the backend, like
| it always happened on UNIX compilers with their separate
| phases as processes connected via pipes.
|
| Nowadays they have intrisics which are a mix of specific CPU
| ones, and others that are general purpose ones.
|
| Then the macro Assemblers that come with them are powerful
| enough to program almost C like code in Assembly.
|
| Check VC++ inline Assembly, intrisics and MASM.
|
| Borland had similar offerings with Pascal, C, C++ and TASM.
|
| Other PC and also on Amiga, had similar offerings.
| pitaj wrote:
| That's a huge tradeoff with compiler complexity. Not only can
| you have issues of syntax incompatibility, but you also have to
| implement the syntax for every assembly variant for every
| architecture you support.
| mrits wrote:
| I've jumped on plenty of hype trains of new languages over the
| last 20 years. Rust is the first one that made we actually worry
| that I might have to eventually switch back to different language
| in the future. In addition, it's the first language that doesn't
| have me use Python for quick shell scripting or small prototypes.
| It's a pleasure to code in.
| papaf wrote:
| _it 's the first language that doesn't have me use Python for
| quick shell scripting or small prototypes_
|
| How do you define quick? Python has a large standard library
| and so you don't have to hunt for functionality on crates.io
| and then download/compile -- I have written scripts faster than
| that.
| nicoburns wrote:
| If you know that a crate exists then you can simply `cargo
| add foo` and have it download in the background while you get
| on with writing your script. If you don't know that it exists
| then you'll have to find it the first time, but you have that
| problem with python standard library modules too.
|
| Writing scripts with Rust likely will be slower than Python,
| but I don't really buy that having functionality in crates is
| part of that.
| papaf wrote:
| _If you don 't know that it exists then you'll have to find
| it the first time, but you have that problem with python
| standard library modules too._
|
| Except that, if its in the standard library, you don't have
| to choose between multiple implementations. I have written
| scripts faster than I have chosen dependencies.
| [deleted]
| nicoburns wrote:
| If I want to make an HTTP request in Python, which module
| should I use? There is a built in one (more than one I
| believe), but the official docs link out to a 3rd party
| module https://docs.python.org/3/library/http.client.html
| papaf wrote:
| I think things are beginning to get a bit surreal. People
| arguing that Rust is a better scripting language than
| Python and now with one particular poor example in the
| Python standard library means the chaos of crates.io is a
| comparable solution in terms of reducing choice.
|
| Rust is a great C++ alternative. But seriously, the
| community has cult like marketing.
| pjmlp wrote:
| Rust might become a C++ alternative, but still has some
| catchup to do with 40 years of ecosystem maturity and
| this is the kind of stuff that gets overlooked when
| pitching newer languages.
| nicoburns wrote:
| FWIW, I agree with you that Python is better that Rust
| for scripting (I was not the OP), but finding a crate in
| Rust is generally a matter of googling "Rust http client"
| or "Rust regex" and reading the top result. Not exactly
| hard, and in my experience something that I end up doing
| in every single language including Python, because using
| the standard library directly is often not the correct
| choice.
| bluejekyll wrote:
| > But seriously, the community has cult like marketing.
|
| What in your opinion makes one language cult-like vs.
| another that many people like and recommend to others?
|
| Cults generally have a very negative impact on those who
| are members vs. the leaders. Usually the members of cults
| are taken advantage of and are only there to support the
| people at the top.
|
| The Rust community is very far from anything cult-like.
| mmcgaha wrote:
| The Python standard library is amazing. A few weeks ago, I
| wrote a program that provides a SMTP relay, mail storage, and
| web UI for managing email sequencing. The only dependency
| that it pulled in was pywin32 so it could run as a windows
| service; if it ran on a Linux box, there wouldn't be a single
| dependency.
|
| Not including integration testing, the whole deal was two
| days of work. If I had to pull in and evaluate external
| libraries I would have spent two days just working out the
| details of which libraries to select.
|
| At least for now, I don't think anything can replace Python
| for prototyping an idea.
| eloff wrote:
| I love rust, but Python is still my goto for scripting, small
| tasks, calculations, etc. It's more convenient for nearly all
| tasks of that shape.
|
| I remember telling my uni professor about that 15 years ago,
| but she swore by using C for that purpose. It's what you know I
| suppose, but if you know both languages, Python is much better
| suited to the task.
| bluejekyll wrote:
| > Python is much better suited to the task.
|
| This is not an objective opinion, but subjective. People
| generally appreciate different things about different
| languages, and it's entirely possible for some who knows both
| languages to disagree with you here.
|
| For quick CLI tools, my favorite thing about Rust is that it
| has really high quality command line parsers available in the
| community, and they are type safe.
|
| I'm not suggesting that your opinion is wrong, only that the
| way you phrased it implies that many people could come to the
| same objective opinion, while there's plenty of evidence that
| folks pick languages they enjoy and prioritize different
| things than you might.
| eloff wrote:
| There's this political correct thing where people act like
| there's no objective truth and everything is subjective.
|
| That's just not how reality works, there is usually an
| objective truth even when we can't agree on what it is. You
| can use a hammer and a screwdriver for putting screws into
| drywall, but one tool is objectively better, under most
| conditions, regardless of your personal opinion.
|
| Python is superior to C and Rust for most kinds of
| scripting tasks, given equal mastery of both. It has a
| REPL, it doesn't have a compile time, it has a great
| batteries included standard library. There are plenty of
| specific tasks that will be exceptions, but that's my
| subjective opinion. I also think it's closer to the
| objective truth - and that people who have a different
| opinion are simply wrong. I'm not afraid of calling it how
| I see it. I could be wrong here, but I don't think that's
| the smart money bet.
| steveklabnik wrote:
| I mean, I should probably turn this comment into a blog
| post, but https://news.ycombinator.com/item?id=22712441
|
| That Python and that Rust are not very far off from each
| other. Rust is _surprisingly_ good at these tasks for
| people who already know Rust. It 's not as far out as you
| seem to think.
|
| That being said, I am quite sure that Rust is not going
| to take over as a scripting language or something. But at
| the same time, it is not completely ridiculous to write
| some Rust for these sorts of tasks if you're already
| comfy, and if the libraries are there.
| eloff wrote:
| I shouldn't be surprised to see you defending Rust here
| :) I do see a lot of similarities between Rust and
| Python.
|
| I don't agree that it's better than Python for most short
| scripting tasks - but I will grant your point that it's
| not completely ridiculous either, not by a long shot.
| steveklabnik wrote:
| Honestly, I am surprised; if you go read my old Hacker
| News comments, you'll see me saying that I don't think
| Rust will ever make sense for the backend of websites. I
| have been pleasantly surprised as things have developed.
| eloff wrote:
| I don't have anywhere near your level of experience with
| Rust. But yeah that's been surprising to me too.
|
| I still think I'd rank it behind Go and Python for a
| typical website backend - but it depends on the project
| and the team.
|
| The more people involved, the more things the type system
| will save you from, and the more you benefit from being
| able to build powerful abstractions - which offsets the
| relatively higher "tax" on productivity with it.
|
| Rust is one of the better choices for backend web
| development today, a sentence I also find surprising just
| to write.
|
| Honestly, probably the biggest thing holding it back for
| that use case is not the language itself but lack of
| adoption. It's tougher to hire for, and has a less mature
| ecosystem. I feel the momentum is there and that will
| change over the next 5 years or so.
| steveklabnik wrote:
| Yep, I would agree with all of this.
|
| Some Oxide folks have talked about our experiences with
| Rust as web backend stuff, it's linked in the post but
| https://blog.jessfraz.com/post/the-automated-cio/ and
| https://twitter.com/ahl/status/1308421852931461126 We had
| to build a bunch of stuff because as you say, the
| ecosystem isn't super mature at times.
| bluejekyll wrote:
| > You can use a hammer and a screwdriver for putting
| screws into drywall, but one tool is objectively better,
| under most conditions, regardless of your personal
| opinion.
|
| This is a poor analogy. Programming languages are used
| for writing programs. You suggest that Python is
| objectively superior in one context "scripting" than
| other programming languages. There are languages that are
| not cross-platform, that would fit that, there are
| languages like PL/SQL that are limited to databases,
| those are not practical for many program development
| efforts. In this context, we're really talking about two
| different types of hammers, perhaps one has a claw and
| the other does not, but they are both fairly portable and
| can target nearly all the same platforms.
|
| But if Python is objectively better than these other
| general purpose languages, does that imply that there are
| areas where Python is not superior to these languages?
| Would it suggest that folks who've been successful even
| when choosing Python in those cases objectively made the
| wrong choice?
| pjmlp wrote:
| Actually, check Oracle Forms and APEX.
| eloff wrote:
| > In this context, we're really talking about two
| different types of hammers, perhaps one has a claw and
| the other does not, but they are both fairly portable and
| can target nearly all the same platforms.
|
| It's an analogy, but one tool is going to be faster and
| easier to use. So let's say a screwdriver vs an electric
| screwdriver.
|
| > But if Python is objectively better than these other
| general purpose languages, does that imply that there are
| areas where Python is not superior to these languages?
|
| Yes. There are a lot of areas where Python is inferior.
| In fact I'm using Rust right now for a project despite
| having over 15 years experience with Python. Programming
| languages are tools and they're better or worse suited to
| different tasks. There is no one language to rule them
| all - yet anyway.
|
| > Would it suggest that folks who've been successful even
| when choosing Python in those cases objectively made the
| wrong choice?
|
| Yes. That you were successful does not fully validate
| your decision about choice of programming language. It
| just means it wasn't that bad. It does not mean it was
| the optimal choice.
| bsaul wrote:
| Has there been any news on exporting a lib to be used by an
| android app ? Last time i checked, it was still painful to
| generate jni bindings.
|
| I'm dying to find a tech that would let me easily write a shared
| lib that targets web , android and ios, but so far everything
| seems very experimental wherever i look. Rust seemed to be the
| closest, but still a bit raw.
| steveklabnik wrote:
| Nothing specific has changed here recently, no.
|
| I _believe_ Cloudflare is doing this with the 1.1.1.1 app;
| maybe someone who is there will see this and chime in.
| kettro wrote:
| Great post, especially for the embedded crowd. I'm looking to
| start using Rust in FW development but hit a couple pain points.
|
| * First, bit field descriptors is a huge pain - where, in C, you
| would define an enum for the task, there isn't a real equal in
| vanilla Rust, other than a litany of constant variables. *
| Second, the over-reliance on nightly is a tough sell for - having
| inline asm gated makes it very hard. * Third, while format is
| great, it's also very heavyweight. Not having (AFAIK) variadic
| arguments is hard, and there isn't really an equal to printf.
|
| I would love to be proven wrong, because I have an OS to write,
| and would love to use Rust.
| dochtman wrote:
| Have a look at the recent defmt project announced by the
| Knurling-rs group:
|
| https://defmt.ferrous-systems.com/
|
| (And consider sponsoring them if this is of value to you:
| https://ferrous-systems.com/blog/knurling-one-month/.)
| masklinn wrote:
| > First, bit field descriptors is a huge pain - where, in C,
| you would define an enum for the task, there isn't a real equal
| in vanilla Rust
|
| "A litany of constants" is exactly what your c enum is though.
|
| And you can define a "degenerate" Rust enum with explicit
| discriminant values: enum Foo { A
| = 1, B = 2, C = 4 }
|
| They are cast-able to integrals too:
| println!("{}", Foo::C as usize); // prints "4"
|
| Doesn't work so well for flags however.
|
| > Second, the over-reliance on nightly is a tough sell for -
| having inline asm gated makes it very hard.
|
| The alternative would be to simply not make the feature
| available at all until it is done and ready, with even higher
| risk (as it would have been exercised even less).
|
| As is, if the feature is fine for you as-is you can use it, and
| if you can't or don't want to use nightly you can go and assist
| its shepherding to stable (https://github.com/rust-
| lang/rust/issues/72016)
|
| > while format is great, it's also very heavyweight. Not having
| (AFAIK) variadic arguments is hard, and there isn't really an
| equal to printf.
|
| There are no safe Rust-level variadics, but Rust can call C
| variadic functions, and under RFC 2137 (not stable yet I think)
| define them as well.
| JoshTriplett wrote:
| > * First, bit field descriptors is a huge pain - where, in C,
| you would define an enum for the task, there isn't a real equal
| in vanilla Rust, other than a litany of constant variables.
|
| With my Rust language team hat on: we'd love to have native
| support for bitfields. I'd invite folks who are interested in
| that to propose a language MCP ("major change proposal"), which
| I'd expect to be approved, and then collaborate on a spec for
| them.
| djmips wrote:
| Josh are you able to answer my top-level comment about fixed
| point numbers?
| JoshTriplett wrote:
| Sure, done.
| nicoburns wrote:
| You can assign numeric values to enum variants in Rust too like
| so: enum Field { Foo =
| 0b11111111, Bar = 0b10101010, }
| fn main() { println!("{}", Field::Foo as u8);
| println!("{}", Field::Bar as u8); }
|
| There is also the bitflags crate:
| https://docs.rs/bitflags/1.2.1/bitflags/
|
| For lighter weight formatting there is
| https://github.com/japaric/ufmt
| alkonaut wrote:
| > You can assign numeric values to enum variants in Rust too
|
| Is this (C-style enums) new?
|
| I swear I looked for it a year or two back, found questions
| about it, with the answers "use constants".
| ChrisSD wrote:
| These aren't really C style enums. These are still sum
| types.
|
| C-style enums are sugar for defining an integer type alias
| and a bunch of constants without creating any new types or
| scope.
|
| Rust enums, even with an assigned value, define a new type
| that can only be one of the defined values. So this type is
| not an integer and cannot have a bit pattern that isn't
| explicitly defined.
| steveklabnik wrote:
| Rust calls this feature "C style enums," so while you're
| right there are differences, it's sort of a term of art
| in this context.
|
| ("style" is supposed to reflect that it's similar, but
| not the same thing.)
| nicoburns wrote:
| EDIT: Found it in the changelog. This feature was added in
| Rust 0.8 (2013-09-26) "Explicit enum discriminants may be
| given as uints as in enum E { V = 0u }"
| https://github.com/rust-
| lang/rust/blob/master/RELEASES.md#ve...
|
| They're referenced as a pre-existing feature in this Jan
| 2015 RFC [0], so they predate Rust 1.0. I don't know quite
| how old they are, but I suspect much older than that as
| this feature is necessary for interfacing with C which has
| been a high priority for Rust for a long time (particularly
| driven by the needs of the Servo project in the early
| years).
|
| [0]: https://rust-lang.github.io/rfcs/0639-discriminant-
| intrinsic...
| masklinn wrote:
| > Is this (C-style enums) new?
|
| No.
|
| > I swear I looked for it a year or two back, found
| questions about it, with the answers "use constants".
|
| Possibly because they were asked / answered in the context
| of bit flags?
|
| Even degenerate, rust enums are not compatible with C enums
| because they're still type-safe, you can't create any
| random value and say "that's a Foo", that'd be UB. So if
| you want bitflags, you need to use constants.
| alkonaut wrote:
| Thanks. I didn't want bitflags, this was just basically
| for an enumeration of channels/parameters e.g Foo=0,
| Bar=1, Baz=2. Ideally I'd like one that was numbered
| automatically and also offered a way of enumerating the
| possible values at runtime. I can't remember why I went
| back to constants in that case.
|
| Another struggle I remember was just getting the max
| defined value. Again the Rust type is pretty Opaque
| because it hides the all-powerful discriminated union
| type. I love the Rust enum type, but I wish Rust also had
| a first-class dumb enum type, with all the C/C# niceties
| (bitflags, runtime enumeration, selection of backing
| field). This seems like quite a different from what the
| rust enum is.
| steveklabnik wrote:
| You probably ran into this stuff not being built-in. You
| can add it on via a macro pretty easily, except that the
| "selection of backing field" is built in via the repr
| attribute. An example of this would be packages like
| https://docs.rs/enum_derive/0.1.7/enum_derive/
|
| The other stuff isn't built in because it would add a
| bunch of code you may or may not want to your build, and
| it's easy enough to opt into. We also could solve that
| problem, in theory, a few ways, but there just hasn't
| been a ton of demand for it, so it hasn't been done.
|
| With bitfields, there has been increasing demand lately,
| so we'll see.
| simias wrote:
| >First, bit field descriptors is a huge pain - where, in C, you
| would define an enum for the task, there isn't a real equal in
| vanilla Rust, other than a litany of constant variables.
|
| Have a look at the bitlags crate, I use it a lot for this
| purpose: https://docs.rs/bitflags/1.2.1/bitflags/
|
| You still have to give the literal value of the field instead
| of using the auto-incrementing enum but that's how I do it in C
| as well, I find it too error-prone otherwise. And how do you
| deal with fields that take up multiple bits anyway?
|
| >Second, the over-reliance on nightly is a tough sell for -
| having inline asm gated makes it very hard.
|
| I agree 100%. I can understand them prioritizing higher level
| system programing and taking the time to do asm right, but it
| does make it a bit of a pain to do bare metal Rust at the
| moment.
|
| >Third, while format is great, it's also very heavyweight. Not
| having (AFAIK) variadic arguments is hard, and there isn't
| really an equal to printf.
|
| What do you have in mind here? format! is strongly typed and a
| lot more flexible than printf. You can't even print custom
| structs with printf... Actually even printing standard types
| like uint32_t and friends require macro soup to work portably.
|
| Variadic arguments are pretty much a no-go for a strongly
| typed, static language since you would need a lot of trickery
| to get it to work safely under the hood (hence format! being a
| macro).
|
| But what use case do you have for printf that can't be
| implemented with println!/format! and friends?
| masklinn wrote:
| > But what use case do you have for printf that can't be
| implemented with println!/format! and friends?
|
| I'm guessing they mean that the format! machinery is rather
| complex and brings in _a lot_ of code. That it 's also
| somewhat slow is a recurring concern .
|
| Have none of the embedded folks created a specialised version
| of format! which is _not_ generic, and basically only
| supports the types and styles which c 's printf supports?
|
| edit: there's ufmt though it seems somewhat inactive and I've
| no idea how _good_ it is: https://github.com/japaric/ufmt
|
| > Optimized for binary size and speed (rather than for
| compilation time)
|
| > No dynamic dispatch in generated code
| rcxdude wrote:
| There's defmt which I think i think is even better (it
| implements basically the same thing as I have used in a
| commercial C++ embedded project for a few years, and was
| sorely missing any open source equivilent when I was first
| trying to implement it). formatting strings on an embedded
| device is pointless and wasteful. Heck, formatting log
| lines before they are displayed to the user is actively
| harmful to interpreting them! Defmt basically gives
| embedded projects structured logging and a substantial
| bandwidth, cpu, and space overhead gain.
|
| https://ferrous-systems.com/blog/defmt/
| masklinn wrote:
| defmt looks cool for logging but I'd think there _are_
| cases where you want to format strings somehow in order
| to present them to the user e.g. audio track information
| or whatnot.
| tambourine_man wrote:
| > because I have an OS to write
|
| That sounds awesome. Personal project or commissioned?
| Upvoter33 wrote:
| good article, one of the better ones I've seen around Rust and
| what is cool about it.
|
| I'd like to know what Oxide is up to...
| dochtman wrote:
| Their site is somewhat explicit about it?
|
| https://oxide.computer/
|
| Also I can highly recommend their podcast, I can't wait for the
| next season.
|
| https://oxide.computer/podcast/
| yjftsjthsd-h wrote:
| Their website says what they intend to do, but not what
| they're up to lately; the last blog post is from July and is
| fairly meta (process for discussion, not ex. "we're working
| on firmware this week"). Similarly, podcast last posted in
| February.
| bcantrill wrote:
| Sorry if that's a bit thin; more detail on what we're doing
| and why can be found in a (pre-COVID) talk I gave at
| Stanford[1]. We're definitely not a Deep Stealth company,
| but we've also been very busy building; expect many more
| details over the coming year!
|
| [1] https://www.youtube.com/watch?v=vvZA9n3e5pc
| fizixer wrote:
| Rust, and Go, and Julia, and D, and Swift, and what not, should
| have a shouting and fighting match with one another.
|
| When they are done, they can let me know who won and then I'll
| take that language a bit more seriously.
|
| In the meantime I'm a humble coder sitting in the corner with
| Python + C + CUDA (plus some scheme and assembly), doing useless
| things like AI, robotics, IoT, etc.
| saagarjha wrote:
| None of them have to "win" for you to be able to use them. In
| fact, each excels in its own niche.
| fizixer wrote:
| Wow, thanks for opening my eyes.
|
| Time to clear out the next two years so I can learn half a
| dozen special snowflake randos that contribue ZERO to the
| problems and projects I'm working on.
| strangeattractr wrote:
| Nobody cares about your problems, nobody cares if you learn
| a new language or not. The thread is about reflections on
| using rust - if you don't want to learn/use it fine, but
| being irritated that others are is just strange.
| saagarjha wrote:
| Condensed matter physics is unlikely to contribute anything
| to the problems and projects you're working on as well, but
| that doesn't mean it isn't useful or that we shouldn't be
| studying it. Whether it's something that you're interested
| in is an entirely separate question. Regardless, shallow
| dismissals are against the guidelines here, so we don't
| want to hear about it if you're not interested.
| nindalf wrote:
| If anyone is wondering if it's worth the effort to read a
| comment that's greyed out to the point that it's white - IMO it
| wasn't. I'd like my time back.
| saagarjha wrote:
| Sometimes they are, particularly when comments from new users
| or those caught up in a shadowban-so I keep showdead on. But,
| yes, one must often be aware that they may be grayed out for
| a good reason.
| [deleted]
| [deleted]
| throwbackThurs wrote:
| I've begun coding with embedded rust, it's actually really
| refreshing to use a modern toolset & language in an embedded
| environment
| djmips wrote:
| Does Rust have first class support for fixed point number
| formats? If not, is there a proposal for that?
| JoshTriplett wrote:
| Do you mean something like decimal floating-point? No. There
| are several crates that provide such types, though:
| https://crates.io/search?q=decimal
|
| We've talked about having support for user-defined literals, so
| that you could have decimal literals; in the meantime, a macro
| works for that.
| tbirdz wrote:
| I don't want to speak for djmips, but I believe he was
| referring to something more like
| https://en.wikipedia.org/wiki/Q_(number_format)
| djmips wrote:
| That's pretty cool. I hadn't seen that before. I knew DSPs
| have used fixed point for decades but not aware of this
| format.
| djmips wrote:
| Thanks for the crates search link! It looks like decimal
| floating point is something used for financial calculations.
|
| Fixed point is where say in a 32 bit word, 16 bits is used
| for the integer part and 16 bits for the fraction or any
| combination that you can declare. Usually notated like 16.16
| or 16:16. Another format example in 32 bits could be 8.24 and
| also formats in other word sizes.
|
| I found some crates using 'fixed' as the search term.
|
| https://crates.io/search?page=1&per_page=10&q=fixed%20point
|
| It's been my desire to have a language for embedded to have
| first class support for fixed point just from the ability to
| work with them like you would a floating point number and not
| have to worry about macros.
| JoshTriplett wrote:
| Ah, got it.
|
| Along the same lines, is there anything that'd be needed to
| have "first class support" other than literals? If we had
| user-defined literal formats, so that one of those fixed-
| point crates could define a format for fixed-point
| literals, would that suffice?
| qppo wrote:
| Are there any architectures in production today where
| fractional arithmetic is meaningfully different than emulated
| block floating point _and_ have an LLVM backend already?
|
| I know there are some TI and ADI arch's with special fixed
| point data types built into their compilers (which are
| nonstandard extensions to C/C++, fwiw), but they are
| unsupported by LLVM last I checked.
|
| I've also heard that those niches are having their lunch eaten
| by ARM M4/M7 cores which have floating point vector
| instructions, and you can write Rust to target those today.
| [deleted]
| qaq wrote:
| Guys please make a pizza box Oxide.Computer workstation :)
| fluffy87 wrote:
| What is Oxide computer?
|
| I saw the talks, but I still have zero idea of what it is they
| want to sell.
| steveklabnik wrote:
| We will be selling servers.
|
| Here's a thread from last time this came up:
| https://news.ycombinator.com/item?id=23979042
| Const-me wrote:
| > Rust addresses this gap with the same "0b" prefix as found in
| some non-standard C compiler extensions.
|
| In C++ that's part of C++/14 standard, well-specified.
|
| > we have u8, u16, u32, u64, etc
|
| It's indeed nice to have fundamental types like that, but
| <stdint.h> header is required by the standard since C99, in C++
| since C++/11. It provides typedefs like uint32_t and the rest of
| them, thus the same UX.
|
| > DWARF support
|
| Yeah, but no PDB. Ship a Windows program written in Rust, and
| when it crashes or hangs on end-user's PC you're pretty much
| screwed. You need WinDBG to analyze these memory dumps written by
| the OS, and for that you need pdb symbols as opposed to dwarf.
| Diggsey wrote:
| Rust generates PDB files by default when using the MSVC
| toolchain...
| shepmaster wrote:
| > Yeah, but no PDB
|
| Can you expand on this? C:\rust>cargo new
| demo Created binary (application) `demo` package
| C:\rust>cd demo C:\rust\demo>cargo build
| Compiling demo v0.1.0 (C:\rust\demo) Finished dev
| [unoptimized + debuginfo] target(s) in 2.28s
| C:\rust\demo>dir target\debug Volume in drive C is
| Windows 10 Volume Serial Number is B4A6-FEC6
| Directory of C:\rust\demo\target\debug
| 10/11/2020 02:03 PM <DIR> . 10/11/2020
| 02:03 PM <DIR> .. 10/11/2020 02:03 PM
| 0 .cargo-lock 10/11/2020 02:03 PM <DIR>
| .fingerprint 10/11/2020 02:03 PM <DIR>
| build 10/11/2020 02:03 PM 61 demo.d
| 10/11/2020 02:03 PM 152,064 demo.exe
| 10/11/2020 02:03 PM 1,101,824 demo.pdb
| 10/11/2020 02:03 PM <DIR> deps 10/11/2020
| 02:03 PM <DIR> examples 10/11/2020 02:03
| PM <DIR> incremental 4
| File(s) 1,253,949 bytes 7 Dir(s)
| 15,995,387,904 bytes free
|
| `demo.pdb` is readily available.
| nix23 wrote:
| I just like Cantrill, he kicks butts and dtrace them afterwards.
| Great Speaker!
| jynelson wrote:
| I find it interesting the article didn't mention compile times at
| all. Maybe since Oxide mostly works with embedded, they have few
| dependencies and their compile times aren't very bad? I know my
| primary complaint after working with the language for about a
| year is that most projects take over a minute to build. Of
| course, it doesn't help that I keep moving onto larger projects
| xD but even small things like cargo-deadlinks and ripgrep take a
| while.
| [deleted]
| neolog wrote:
| Looks like the honeymoon is still ongoing.
| saagarjha wrote:
| A sign of a good marriage is that you never feel like you've
| come out of honeymoon, so I think they have likely made the
| right choice :)
| neolog wrote:
| > A sign of a good marriage is that you never feel like
| you've come out of honeymoon
|
| Does that happen for some couples?
| rabidrat wrote:
| Apparently some small percentage of couples do experience
| this. I don't think it's some magical "marriage made in
| heaven"; my theory is that some small number of people have
| a superhealthy relationship with their ego, and so don't
| need to differentiate (which is what causes the honeymoon-
| leaving), and if you get two of them together, they can
| stay in the honeymoon state indefinitely.
| Drdrdrq wrote:
| Yes. Some fight on the honeymoon already.
| saagarjha wrote:
| Better early than late?
___________________________________________________________________
(page generated 2020-10-11 23:00 UTC)