That was a hard long adventure, massive refactoring with bug-fixing 🥵

I went to look into the activitypub federation package from Rust and noticed that it does not support JSON-LD. This took me to a search into other libraries, which got me to RDF-based crates. Just thought it was a good idea to share.

Hi rustaceans! What are you working on this week? Did you discover something new, you want to share?

Hey,

Is there any way to create a macro that allows a Some<T> or T as input?

It's for creating a Span struct that I'm using:

struct Span {
    line: usize,
    column: usize,
    file_path: Option<String>,
}

...and I have the following macro:

macro_rules! span {
    ($line:expr, $column:expr) => {
        Span {
            line: $line,
            column: $column
            file_path: None,
        }
    };

    ($line:expr, $column:expr, $file_path: expr) => {
        Span {
            line: $line,
            column: $column
            file_path: Some($file_path.to_string()),
        }
    };
}

...which allows me to do this:

let foo = span!(1, 1);
let bar = span!(1, 1, "file.txt");

However, sometimes I don't want to pass in the file path directly but through a variable that is Option. To do this, I always have to match the variable:

let file_path = Some("file.txt");

let foo = match file_path {
    Some(file_path) => span!(1, 1, file_path),
    None => span!(1, 1),
}

Is there a way which allows me to directly use span!(1, 1, file_path) where file_path could be "file.txt", Some("file.txt") or None?

Thanks in advance!

Morning all!

Okay, let me start out by saying that I know absolutely sweet F.A. about Rust. There's simply something I'm trying to get working and it's required me to make a few changes. And with every change, it's getting closer to building successfully… or so I hope.

Anyway, I'm here to bother you for a reason, not just to waffle. I was wondering if someone could be kind enough to explain this rust toolchain malarkey?

When I started trying to "fix" this thing (it's a dockerfile), I updated it to build from the latest and greatest rust and then updated to the latest and… I digress, point being it's failing some cargo stuff and I have reason to believe it's because of the rust toolchain which is set as nightly-2022-07-19 now, I thought I could just set that to stable, but upon reading some docs, I need to set the date. I was just wondering if someone could explain why? Why can't I just have the toolchain set to latest? It seems complicated for nothing.

Hi rustaceans! What are you working on this week? Did you discover something new, you want to share?

This is my first try at anything open source so any feedback is welcome :)

Hi rustaceans! What are you working on this week? Did you discover something new, you want to share?

Very impressive IDE integration for Dart macros. Something to aspire to.

VOID WRONG

It seems like I misunderstood some stuff.

Over the years, up until Rust, there were 4 ways to have a 'safe' language:

• A virtual machine (e.g. most languages today)

whether it's a high-level (scripting languages) one or low-level one (JVM, CLR)

• What C++ and similar languages do, destructors, compile-time bound checks, make a global heap and shit in it, make a local stack and piss in it, etc (basically my AllocPPx.pl but baked into the language)
• Bake the VM in with the machine code. That's what D and Go do, and I think Nim does that too. This will make the point of your language being compiled entirely moot imo.
• Finally, the most 'controversial' decision for imperative-loving chuds: make a functional language. ML/Scheme/CLisp achieve memory safety through closures. Haskell achieves this through Monads. Functional languages have a property which allows them to be be both compiled into machine code and bytecode, and also, interpreted like an scripting language.

The problem with all these approaches is the trade-off between safety and speed. There's another factor, and that is low-level access to the system. Languages like OCaml came close to achieving a balance, and that's why Rust bassed itself on it.

Most imperative languages have 'operational semantics', but not 'denotational semantics'. You can't describe what C does with math. What C does depends on the platform, the CPU, etc.

Rust's safety is achieved by 'flattening out' the memory model of a functional language like Ocaml. OCaml is a language with denotational semantics, because it's a functional language. Rust is an imperative language but it has denotational semantics. At least when comes to memory management.

I am not going to even attempt to describe the denotational semantics of Rust because I am just an amatuer and i don't have a master's in LDT. But if someoen tries, they could.

I think people might have already done it. I am not sure.

If you tell me no, and Rust does not have denotational semantics, I stand by my great-great grandfather's barber's grave that yes, it does!

So why do I say Rust 'flattens out' the functional model for memory management? It does at least with lifetimes. So imagine this: lifetimes are just 'let' bindings, but with a different syntax.

OCaml:

let rec factorial = function
  | 0 -> 1
  | n -> n * factorial (n - 1);;

Scheme

; This uses `let` under the hood
(define (factorial n)
  (if (<= n 1)
      1
      (* n (factorial (- n 1)))))  

So these two in Rust would be:

fn factorial<'a>(n: u32) -> u32 {
    match n {
        0 => 1,
        _ => n * factorial(n - 1),
    }
}

I know 'a is almost useless here, but what I meant was, that 'a makes it similar to the 'let' bindings in the prior to examples!

Semantics here is clear. Right?

But C:

int factorial(int n)  {
   if (n == 0) return 1;
   else return n * factorial(n - 1);
}

We do have operational semantics here, but who's to say what are the denotational semantics? Right? What is a 'function' in C? Well most C compilers translate it to an Assembly subroutine, but what if our target does not support labels, or subroutines?

You see what I am arriving at?

Conclusion

Rust is a semi-functional, semi-imperative language, but the difference between Rust and other languages with functional aspects is: denotional semantics!

Note: A language having lambda closures does not make it 'functional', you can do that in GNU C too ffs! Denotational semantics make it functional.

I thought this might interest you Rust folk. This is kinda like an LLVM bitcode to JVM bytecode translator. So run rustc with --emit=llvm-ir (I think that's the flag) and then pass the bitcode image to this program, then get JVM bytecode which you can make a JVM bytecode archive (JAR) from it. Could be an interesting? The author says it can JVM code from Clang output, so why not Rustc?

Keep in mind that these are two different beasts, JVM is designed for a safe virtual machine and LLVM is chiefly used to be translated into machine code. However, stupider and more wonderful things have been done with LLVM and JVM, for example, there's an LLVM to 6502 translator, so you could be making NES games with Rust.

I will test this in a few days, busy implementing my own JVM (hope I can do it) and I don't have the Rust toolchain installed on my system. But hey maybe someone can make a Cargo plugin from it (is it possible?)

Thanks, later.

#rust #rustlang