Rust 1.43

> Just to be clear, you never HAVE to update your code. Rust 1.0 code still works just fine.

You have to update your dependencies though because every now and then, changes lead to breaking builds. I have a codebase from 2015, last touched in 2016, and many dependencies failed to compile, some because of changes in the language (those changes are only done to fix bugs but they still cause churn to users), others because the openssl wrapper doesn't support newer natively installed versions of openssl. It took me roughly an hour to fix all the issues and it's only a few hundred lines.

Admittedly this is much much less effort than staying up with whatever the currently hyped error handling library is. And C++ projects often need effort to work on newer compilers as well because they invoke UB and the optimizer changed and led to segfaults. Seen it with my own eyes.

Also isn't the point of tools like Rustup is that you don't need to make sure your code is constantly up-to-date with respect to the compiler? Like you can keep using rustc 1.0 on code written for Rust 1.0, right?

To clarify for others: "anyhow" and "thiserror" are not placeholder names in that sentence. They refer to:

https://github.com/dtolnay/anyhow https://github.com/dtolnay/thiserror

We already have minor releases, but they are exclusively for critical bugfixes. Everything else either rides the train (up to 12 weeks) or gets backported to beta (up to 6 weeks before hitting stable).

In that case I think keeping up very small additive changes is good, thanks for clearing up

We do, and that’s part of what I meant in the comment by “dropped”; the first one can’t be worked around, but the others could, in theory.

That said I’m not an expert on Rocket and don’t know what Sergio’s plan is exactly.

How does Nix handle areas with extensive package ecosystems? Python, Node et al? It seems like every distro/super packager has different compromises for this question.

I feel like I've been pushing my use case plenty already, so please take this as an answer to your question rather than one more push ;-)

I'd like to be able to create plugin-style cdylibs that get loaded into a host program. For instance, PostgreSQL extensions are shared libraries (typically written in C) that need to be loaded into a running instance of postgres for integration testing. I am trying to make it reasonable to write such extensions in rust (https://github.com/jeff-davis/postgres-extension.rs).

The environment variable to find the shared library would solve one problem, but there are still a couple more right behind it:

* Running "cargo test" tries to build a binary that links to the library to run the unit tests, but this will fail because there are unresolved symbols in the .so file (symbols that call APIs in the host program, in this case PostgreSQL functions like palloc()). In other words, the test binary is useless because it can't load the plugin.

* Linux seems fine creating a .so with unresolved symbols, but Mac and Windows need special linker flags. I can document that the linker flags are needed by consumers of my crate, but it would be nice if there was a better/supported way to create plugin-style shared libraries. I tried filing a bug with PR (https://github.com/rust-lang/rust/pull/66204) it was determined that it needed to go through the RFC process.

The simplest way to see the problem is to look at this crate: https://github.com/jeff-davis/unresolved

My problems don't end there, unfortunately. For my crate to really work, I also need to solve the problem of setjmp/longjmp at the edges between C and Rust (https://github.com/rust-lang/rfcs/issues/2625).

This is a function invocation:

    foo(bar)

This is a macro invocation:

    foo!(bar)

It's done this way because macros can have much more complex things inside the ()s than functions can. This helps both humans and computers parse such things.

Not OP, I think they mean the exclamation mark (!)

foo(x, y, z) is a function. foo!(x, y, z) is a macro.

    println!("something")

that's a macro

Exclamation mark. e.g.

    println!("hello, world");

or

    todo!();

are macro invocations.

Macros:

#[Foo] struct Bar {}

baz!()

cat!{}

blah![]

TIL that “Exclamation point” is region specific. Other people call it exclamation marks.

In the example given the macro is almost useless. The benefit comes if you want the expanded code to have more things, like methods defined that otherwise you would have your consumer write or sister methods and types.

The macros are only about convenience on usage and reduction of boilerplate. A good example is the vec![1,2] macro call that expands to

    {
        let mut x = Vec::new();
        x.push(1);
        x.push(2);
        x
    }

The reason the blog post is using that example is because it's showing a new type of macro argument which accepts items (functions, structs, enums, traits and impls) and expands them correctly without any extra needs by the macro writer.

Here's a real-world example from the code I was working on yesterday: I have several database tables where the records have numeric IDs, and instead of having the ID type be just an int everywhere, I want them to be proper types to avoid mixups. Instead of

  fn set_document_owner(document_id: i64, user_id: i64)

where I could easily provide the arguments in the wrong order, I want

  fn set_document_owner(document_id: DocumentID, user_id: UserID)

where this cannot happen. Each ID type is just a one-element tuple containing an i64, which would just be

  pub struct DocumentID(pub i64);
  pub struct UserID(pub i64);
  //... and so on ...

and so on. But in order for them to behave as expected (e.g. with the == operator or when reading/writing IDs in the database), I need to write a bunch of boilerplate. This is the macro that I have now:

  use rusqlite::types::{FromSql, FromSqlResult, ToSql, ToSqlOutput, ValueRef};

  macro_rules! make_id_type {
      ( $name:ident ) => {
          ///A type-safe primary key.
          #[derive(Default, Clone, Copy, Hash, PartialEq, Eq, Deserialize, Serialize)]
          pub struct $name(pub i64);

          impl fmt::Display for $name {
              fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
                  self.0.fmt(f)
              } 
          } 

          impl ToSql for $name {
              fn to_sql(&self) -> rusqlite::Result<ToSqlOutput> {
                  self.0.to_sql()
              } 
          } 

          impl FromSql for $name {
              fn column_result(value: ValueRef) -> FromSqlResult<Self> {
                  Ok($name(i64::column_result(value)?))
              } 
          } 
      };
  }

  make_id_type!(DocumentID);
  make_id_type!(UserID);
  //... and so on ...

This is pretty much the most basic usecase for macros. You can do some more interesting stuff than just take a name and insert it into some template, because macros can actually pattern-match the phrases given to them in the macro invocation. A good example, also from the RDBMS domain, would be https://docs.diesel.rs/diesel/macro.table.html (link goes to the documentation of the macro).

In this specific case the macro isn’t very useful since you can easily write `trait T { ... }` yourself. They tend to be more useful when there is a lot of similar boilerplate code that only differ in a few ways. A macro can cut down most of that repetition. They can also be used to provide pseudo “literals” like the vec! macro does for the Vec data type.

One thing I use it for all the time is data-driven tests, e.g. https://github.com/jcdickinson/racemus/blob/master/racemus-b...

One common usage is to use macros to repeat some definition for every integer type. In this case T is not a generic, but the name of the trait.

One issue with macros is that they are currently breaking most IDE integrations.

Rust is also supported by more than Mozilla these days.

Yes, it is being automatically de-referenced.

This seems like an odd choice... do you know the rationale? (or have a link to an issue/RFC I could go read)