[HN Gopher] Rust 1.71.0
___________________________________________________________________
Rust 1.71.0
Author : mbStavola
Score : 246 points
Date : 2023-07-13 14:06 UTC (8 hours ago)
(HTM) web link (blog.rust-lang.org)
(TXT) w3m dump (blog.rust-lang.org)
| epage wrote:
| From cargo's changelog [0]
|
| > Automatically inherit workspace fields when running `cargo
| new`/`cargo init`. #12069 [1]
|
| imo I think this is a big quality of life improvement
|
| [0] https://github.com/rust-
| lang/cargo/blob/master/CHANGELOG.md#...
|
| [1] https://github.com/rust-lang/cargo/pull/12069
| revskill wrote:
| I think versioning like 13.07.23 is better.
|
| You automatically get:
|
| - Minor version upgrade every day.
|
| - Major version upgrade every month.
| dagmx wrote:
| But that forces a very specific schedule on projects and ruins
| the semver meaning of what a version entails.
|
| I really dislike date based versioning unless the major version
| is year aligned and is truly a big jump forward (like Jetbrains
| do it).
|
| Otherwise how do you know when a breaking change happens? Or if
| a version is significant or not? With 1.69.1 I know how .1
| relates to .69 and to the 1.
| aseipp wrote:
| Calver I think is more useful for _applications_ that get
| continuously developed and released, honestly. Like, whenever
| you are using a webapp that is just self-contained thing,
| semver doesn 't necessarily mean much, it basically just
| boils down to "Big version number bump = more recent."
|
| I think this is one of the reasons programmers gets mad at
| like, Google Chrome or Firefox or whatever about having
| version number 100, but literally _nobody else cares_.
| Version numbers just fundamentally mean something different
| to engineers who think of "consuming programs" like they do
| consuming an API, versus a user, who just thinks of it as
| "Bigger number = more recent = good."
|
| > Otherwise how do you know when a breaking change happens?
|
| Linux is a good illustrative example of how this works. How
| do you know when a breaking change in Linux happens? The
| answer is the developers define a stable boundary (userspace)
| and stick to it, whether or not they use semver, and the
| other components are out of scope (kernel APIs). They simply
| have a different criterion for where the line gets drawn.
| This makes some people mad and some people happy, but it's
| not exactly new.
|
| Similarly, in most of the calver applications I've seen and
| used, you typically just don't do huge breaking changes, you
| just do gradual migrations of existing things, with warnings,
| rollouts, cutovers, brownouts, etc to control what happens.
| So the answer is "when do they happen" is "they mostly
| don't." The release process and guarantees are just
| different.
|
| Same with "is a version significant or not." How do you know
| if a version of Linux is significant? You go read the release
| notes. They come out once every 3 months, so you always know
| when to look. When you do calver based releases, that
| question just matters a whole lot less in some sense. Did a
| feature not get in this time by a hair? It will just get in
| next time, so there's no need to squeeze yourself or sweat
| bullets about extending your runway. Sometimes a lot of big
| features land in one release and sometimes they get held
| back. It's just how it works.
|
| I don't think calver is very good for actual programmer-
| facing APIs, necessarily, but it can work e.g. webapps tend
| to have different versioning schemes and techniques for REST
| APIs, so clearly semver isn't the _only_ possible technique.
| It does help introduce some mechanical semantics that can be
| tool checked, etc. For Rust that 's really useful, but for a
| lot of cases that isn't so relevant.
| revskill wrote:
| No news is good news, so it's fine to upgrade without any
| changes.
| Lev1a wrote:
| > I think versioning like 13.07.23 is better.
|
| > You automatically get:
|
| > - Minor version upgrade every day.
|
| > - Major version upgrade every month.
|
| 1. Isn't the order normally <major>.<minor>.<patch> ?
|
| 2. For sortability the order should if anything follow the ISO
| 8601 order.
|
| 3. Some way to optionally represent the specific rust edition
| used in the compiler/toolchain version would probably be a good
| idea.
|
| Therefore, my recommendation would be (if you'd want to
| actually use this instead of semver):
| YYYY.MM.DD(.EDITION)(-PATCH)
| eYrKEC2 wrote:
| Have you read the `semver` spec? Very small and approachable
| https://semver.org/ . If your project's dependencies are
| following semver, you can reduce your chance of dependency
| hell. If you want to encode the date into a semver version
| string it is possible https://semver.org/#spec-item-10
| dagmx wrote:
| Debugger visualization is a really great idea. I hadn't thought
| of using attribute annotation to do it but now I'm wishing more
| languages had that.
| jauntywundrkind wrote:
| Do any other languages have anything like this
| _debugger_visualizer_ attribute?
| dagmx wrote:
| Not that I know of. But I'd certainly like to know that I
| missed it
| klysm wrote:
| I guess repr is kind of similar in python but not really
| yencabulator wrote:
| Python's repr is Rust's impl Debug for Foo
| mark_undoio wrote:
| Not exactly but for shared libraries in general it's possible
| to ship some accompanying Python that will get installed and
| automatically loaded by GDB.
|
| You can even embed that Python script within the shared
| object using some scary ELF tricks - I was surprised, to say
| the least, to discover this is supported.
| colejohnson66 wrote:
| C# has the `DebuggerDisplay` attribute:
| https://learn.microsoft.com/en-
| us/visualstudio/debugger/usin...
| mihular wrote:
| Yes and much more like DebuggerVisualizerAttribute which
| allows you to present data in any possible way.
| https://learn.microsoft.com/en-
| us/visualstudio/debugger/crea...
| fsloth wrote:
| A slightly different thing - Visual Studio allows you to
| create custom visualizations for any live debug data. This is
| absolutely wonderful.
| scottlamb wrote:
| One of the nice things about Rust's RFC process for new
| features is they answer questions like this: https://rust-
| lang.github.io/rfcs/3191-debugger-visualizer.ht...
|
| edit: actually, I guess that focuses more on the debugger
| side, and less on the language side, so not a great answer to
| your question.
| n8henrie wrote:
| I'm excited about the array <-> tuple conversion! (At least for
| small ones.)
| armchairhacker wrote:
| #[debug_visualizer] seems like it will be very useful.
|
| One of the current issues with Rust (and a place where C++ is
| still better) is debugging. Granted, I end up needing to debug
| Rust code _much less often_ than C++ code, but it would still be
| nice to actually call rust functions in IntelliJ (and it seems
| there 's limited support in gdb and lldb), and view data-
| structures like maps opaquely instead of just their complex
| internals.
| mr_00ff00 wrote:
| Slightly off topic, but is IntelliJ the best IDE for rust? I
| would have assumed Clion
| j-pb wrote:
| I feel that Rust could really profit from an interactive REPL
| like notebook like Julias Pluto. It makes visualisations during
| development and their integration with documentation so
| seamless.
| jo1gi wrote:
| Check out https://github.com/evcxr/evcxr
| kibwen wrote:
| You can do this using the evcxr kernel for Jupyter: https://g
| ithub.com/evcxr/evcxr/blob/1a2d6c40c467267801c7382e...
| j-pb wrote:
| Sadly jupyter is a very different experience to Pluto. The
| latter is similar to ObservableHQ (it even reuses part of
| the runtime afaik).
|
| So you don't have to manually evaluate cells, but they are
| evaluated based on the computations dataflow graph.
|
| Additionally it allows for very interactive visualisations
| and data input.
| dannymi wrote:
| >but it would still be nice to actually call rust functions
|
| I agree.
|
| > data-structures like maps opaquely instead of just their
| complex internals.
|
| Works for me: use std::collections::HashMap;
| fn main() { let mut m = HashMap::<String,
| u32>::new(); m.insert("a".to_string(), 5);
| m.insert("b".to_string(), 3); println!("Hello,
| world!"); } $ rust-gdb target/debug/t1
| (gdb) b 7 (gdb) r (gdb) print(m) $3 =
| HashMap(size=2) = {["a"] = 5, ["b"] = 3}
| jauntywundrkind wrote:
| In this thread it is revealed that all (almost all) Rust devs
| are printf() not breakpoint devs, and why.
|
| This _debugger_visualizer_ attribute does seem like a really
| cool capability. It 's about embedding debugging scripts for
| debug tools, in your rust source code; couldn't be more direct!
| https://doc.rust-lang.org/nightly/reference/attributes/debug...
| IshKebab wrote:
| > In this thread it is revealed that all (almost all) Rust
| devs are printf() not breakpoint devs, and why.
|
| No it isn't? IDE debugging works just as well for Rust as it
| does for C++ in my experience - better even. Yes it sometimes
| shows raw internals of complex containers instead of the
| logical structure, but it does for C++ too.
|
| In Rust I can just click "Debug test" next to any test and it
| will start it in a debugger flawlessly. Zero effort to set
| up. I've never seen anything close to that in C++.
|
| Of course as someone else said, you need a debugger far far
| less in Rust than C++.
| 3836293648 wrote:
| Next step rustc can generate python pretty printers itself?
| At the very least I hope some crate can do that with a build
| script eventually
| masklinn wrote:
| It's been shipping printers for a few years:
| https://github.com/rust-lang/rust/pull/72357
|
| Though that "only" dates back to 2020 so people with
| experience older than that would have had a worse
| experience, and may have ended once bitten twice shy as a
| result never noticing the improvements.
| 3836293648 wrote:
| No, I meant generate printers for custom types, not ship
| printers for stdlib types.
| gnulinux wrote:
| > In this thread it is revealed that all (almost all) Rust
| devs are printf() not breakpoint devs, and why.
|
| I'm a _non-proud_ printf() debugger. I understand that _if_ I
| get use to debugger debugging it 'd be in many ways better.
| The thing is, it's an entirely different paradigm of
| development, and paradigm shifts can come with significant
| productivity cost. Of course, learning, growing and getting
| comfortable with new/different tools is part of being a
| software engineer.
| mark_undoio wrote:
| Have you tried using a debugger at all? I see people who've
| resisted for years become mega fans when they finally try
| one.
|
| I also see people who use them all the time but reluctantly
| - I'd love to know what the difference is.
| Sharlin wrote:
| I wonder why there's no protocol that simply tells the debugger
| that to pretty-print type X, it should call function Y _in the
| debugged executable itself_ (using normal C ABI and some
| agreed-on calling convention). Then, for example, rustc could
| just generate simple glue functions that delegate to
| `Debug::fmt` in order to get formatting that the programmer is
| already familiar with or indeed has implemented themselves.
|
| (Some precautionary measures would of course be required to
| avoid infinite recursion and similar. But the same issues
| already exist in debuggers that allow pretty-printers to eg.
| run arbitrary python code. To avoid a pathological or buggy
| formatter breaking either the debugged program or the debugger
| itself, it might be best to execute the formatter in a separate
| child process.)
| progbits wrote:
| Of course those would have to be side-effect free, or somehow
| "sandboxed".
|
| It seems like debug printers should be pure functions but you
| never know what sort of weird stuff people do.
| eklitzke wrote:
| Even just formatting something as a string will likely
| require memory allocation for all but the most trivial
| cases, and memory allocation is not side effect free.
| yencabulator wrote:
| Take the already-frozen process, make a clone with CoW
| memory, switch the clone to a sandbox that forbids most
| syscalls, run the pretty-printer function(s) in the clone
| process, abort if pretty-printing takes too long (hung on
| lock, infinite loop due to corrupt data structure, etc)?
|
| Lots of devils in the details, but that sounds _possible_.
| mark_undoio wrote:
| You're quite right, it's very possible.
|
| The product I work on does pretty much exactly this - we
| need it because our debugger time travels and we can't
| allow history to be altered!
|
| I wrote some words here: https://medium.com/time-travel-
| debugging/calling-functions-i...
|
| But it's basically exactly what you propose. We didn't
| sandbox the syscalls but you could do that too.
| ratmice wrote:
| The impetus for python, rather than making a call into the
| inferior/debugged process is largely to support pretty
| printing data structures within core files & crash dumps.
| While it is certainly possible, it is not a small amount of
| work to generate pretty printers to run in the debugger
| likely involving an entire toolchain to compile the `Debug`
| traits to. The easiest way is probably compiling Debug traits
| to wasm, with the existing python pretty printers calling
| into that would be my best guess at a good starting point.
| tomjakubowski wrote:
| That's a really neat use case for wasm. And, if there were
| debugger support for wasm pretty-printers, it would be easy
| to support in language toolchains which already compile to
| wasm.
| mark_undoio wrote:
| I'm a debugger specialist, not a Rust specialist - but I'm
| surprised the experience of viewing data structures is not
| better for you.
|
| What platform / debugger are you on? I'd expect the GDB pretty-
| printers (which from the article it looks like Rust has been
| shipping by default for the standard library) to be taking care
| of this relatively well - e.g. looking at
| https://github.com/rust-lang/rust/pull/72357 it appears that
| `HashMap` and `HashSet` have printers.
|
| (Raw C++ data structures without some form of pretty printing
| are also incomprehensible for normal development - and I'd be
| surprised if third party libraries were particularly good at
| shipping pretty printers, though I may be wrong!)
| pkolaczk wrote:
| Why is it such a problem? Can't debuggers use `Debug` trait
| if defined? Or do they already?
| mark_undoio wrote:
| I'm not sure they'd do so automatically but, given the
| ability to call functions (which it sounds like, for Rust,
| GDB lacks) it should be possible to plumb together.
|
| But debuggers like GDB have built in infrastructure for
| expressing how to display structured, potentially nested
| data structures - it's built for the purpose and powerful,
| so it's nice to bring it to bear if you've not already got
| something equivalent in they program.
|
| The other important thing is that the debugger's pretty
| printers work on a core file, without needing a live
| process.
| JakobH wrote:
| I love debugging, how do I go deeper in the art of debugging?
| mark_undoio wrote:
| If you use GDB, I recommend checking out the official
| documentation:
| https://sourceware.org/gdb/current/onlinedocs/gdb.html/
|
| It's quite hard work sometimes - there's a lot in there -
| but the capabilities available are amazing and it's well
| worth nosing around.
|
| I also recommend just hitting TAB a lot and seeing what
| commands are suggested. Then use the "help"command to find
| out more.
|
| My employer also hosts some articles that digest some
| knowledge we've gained into a more palatable form:
| https://undo.io/resources/gdb-watchpoint/
| jackbracken wrote:
| Release more bugs
| wiz21c wrote:
| per-bugging or re-bugging is the way
| armchairhacker wrote:
| I'm using the IntelliJ debugger.
|
| It's gotten much better. Primitive structures which are
| defined by their fields and builtins like `Vec`, `HashMap`,
| `String`, are handled good. But structures in library or user
| code which use "raw" and other non-trivial representations,
| but provide an opaque safe API, I can only introspect the
| non-trivial fields.
|
| This annotation is exactly what those custom structures need.
| dcz_self wrote:
| You can use QtCreator that way already:
|
| https://dorotac.eu/posts/debugging_rust/
|
| You can view the data structures opaquely even though the
| functions are written not in Rust, but in Python.
|
| One of the difficulties is that the Rust compiler will emit
| different debugging info depending on the compiler version.
| Perhaps I should look into how gdb deals with that (if at all).
|
| Patches welcome.
| tempodox wrote:
| Wow, those long lines that don't break are a special kind of
| horror, in an article from 2023 no less. Am I glad there's
| Reader View.
|
| But the contents is interesting. Bookmarked.
| dcz_self wrote:
| Which lines do you mean? This source code part?
|
| > $1 = alloc::string::String {vec: alloc::vec::Vec<u8,
| alloc::alloc::Global> {buf: alloc::raw_vec::RawVec<u8,
| alloc::alloc::Global> {ptr: core::ptr::unique::Unique<u8>
| {pointer: core::ptr::non_null::NonNull<u8> {pointer:
| 0x5555555abaa0}, _marker: core::marker::PhantomData<u8>},
| cap: 3, alloc: alloc::alloc::Global}, len: 3}}
|
| On my browser, everything breaks according to the browser's
| window size (I set white-space: pre-wrap).
| riquito wrote:
| Don't know about the long lines, everything wraps well to
| me, but on mobile (firefox) the zero padding on the left
| side is brutal. The gigantic comment section at the end
| is a small hindrance, while the right sidebar kills
| 30-40% of the page width (on mobile), which is annoying
| on longer articles. And thanks for the content :-)
| lolrustwtf wrote:
| [flagged]
| diarrhea wrote:
| I had wondered about this but am too green to get it. Is this
| the reason that in VSCode, when debugging, most variables show
| as basically raw bytes instead of something useful? That was
| very surprising to me and made debugging difficult. In Python
| I'm used to it just working.
| tempodox wrote:
| It's not VSCode, it's the plugin for the language you're
| using. And let's face it, most of them are rather shitty.
| TillE wrote:
| C++ debugging on VS Code is pretty good in my recent
| experience (macOS / lldb), though not as full-featured as
| Visual Studio.
| 0cf8612b2e1e wrote:
| Just to give some acknowledgment, the VSCode Python debugger
| is really great. I was a longtime print debugger, but the the
| tooling makes the process so straightforward to use, that it
| is now the only way I can operate.
| swader999 wrote:
| I write billing apps because I'm a masochist and feel there is
| deeper meaning to be gained through suffering. Lot of data and
| rules to process. Torn between learning Go or Rust next.
| diarrhea wrote:
| Not qualified to answer thoroughly, but I wouldn't use Go for
| anything that it's not designed for, which is cloud
| infrastructure. That's actually its slogan and it excels there.
|
| For Rust, you can likely encode most rules and transitions
| between states in the type system itself. It's a super power in
| that niche.
| diarrhea wrote:
| But expressive it is anything but, it turns out.
| capableweb wrote:
| Golang was initially sold as a "expressive, concurrent,
| garbage-collected systems programming language", not as a
| "cloud infrastructure" language.
|
| Screenshot of the Golang website from ~2010:
| https://i.imgur.com/AYeUvuE.png
| pohl wrote:
| Pike later expressed regret about using the term "systems
| programming" so loosely. I believe it was during this panel
| discussion:
|
| https://learn.microsoft.com/en-us/events/lang-
| next-2014/pane...
| pjmlp wrote:
| Thankfully some folks completly ignored whatever the rest
| of the world thinks system programming is all about and
| created:
|
| - TinyGo (https://tinygo.org/), which is acknowledged by
| people in the industry[0][1]
|
| - TamaGo unikernel on USB Armory secure key
| (https://www.withsecure.com/de/solutions/innovative-
| security-...)
|
| And then there is the question if writing compilers,
| assemblers, linkers is systems programming or not.
|
| [0]-https://www.cnx-software.com/2019/08/28/tinygo-go-
| compiler-f...
|
| [1]-https://twitter.com/ArmSoftwareDev/status/13168048133
| 1796787...
| veber-alex wrote:
| By that logic Python is a systems programming language
| because MicroPython exists.
|
| Just because you can provide some niche examples where Go
| is used as a systems programming language doesn't mean it
| is a general purpose systems programming language.
|
| Putting Go in the same category as C/C++/Rust/Zig is
| ridiculous.
| pjmlp wrote:
| When Python manages to bootstrap itself, Lisp Machine or
| Smalltalk style, yep.
|
| Ridiculous is being a gatekeeper lacking imagination.
|
| Thankfully for mankind's progress they tend to be a
| minority, even though they sometimes get into the way.
| capableweb wrote:
| Regardless, I don't think anyone in the first couple of
| years would describe Golang's goal as to be "designed for
| cloud infrastructure" like what parent did.
| pohl wrote:
| Well, except for the context where google's cloud
| infrastructure code were precisely what they meant by
| "systems" back then.
| benatkin wrote:
| I agree with you. To me that sentence broadens its
| applicability. _Systems_ narrows it a bit, but he didn 't
| intend to so much. People misunderstood this use of the
| term. In this context, it's more related to systems
| thinking than operating systems. systems =/= close to the
| metal
| yencabulator wrote:
| "Systems programming" = "programming things that are used
| by programs, not by end users".
|
| https://en.wikipedia.org/wiki/Systems_programming
| swader999 wrote:
| Readability and comprehension are very important. You want
| to minimize the translation between business and technical
| worlds in this space. C# worked well in the past if you
| didn't get distracted by all the frameworky tangents but it
| doesn't seem like there's as much new work in that
| language.
| mark_undoio wrote:
| I've been experimenting with Go recently, with Rust still on my
| to-do list. I _really_ like the simplicity of Go, with a fairly
| small language of constructs that combine powerfully.
|
| Having learned SML / Haskell in the past I've got a bit of a
| soft spot for languages that are utterly cruel to you with
| their compilation errors but lead you straight to bug-free
| code. What I've heard about Rust puts it in this camp.
|
| One thing that does concern me about Rust: when I (now and
| then) look at what's changing in C++ it feels like a lot of new
| mechanisms and abstractions are required to address problems
| created by previous design decisions. I sometimes read about
| Rust and worry that I might need to embark on a similar
| journey.
| justincredible wrote:
| Rust compilation is strict but not cruel. The suggested fixes
| associated with compilation errors are very friendly to
| beginners (one notable exception is errors around lifetimes).
|
| Your concerns regarding "feature creep" are reasonable and
| would be expected for a language trying to displace C++.
|
| Edit: grammar
| seanw444 wrote:
| Not to mention the unstable and fast-moving nature of its
| development.
|
| https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-
| repl...
| Georgelemental wrote:
| Many of Rust's new "features"--for example GATs--are really
| more removing restrictions. Code you would try to write,
| and then be surprised to learn it wasn't possible.
| howinteresting wrote:
| > C has a spec. No spec means there's nothing keeping rustc
| honest.
|
| Can you find the flaw in this statement?
|
| No spec doesn't mean there's _nothing_ keeping rustc
| honest, it just means there isn 't a _spec_ keeping rustc
| honest.
|
| > Any behavior it exhibits could change tomorrow.
|
| And pigs could fly tomorrow as well. This is not a serious
| engagement with the ways the Rust developers go to great
| pains not to change behavior (such as crater runs). In many
| ways empirical evidence like crater is more valuable than
| some random document that might or might not be fully
| obeyed at any time.
|
| > That they can't slow down to pin down exactly what
| defines Rust is also indicative of an immature language.
|
| Rust has slowed down a lot, just not to Drew's liking. And
| he isn't acknowledging the ways in which the risks of
| moving fast are mitigated.
|
| > Safety. Yes, Rust is more safe. I don't really care. In
| light of all of these problems, I'll take my segfaults and
| buffer overflows.
|
| Please leave the software industry. This is embarrassing.
|
| > I especially refuse to "rewrite it in Rust" - because no
| matter what, rewriting an entire program from scratch is
| always going to introduce more bugs than maintaining the C
| program ever would.
|
| What evidence is there for this position? My contention is
| that a Rust rewrite would maybe not start that way, but
| rapidly exceed the C version in quality because it is just
| a more modern language.
| isanjay wrote:
| In some ways they are polar opposites.
|
| Fastest compile times vs slow compile times. Excellent type
| system vs very basic type system Complex language vs Simple
| language
|
| If I were to learn a new language it would be rust because I
| like it's type system.
|
| That being said I use many cli tools written in rust and
| golang.
| capableweb wrote:
| Clojure was basically made for manipulating data and enabling
| fast changes of rules. Couple it together with XTDB which makes
| a lot of sense for finance-related domains because of its bi-
| temporality.
| benatkin wrote:
| Check out dart and flutter :)
| brink wrote:
| Mostly depends on how ambitious you're feeling, imo.
|
| fwiw - I learned Rust, was painful at first, but now I love it.
| swader999 wrote:
| From what I've read, it seems like if you can learn Rust, go
| would be a quick afterthought to pick up. Just not sure if it
| was my own money for dev expenses if I would choose it.
| eYrKEC2 wrote:
| That is very fair. I was useless the first month of Rust. I
| would say that new rust devs are basically in training and
| unavailable for ~4 weeks. Rust mastery takes much longer
| than that, of course.
|
| However, the type checking in Rust is fantastic. The
| confidence in correctness that you have when it is complete
| is much higher than many other languages.
| masklinn wrote:
| > Just not sure if it was my own money for dev expenses if
| I would choose it.
|
| Use case would probably be a major factor in the decision
| e.g. picking up rust from scratch to write a basic network
| service would probably be stupid unless it had very strict
| requirements known in advance (and even then you might want
| to write it in go anyway in case that works out or to
| quickly uncover issues you'd hadn't predicted).
|
| If you know in advance you have very strict resource
| constraints however, or you really need the reliability (of
| extensively encoding things in the typesystem), or you're
| writing native extensions (python + rust via pyo3 is great,
| python + go is something I'd avoid unless the entire
| solution already existed in Go and I could expose it to
| python over a pipe), etc... then the investment would
| likely be more worth it.
|
| Basically, how much return would you expect, Go requires
| very little investment, Rust a lot more.
| jarjoura wrote:
| If you're already familiar with system languages like C++, I
| think you'd make progress in Rust a lot faster than you think.
| However, it takes a LONG ass time to truly know the language
| and internalize good intuition around the kind of code you need
| to write to take advantage of it.
|
| I do love Rust, but one complaint is that early design
| decisions because of my weak understanding are extremely hard
| to refactor out later on. Poor type choices can end up bleeding
| into the entire project that become nightmares to improve.
|
| My advice is to use cargo workspaces to break up your project
| into small self contained modules early so when you will
| inevitably need to refactor, it will make your life less
| painful.
| orra wrote:
| Nice to have the option to unwind across an FFI boundary. It's
| also good that (in a future release) erroneously unwinding across
| a C ABI boundary will abort, instead of being undefined
| behaviour.
___________________________________________________________________
(page generated 2023-07-13 23:02 UTC)