[–] 3 points 2 months ago (2 children)

For the problem of linking back to your instance, I wonder if it would make sense to define a new URI scheme for fediverse links. Websites and apps can handle it directly when a user is logged in, or let an external app handle it otherwise.

  • source
  • [–] [S] 1 point 9 months ago*

    I'm not saying that there's a problem with doing things one way or another. Rather, I'm asking whether there's a problem with doing things differently that then led to this design decision to be made with Rust. I want to better understand how this language came to be.

  • source
  • parent
  • context
  • [–] [S] 1 point 9 months ago (2 children)

    The term “meta-programming” had me lost since I’m only familiar with that in reference to C++ templates (and Rust’s generics are more like templates).

    Yes, like C++ template and macros. The kind of code that generates new code before being run.

    So to answer your question as to why there are macros, it’s because you need to generate code based on the input. A function call can’t do that.

    You can design a language where you don't need to generate code to accomplish this. My question isn't why this is necessary in Rust. My question is why Rust was designed such that this was necessary.

    Someone mentioned elsewhere that this allows for compile-time type safety. I'm still trying to wrap my head around how that works.

  • source
  • parent
  • context
  • [–] [S] 1 point 9 months ago* (7 children)

    C++ was my first programming language. I remember the nightmare of dealing with dependencies and avoiding boost because it felt wrong to need a third part library for basic features. The toolchain for Rust is very nice (not just compared to C++, but all other languages I've worked with) and has so far been a huge joy to work with. The language itself too. I'm just curious about why the language likes to expose more of its features through meta-programming rather than directly in the language itself. Things like println! and format! being macros instead of functions, or needing a bunch of #[derive(Debug,Default,Eq,PartialEq)] everywhere for things that other language provide through regular code.

  • source
  • parent
  • context
  • [–] [S] 6 points 9 months ago (10 children)

    I'm not talking about what features are in the standard libraries vs third party libraries. I mean meta-programming as in the stuff that generates Rust code. Take console printing for example, we use a macro println! in Rust. Other languages provide an actual function (e.g. printf in C, System.out.println in Java, print in Python, etc). The code for my first project is also full of things like #[derive(Debug,Default,Eq,PartialEq)] to get features that I normally achieve through regular code in other languages. These things are still in the Rust standard library as I understand it.

  • source
  • parent
  • context
  •  

    Is it just me, or does Rust feel much more bare-bones than other languages? I just started learning it recently and this is the one thing that stood out to me, much more so than the memory management business. A lot of things that would normally be part of the language has to be achieved through meta-programming in Rust.

    Is this a deliberate design choice? What do we gain from this setup?


    Edits:

    1. Somehow, this question is being interpreted as a complaint. It's not a complaint. As a user, I don't care how the language is designed as long as it has a good user experience, but the curious part of my mind always wants to know why things are the way they are. Maybe another way to phrase my question: Is this decision to rely more on meta-programming responsible for some of the good UX we get in Rust? And if so, how?
    2. I'm using meta-programming to mean code that generates code in the original language. So if I'm programming in Rust, that would be code that generate more Rust code. This excludes compilation where Rust gets converted into assembly or any other intermediate representation.
    How reliable is SnapRAID? (programming.dev)
     

    SnapRAID doesn't compute the parity in real time, so there's this window between making a change to the data and syncing where your data isn't protected. The docs say

    Here’s an example, you acquire a file and save it to disk called ‘BestMovieEver.mkv’. This file sits on disk and is immediately available as usual but until you run the parity sync the file is unprotected. This means if in between your download and a parity sync and you were to experience a drive failure, that file would be unrecoverable.

    Which implies that the only data at risk is the data that's been changed, but that doesn't line up with my understanding of how parity works.

    Say we have three disks that store 1 bit of information and a parity drive: 101 parity 0. If we modify the data in the first disk (data 001 parity 0), then the data is out of sync. Say we now lose disk 2 (data 0?1 parity 0). How does it then recover that data? We're in an inconsistent state where the remaining data tells us that drive 2 used to hold 0^1^0=1 when it actually held a 0. So doesn't that mean that between any modifications and a sync operation, all your data in that disk region is now at risk? Does SnapRAID do anything special to handle this?