RVA23 is pretty nice. This is the first RISC-V profile that's really viable for desktop class CPUs. (But I still wouldn't buy a RISC-V chip expecting to run Linux on it until they have proper support for UEFI, ACPI, etc. and "unified discover" is specified, which won't be for probably 3-5 years.)
To what? They don't really have any serious competition.
The documentation looks excellent!
I'm definitely going to try this for my next PCB project. I've tried basically all of the other free options (Designspark PCB, Eagle, Kicad, Geda, Horizon) and Horizon is the only one really worth using IMO (Designspark PCB is also decent).
Eagle and Geda are trash. Don't waste your time.
Kicad should be great, but they've made a number of insane UX decisions that make it really unusable in practice. Horizon is actually based on the pretty good Kicad engine but it fixes most of the UX mess.
You need them in CI anyway to check people have actually done that, but yeah you definitely don't need to have CI automatically fix formatting and commit the fixes. That's crazy.
Seems like one of the areas where Rust is least pressing, but I guess if uutils does become dominant it will be a lot easier to work on the code and add new features & tools.
I don't know I think the argument about forcing maintainers to learn Rust is probably true - sure the Rust code might not touch the DMA code, but Linux doesn't have stable APIs so in theory you're supposed to be able to change an API as long as you fix all the drivers that use it.
That now involves fixing Rust drivers, so you're going to need to know Rust.
However I don't think that's a good reason not to do it. In my opinion Linus should just be honest and say that the Rust experiment has been successful, Rust is going to be part of the kernel moving forwards, and you will probably have to get off your arse and learn it.
All this "you won't have to learn Rust" talk is thin reassurance to keep people happy. I don't think anyone really believes it.
Reminds me of when WASM was introduced and everyone was saying "the goal isn't to replace JavaScript" to keep the JavaScript folk happy, despite everyone knowing that that was exactly the goal.
I don't know why you're being downvoted. It literally starts with the word OPINION in bold red caps.
Ugh, I was working on a DIY smart lock. "I'll use Matter!" I naively thought.
Ok you need a border router for Thread support. No problem, I'll buy one. Should be cheap right since an ESP32 can handle it. Nope! You pretty much can't buy a standalone border router. All the articles are "don't worry, you might have one already if you have a Nest Hub or a Home Hub or...". Well I don't have one.
Pretty lame. I guarantee if they make a vendor neutral border router dongle you can just plug into your router's ethernet port and sell it at cost price (like £5) they'll see triple the uptake.
PDF writing isn't too bad IMO, since you don't need to understand the whole spec. I've written a PDF writer for maps from scratch and it was fairly easy and not too much code.
PDF reading though... Yeah I'm happy to leave that to people with more time and use their libraries.
A modern format would be nice, but I don't think it would be anywhere near nice enough to give up how universal PDF is.
They seem exactly the same to me: when a variable is assigned a value, it’s equal to that value now.
Yeah it's confusing because in maths they are the same and use the same symbol but they are 100% not the same in programming, yet they confusingly used the same symbol. In fact they even used the mathematical equality symbol (=) for the thing that is least like equality (i.e. assignment).
To be fair not all languages made that mistake. There are a fair few where assignment is like
x := 20
Or
x <- 20
which is probably the most logical option because it really conveys the "store 20 in x" meaning.
Anyway on to your actual question... They definitely aren't the same in programming. Probably the simplest way to think of it is that assignment is a command: make these things equal! and equality is a question: are these things equal?
So for example equality will never mutate it's arguments. x == y will never change x or y because you're just asking "are they equal?". The value of that equality expression is a bool (true or false) so you can do something like:
a = (x == y)
x == y asks if they are equal and becomes a bool with the answer, and then the = stores that answer inside a.
In contrast = always mutates something. You can do this:
a = 3
a = 4
print(a)
And it will print 4. If you do this:
a = 3
a == 4
print(a)
It will (if the language doesn't complain at you for this mistake) print 3 because the == doesn't actually change a.
What would you use instead?
FizzyOrange
joined 2 years ago
I think it's a perfectly reasonable license. You can also use it for free with closed source projects, except embedded projects (where most of the money is), which I think is generous.
I don't think everything has to be completely free. I'd much rather they had a viable business model and actually continue existing than just fizzle out because they have no funding source. Writing a high quality GUI toolkit is an enormous task so it's not really going to happen otherwise.
As much as I'm following egui, Xylem, Dioxus, Makepad etc. and hope they succeed I'd put my money on Slint being the first to make a Rust GUI toolkit of the same quality as Qt.