Let’s start a private equity corp called “Millennials”. Perfect camouflage!

J’ai appris aujourd’hui que tous les franquistes avaient été pardonnés/amnestiés en genre '78.

Du coup, c’est un pas en avant!

You may also interact with countless bots without ever knowing, because creating fake identities is free.

Maybe. Bots don’t seem currently capable of holding a conversation beyond surface level remarks. I think I tend to engage with thought-provoking stuff.

On the off chance that I reply to a bot, it is as much for my reply to be read by other humans viewing the conversation. So I don’t understand how interacting with countless bots is supposed to be such a big downside.

Plus, I don’t see how public/private key pairs prevents endless “fake” identity creation/proliferation. It’s not like you need a government-issued ID to generate them (which, to be clear, still wouldn’t be great -just got other reasons).

Fair, some people value their identity.

To be clear, I’m talking about online identities. In which case, I would argue that if you value it so much you should not delegate it to some third party network. My IRL identity is incredibly valuable to me, which is why I don’t tie it up with any online communications services, especially ones I have no control over.

For average people nothing changes, the app can hold their key for them and even offer email recovery.

…so then the app can post on my behalf without me knowing? And it’ll be signed as if I had done it myself. I don’t understand preferring this if you’re not also self hosting.

That’s something having signatures and a web of trust solves.

But as I wrote in my previous message regarding gpg signing circles (a web of trust), that doesn’t “solve” things. It just introduces more layers and steps to try and compensate for an inherently impossible ideal. Unless I’m misunderstanding your point here?

Besides, you fail to see another problem: Whichever centralized, federated site you use can manipulate anything you read and publish.

I just take that for granted on the internet. It’s true that key-signing messages should make that effectively impossible for all but the largest third parties (FAANG & nation-states). But you still need to verify keys/identities through some out-of-band mechanism, otherwise aren’t you blindly trusting the decentralized network to be providing you with the “true” keys and post, as made by the human author?

Anyway, if you don’t see a need for tools like nostr you don’t need them.

Maybe I’m not expressing myself properly; I don’t see how nostr (and tools like it) effectively address that/those needs.

Sort of like how there was (arguably still is) a need for cash that governments can’t just annul or reverse transactions of, yet bitcoin and all cryptocurrencies I’m aware of fail on that front by effectively allowing state actors (who have state resources) to participate in the mining network and execute 51% attacks.

It weirds me out that most of the arguments for nostr I come across are around how “you can’t loose your identity, it’s just a private/public keypair!”. Maybe I just don’t get banned enough to understand the perspective, but to me the real problem is the content/discussions being lost, not usernames for some corner of the web.

I really don’t care about loosing my identity on a social media website; I’ve found it healthier to view social media accounts on the same level as my customer account at my isp and power utility. When I change ISPs, the old account is closed down and I start up a new one at the other ISP. What’s important to me is the service getting delivered, not that it remembers that I’m the same person from however many years ago. It’s still the same me here in my body, interacting with the web. I know what I need from it, it doesn’t always need to remember who I am (and sometimes I’d rather it forgot or never knew in the first place).

My final point is a bit of a troll, but also kinda serious: how decentralized is it when your identity is “centralized” in your key pair? Loose your keys or loose your password to the key, and your identity is similarly effectively gone. Even worse in this case, no-one can restore it for you. Which is why I don’t tie my identity that much to any online service, especially ones I don’t host. The only thing that truly preserves my identity is the flesh-and-blood body that I inhabit (and even that isn’t fail-proof).

I’ve interacted with GPG signing circles before. So many people are losing access to their keys. So many more are considering some of their keys as compromised. In either case they’re regularly generating wholly new keys, essentially rebooting their “identity” from scratch. When they do so, they always rely on flesh-and-blood interactions to have their new identity verified and trusted by others.

Maybe it’s a question of which circles we’re involved in; mine are already regularly hopping accounts, without being forced to by bans or server outages. I’m used to interpreting the tone & content to recognize “people”, and ignoring usernames. On top of that so many people regularly change their display names on social media for vanity and expression purposes that I can’t reliably use them anyways for recognizing accounts.

I really appreciate Linus trying to tone down the nastiness in his replies over the years, but I’d be willing to let almost anything slide if it means getting a proper, old-school Torvalds tear-down of Musk.

Maybe nowadays, with Elon’s imbecility so publicly visible.

I’ve run Arch for close to 10 years, and was pretty jazzed by Musk in the early days of his presiding over Tesla and Space X. Then again, I was barely an adult at the time, and I hadn’t yet come across the first reports of terrible working conditions and his overall shittyness as a manager/exec.

Article is from October of 2020, I’d be interested in learning how/if things have changed since.

Right?

“Protecting vulnerable individuals” - they must mean Putin and Bibbi, not actual victims of political intimidation, sabotage, etc.

This seems right up my alley, as a fan of the Micromachines games and RTS in general.

I’ll try to give it a go when I regain a decent internet landline.

You’re welcome!

I strongly agree with the feeling that there is a hole in the current material. At the same time, given the glimpses I’ve had of the other chapters and their sections, I wonder if we “just” need to get through the rest of the book.

The current state of The Book and our progress through it as a community specifically reminds me of being at school: the lessons build on each other, and it always takes a certain amount of material covered before you start to really make sense of things and “refactor”, almost, your prior understanding.

I align with that article 's conclusion; in fact such a “fediverse browser” is exactly what I think the fediverse needs to fully replace closed/proprietary/traditional social media.

However, some of their arguments seem off. For example, for the client to be able to choose/implement it’s own sorting algorithm, it seems to me that it would need to have access to all posts. At that point, your client is just another server, with all the problems that we’re originally trying to avoid.

I have the same problem with your proposal / nostr’s approach: you may obtain a portable identity but all the “content” tied to that identity still has to live somewhere - someone else’s server or your own.

Interesting to note that this was originally posted a little over a year ago. I don’t know if anything has changed since, as I don’t self host masto and have been spending more and more of my “fedi-time” here in lemmy.

Not surprised that someone who “led AI and subscription products at Amazon for the past 8 years” ended up back on mastodon.social, but that’s probably neither here nor there…

f I may ask, what particular experience or background knowledge do you think makes you and rust such a good fit? Knowing OCaml (I’ve certainly heard of OCaml as an adjacent language to rust in terms of concepts and interests)?

Overall it’s from having gone through [most of] a Computer Science and Applied Math engineering course. Some of the courses:

• functional programming with OCaml
• proving correctness in simple programs
• Computer Architecture 101 that walked us from building simple logic gates out of transistors to simulating a 32-bit processor on an FPGA
• implementing some common collections, like Rust’s Vec or a linked list, in C
• parsing and regular grammars
• intro to compilers

This gave me an appreciation for many of the things that Rust forces you to confront head-on like stack vs heap and why stack frames are created & dropped, copy vs clone vs move, types sometimes needing to have sizes known at compile-time, and of course all the use-after-free, double-free, etc shenanigans that come from pointers.

Edit: and getting pretty familiar with Python as my primary language (which had nothing to do with attending engineering school). Rust’s traits, and the way that many of the “higher-level” language features are directly implemented using canonical traits, is very similar in practice with how Python uses “dunder” methods (=“double-underscore”, of the form __methodname__()) to duck-type its language features like iterators, collection length, collection indexing, dot notation access/manipulation, context managers, and even inheritance. Context managers in particular are almost equivalent to how Rust drops things that exit scope (they allow you to attach behavior to exiting scope in an otherwise runtime garbage-collected + interpreted language).

I would describe OCaml as if Rust had been invented from a pure maths point of view of computation, as opposed to how in reality Rust was invented from a “when can [heap] memory be predicted by the compiler to be free-able” (my own words, obviously). So you can do things like specify a “true” generic function in OCaml that infers the restrictions that apply to the valid types it can receive, and the compiler takes care of mono-morphizing that code for the various types that your program actually ends up manipulating/passing to that function at runtime. All functions are partial and composable, and to mutate things you have to explicitly delineate a block of imperative code (everything is immutable + functional by default). You end up doing a lot of pattern matching. Many problems can be compactly solved by recursively pattern matching over arrays and tuples while shuffling around the data that you’re working on (aka dynamic programming).

In relation to rust, it seems to me that it’s the sort of thing that benefits from openly engaging in directionless “horizontal” learning in order to build up a necessary foundation for then building “vertically” once enough pieces are in place. At least more so than more basic languages.

Yes. I made the analogy to biological organisms in my other reply, but you could also make one with human societies; you can’t understand a society by starting from any single member and slowly zooming out. You’ll need to at least repeat that process from multiple different starting points before you begin to form any true/deep understanding of that society as a whole. I.E., you need to examine the garbage collectors and the town priests and the brothel workers, not just the landowners or the factory workers.

I really like that “climbing a spiral” pitch! I wonder how adaptable it would be to learning Rust, however. Or rather, how one could construct said spiral differently; it already feels like The Book spirals upward and outward from a core of general/abstracted programming.

I was reading this last evening and ultimately decide against pinging you with it at the time, lol.

It directly riffs off of, and complements, the article you posted. It also speaks to your remarks on an optional garbage collector, as well as “how to think about the lifetime/borrow checker/permissions interplay”.

but I think I would have found it better to go from the basic idea of pointers as a way of not taking ownership

small quibble: String, Box, and Vec are all technically pointers that do take ownership (rather, they have ownership of what they’re pointing to). It’s really only “references” in Rust that don’t take ownership. Which, IIRC, is more or less how The Book introduces references in chap 4. So I’m not really sure how what you’re describing would differ from the current state of the book. Nonetheless, I understand the confusion that comes from “learning about” lifetimes so “late”.

I suspect Rust is so complex, and like a living organism its parts have co-evolved together so much, that there is no linear explanation or introduction that can “truly” do it justice. You sort of have to throw yourself in, and repeat that process from a handful of directions/trajectories, to start to get a cohesive idea of the whole. I say “co-evolved” notably because so much of “modern” Rust seems to me to be syntactic sugar over “core/original/2015” rust.

I haven’t gotten to the chapters on explicit lifetime annotation this time around, but I expect The Book to clearly state, then, that everything has a lifetime and the compiler actually infers most of them for you as part of this “syntactic sugar”.

The description given for Pinker’s The Blank Slate made me sceptical at best, so I went hunting for critiques and found this https://www.jstor.org/stable/27759451

Sadly it’s pay-walled beyond a preview of the first page.

For a suggestion of my own, The Mother Tongue by Bill Bryson. It’s a fun romp through the history of the English language with numerous tangents focusing on this or that quirk, written for those who have never formally studied English or linguistics.

As someone who was always more of a “STEM” person, this book completely upended my relationship to language. I used to think there was “one way” of expressing any given idea, and our job as humans, as it were, is to simply learn all the words and their meanings so as to be as precise as possible when expressing ideas. Nowadays I very much trend to see it the other way around: our use of language shapes the language itself, and our changing needs in terms of which ideas we want to express is what makes language evolve over time.

To put it succinctly, this book helped me view language as a tool that we should alter to suit our needs, not some pre-ordained scripture that we need to memorize and adjust ourselves to.

I would describe it less as “smiting god”, and more as “indirectly rescuing god from the control of the church”. Though even that is a bit simplistic.

The “she destroys magic to save humanity” bit does thematically feel very close to the ending of His Dark Materials.

I finally clicked over to the thread, and you’re totally correct; the author is clearly talking about their collective encounters with newcomers rather than their own rust “journey”.

This makes me want to share a growing hunch of mine: rust is, currently, made by and for someone like me, who’s had the privilege of developing a (rudimentary) working knowledge of the fundamentals involved in how today’s computers work, from the physics involved all the way up to something like OCaml or python, before ever hearing about Rust itself.

More specifically, there’s so much that The Book leaves assumed-yet-unsaid, even when it really tries to provide background and rationale for concepts.

I don’t think it’s reasonable to expect [The Book’s writing team] to properly teach everything that it later relies on, and it already does say that it expects a certain level of programming experience from the reader near its very beginning. I think it could use a more explicit and concrete list of “requirements”, though, like a dependency tree of prior concepts to acquire. Maybe that could help it strike a better balance between over- and under-explaining things.

Ahh, that makes a ton more sense to me! Thanks.

I like your verbiage regarding “things you do” vs “an [ambient] set of constraints”, and I would go one further (or in any case my mental model is): there are a set of valid states or configurations for references that is smaller than (and contained within) the set of possible or imaginable configurations.

By configuration, here, I kinda literally mean “the state of the program/machine executing the program, as that execution plays out”. So, “3 read-only borrows of some piece of data” is a valid configuration, while “2 simultaneous mutable borrows” is an invalid state for the program to be in. It’s sort of the same conceptual approach as types: you express the valid/allowed configurations that are (almost always) a subset of the overall possible states. Except in this case, it’s the language that has defined it once, ahead of time, rather than us programmers who define things as we go. Maybe that just gets us back to the same point that wasn’t originally clicking for you, though.

Sidenote: I wonder if a language could be developed that allowed the programmer to define or setup their own set of constraints around lifetimes and references. Sort of like what Zig seems to allow for memory allocator/allocation strategies, but specifically for ownership semantics. As I type this out, I can’t shake the feeling that this is basically what Rust has already done with their & vs &mut vs Box vs RC vs RefCell etc. It’s not like there is a way to safely have 2 mutable references to the same memory/variable that is both general and simpler than existing mechanisms.

Re: lifetime notations, it’s good to know that this helped you. For me it was the combination of encountering the particular part in chap 4 of The Book where they examine the case of a function that accepts a tuple and returns a ref to the first element (or something along those lines), and trying to define (and then use) a struct that would store a ref to some other data in a hobby project.

Overall, this makes me realize how much of Rust I have already internalized!

Hmmm. On the one hand I heavily agree with the analogy to read only and write exclusive locks (I think I gave it myself in the ownership chapter recap/discussion thread). On the other, I feel like this is singling out “references” for something that is much broader in cause.

I could just as easily say that references in rust are “just” references, and that it’s the rules around ownership (like the compiler automatically dropping things when changing scope) that restrict what you can do with them, in practice.

I dunno, given rust’s history and explicit purpose of preventing memory errors, notably in multi threaded code, if you still assume you can just take a reference to “any object in memory” and do whatever you want with it then you either haven’t paid enough attention to how the book introduces references or maybe rust isn’t cut out for your way of thinking.

There are ways to do raw pointers in rust if you need to. But then you need to more or less do all of the compiler’s job yourself, notably figuring out when you can safely free that memory.

In other words, references don’t exist on their own, and so how the author describes them “in other languages” feels to me like they never had to implement a language themselves and safely deal with shared references, nor use them that thoroughly in a language with “general” references like C. Otherwise I don’t think they would have developed this mental model that expects references to be considered their own thing, almost separate from the underlying data.

I can’t tell if the author is inexperienced with languages that “do a lot” and have a more cohesive design, or is so much more knowledgeable and experienced than I that they’ve already taken this into consideration and are arriving at this point regardless.

Lignes claires comme Tintin, oui.

Merci en tout cas pour ces liens, ça me fait découvrir !