I mean… you can already kinda do that right? Raise your children to have similar values to you and they’ll vote like you when they grow up. That happens constantly. There’s just an 18 year latency to it. Obviously you lose the vote once they grow up to vote by themselves. I feel like you’re making a bit of a strawman out of what I’m saying here. We clearly just disagree and that’s okay.

The idea is that the parent represents the child. We don’t trust children to make an informed vote, but we trust parents to make all kinds of choices for their children, including extremely personal choices. The current alternative is to not give children a vote at all. I think letting parents choose the vote for their child is better, and fits pretty well with all the rest that parents currently choose for their child. I also think it’s better than simply letting children of all ages vote, since again, they probably won’t be able to make an informed vote.

In that regard, they already have representation by their parents’ votes.

But that vote only counts as much as one person, so it doesn’t give any more representation to the child if you ask me. My whole point is that a parent should have outsized voting power because they represent two persons, not one (okay actually each parent would get 1.5 votes as the child’s vote would be split on each parent but my point is the same).

Until they reach that point, it’s essentially their parents or guardians getting an extra vote.

Honestly I’ve sometimes thought that parents ought to be able to vote for their kids. At least that gives some form of representation to children.

They were also plain C functions in my case, but it doesn’t take too much discipline to only call it through the struct. Also, you can put the struct in a different crate which includes the C bindings to ensure that you can’t call the C bindings without the struct.

Just use the Mutex from the parking_lot crate.

The only time I’ve ever needed a Mutex<()> so far with Rust is when I had to interop with a C library which itself was not thread safe (unprotected use of global variables), so I needed to lock the placeholder mutex each time I called one of the C functions.

Actually I think in this case you’re still better off using a Mutex with “data” inside. I’ve done this before. The idea is that you make a unit struct MyCFuncs or whatever and then you only call the C functions from methods of that unit struct. Then you can only access those methods once you lock the Mutex and get the instance of the unit struct. It feel elegant to me.

I’m curious just because I never use ropes or knots - what kind of work or activity do you do where you use that regularly?

That’s hardly low tech, especially not the newer ones.

At least use TOML if you like ini, there is no ini spec but TOML can look quite similar.

No thanks, I’ll be staying with datastruct.nextState() rather than const nextState = prevState.nextState()

You can easily do the first option in Rust, you just use the mut keyword. That’s it, nothing more than that. And you’ll find that you quite rarely have to do that, and when you do it, it’s actually quite a useful signal to be aware of, since mutability sometimes means a bit more surprising data changes.

I wouldn’t even call that a functional feature, that’s just the language being based on expressions and bool having a then method. It’s more object-oriented in that sense if anything tbh

I really think you should give Rust a chance. It is not a functional language, like Haskell. Haskell is a hardcore purely functional language. Rust is not a purely functional language - instead it just borrows a few features and ideas from functional langauges. It also borrows ideas from object-oriented languages and it is inspired by C++ in some aspects (or has at least learned from C++, I guess you could say).

Could you maybe elaborate what it is about the functional ideas in Rust you don’t like? I really only see them as benefits - Rust is like the best of both worlds. The good stuff from functional and the good stuff from object-oriented.

The problem with classes is inheritance. Inheritance is just a bad idea and a bad way to structure stuff if you ask me.

Rust fixes this neatly with traits that basically provide the same benefits as classes without any of the downsides.

Sorry but immutable by default just makes sense. When you start coding Rust you’ll see how rarely you actually need to use the mut keyword. It’s quite rare actually.

I was kinda baffled by this too. I like the general idea that they present (you need to pay your own long-tenured engineers higher than market rate cause they actually know more about your own system), but this idea of a formula? What, are you gonna start counting git commits? A formula sounds like a super weird way to solve that problem.

Just look at the engineers that add value in your company and pay them a fair market rate. When someone leaves, find out what salary they get in the new job and ensure all your remaining engineers get at least that amount and adjust as you go along. Something like that perhaps.

The expect lint is really great, been looking forward to that for a while.

Still waiting for more flexible const generics 🤞

Could the same thing happen on the Fediverse? I mean could a community get overrun by bot posters without any actual humans posting? I’m not sure what the endgame of doing that would be.

Personally I’m a developer, so I care a lot about integrating parts of my development stack. A lot of those things don’t “just work” on Windows, or even Mac, so I’m happy to stick with Linux instead.

I’m also a developer, but I’m also a user, depending on what I’m doing. And this is a very poor excuse for Linux having bad UX.

Linux shouldn’t only be for developers, it should be for everyone.

Then again, how many examples are there for things that should “just work” and do on Linux but don’t on Windows?

Maybe some but much, much fewer. It shouldn’t be surprising - Microsoft has hundreds if not thousands of people hired specifically for creating working UX and design. Linux just can’t compete with that since it’s mostly developers working on it and, again, developers unfortunately make for awful UX designers.

I don’t think external monitors or a responsive UI is a matter of “perspective”. These are things that should just work, always, for everyone.

What are the examples you are thinking of btw?