Sure, but this was more about being downvoted. Gimp is a great project, and they clearly took a lot of inspiration from a commercial product (Photoshop) that is now offering the exact tools that I was asking about. I don't think my question was out of line, at all.
Doesn't matter what the name is, as long as people remember it. Trust me, the name "GIMP" is not what's holding their project up. It's competition with Adobe and the likes.
However it's great that they're making gradual progress. I've used Gimp for years.
That name reminds me of PUBG and Proton-GE (specifically the GE part). Both awkwardly named after one person's internet handle. If sufficiently shortened, and ideally also pronounceable, I think it can work. With that in mind, "CSAS" might not be the best, though maybe people could pronounce it "Sergeant Sea-Sass". Then the biggest problem I see is the # of syllables, but if you've already established context, you could probably shorten it further in subsequent usage to "Sea-Sass" or CSAS only, which is only about as bad as "LDAP".
It's kinda common knowledge at this point that almost all Smart TV's suck, especially Samsung. I went the Samsung route as well - the TV itself is fine, but the software is horrible.
The solution (that I hope everyone knows about by now) is to buy an Apple TV and connect it. Once the TV starts, it shows Apple TV from the get-go and not any of the Samsung stuff.
> The solution (that I hope everyone knows about by now) is to buy an Apple TV and connect it. Once the TV starts, it shows Apple TV from the get-go and not any of the Samsung stuff.
Or just connect the TV to your PC where you have the freedom to run whatever software you want. Why replace one crappy "smart" device with another.
Not every non-US country. Most people in Norway have iPhones, so iMessage is heavily used. They also use Facebook messenger a lot for some bizarre reason.
Zig is a much simpler language than Rust. I'm a big Rust fan, but Rust is not even close to a drop-in replacement for C. It has a steep learning curve, and often requires thinking about and architecting your program much differently from how you might if you were using C.
For a C programmer, learning and becoming productive in Zig should be a much easier proposition than doing the same for Rust. You're not going to get the same safety guarantees you'd get with Rust, but the world is full of trade offs, and this is just one of them.
For me, where linked lists, graphs and other structures are a common need, zig gives me slices and deferred frees.
Rust is double expensive in this case. You have to memorize the borrow checker and be responsible for all the potential undefined behavior with unsafe code.
But I am not a super human systems programmer. Perhaps if I was the calculus would change. But personally when I have to drop down below a GC language, it is pretty close to the hardware.
Zig simply solves more of my personal pain points... but if rust matures in ways that help those I'll consider it again.
Correct me if I am wrong, but Rust at least has a borrow checker while in C (and Zig) one has to do the borrow checking in their head. If you read a documentation for C libraries, some of them mention things like "caller must free this memory" and others don't specify anything and you have to go to the source code to find out who is responsible for freeing the memory.
Rust gives two reasons for the borrow checker, iterator invalidation and use after free.
As I have always bought into
Dennis Ritchie's loop programming concepts, iterator invalidating hasn't been a problem.
Zig has defer which makes it trivial to place next to allocation, and it is released when it goes out of scope.
As building a linked list, dealing with bit fields, ARM peripherals, etc...; all require disabling the Rust borrow checker rules, you don't benefit at all from them in those cases IMHO.
It is horses for courses, and the Rust project admits they chose a very specific horse.
C is what it is, and people who did assembly on a PDP7 probably know where a lot of that is from.
I personally prefer zig to c... but I will use c when it makes the task easier.
The point is that any formal borrow checking will reject perfectly valid patterns because they are impossible to statically prove, and this comes up especially often with data structures like graphs. So you end up struggling against the compiler - either you just go unsafe (in which case you have to be even more careful than in C and Zig because Rust makes more optimization assumptions based on ownership which you're now responsible for), or else you use hacks like using indices instead of pointers to, basically, work around the borrow checker.
You are describing the deficiencies of Rust implementation of a borrow checker and disregarding general benefits of it. Obviously there could be some way to mark self-referencing objects.
C/Zig do not even allow to specify who is responsible for freeing the allocation, and every time you use a library you need to either search the docs or (more often) reverse-engineer the code. Probably this is why writing or checking C code is so slow. I end up adding annotations to function prototypes but nobody is going to validate them so they only serve as documentation.
Well, we are comparing real world languages, so of course I'm going to talk about the limitations of the actual checker that Rust has. That said, is there a better (as in fewer false positives without giving up safety) implementation of lifetime tracking out there? I mean, fundamentally, the problem is that the question ultimately boils down to telling what the code will do without running it.
C and Zig have exactly the same facility to let you specify who's responsible for allocation - owning vs non-owning types for resources; it's just that you have to write them by hand, and for types that are owning, destructor calls must be done explicitly (but still, the pattern of "if I got an instance of OwnedFoo, I need to call destroy() on it" is much more straightforward then chasing the docs for each function).
reply