Traister101

So the big important part of git is that it’s a collection of commits. A branch is just a labeled commit and each commit is a list of what changed from the parent. Rebasing (the most confusing one for people) is when you fiddle with a commit from underneath yourself. Or in even more simple terms editing a parent commit. Rebasing is extremely powerful but most useful for when you notice a bug you wrote a couple commits ago. Fixing such issues via rebase (or !fixup commits you auto squash at the end) keeps your history clean. It’s as though you never wrote the bug. The other thing you do a lot with rebasing is moving your branch up in the history cause somebody updated the remote.

I wouldn’t be shocked if it was astro-terfing

Everyone from the lemmy.blahaj.zone instance that I’ve interacted with or seen have been trolls. Those guys are super weirdos idk what their deal is. It’s baffling seeing what they claim to stand for

There are a couple projects with native block chain art but as you might expect it’s low resolution pixel art due to the nature of block chain being prohibitively expensive to use as storage

Brave is forked from Chromium so hypothetically they could maintain V2 but they’d need their own store as they currently rely on Googles

Yup. The moron even admitted it too!

Counterintuitive but more instructions are usually better. It enables you (but let’s be honest the compiler) to be much more specific which usually have positive performance implications for minimal if any binary size. Take for example SIMD which is hyper specific math operations on large chunks of data. These instructions are extremely specific but when properly utilized have huge performance improvements.

Permits is only required when the compiler can’t see the extending classes. IE inner classes can extend without needing to be written out in a permits clause. This isn’t really that useful but I’ve taken advantage of it more than once so who knows

Um what? I didn’t like hide extra meaning in what I said. High quality code doesn’t imply all that extra shit you added. It’s code that’s easy to read and modify. Typically this just means you name stuff well and document things that aren’t obvious. Usually my docs explain why something exists since thinking it’s unnecessary cause you don’t remember what the original problem was a common occurrence before I started doing so.

Is high quality code ran through a formatter? I’d hope so yeah. There should be a consistent code style across the entire project. Doesn’t matter what it it long as it’s consistent.

100% code coverage is meaningless and as such a pointless metric. Also 100% coverage is explicitly tied to the implimentaion as all code paths have to be reached which is obviously not a good idea (tests have to change when the implimentaion changes as you’re testing the implimentaion not the api).

Really a lot of this is just meaningless buzz words as an attempt at some sort of gotcha. Really don’t understand how you even interpreted a statement so simple in this way.

Ah sure, like scripts and stuff. I have some absolutely atrocious python hanging out to help me do shit. I don’t have like any actual projects that are just a trash fire though

I don’t really get the code point. Like your own code written for personal projects is probably gonna be pretty high quality I’d hope? Sometimes we just write trash to get something finished but soon as I’ve had to change it… hell yeah I’m unfucking that mess, no way do I want to figure out what it does a second time.

I mean yeah but not anywhere near badly enough to be willing to deal with a phone keyboard…

ಠ_ಠ

I think primarily I don’t really care to argue about if it’s harder to write or not since it doesn’t really matter. I think the pros Rust provides are worth all it’s cons

I’d probably say it depends but I’m no Rust expert and I have no direct experience with C (though quite familiar with C++).

Basically I’d expect writing C to be easy, but not safe. IE you can quickly and easily write C that compiles but has runtime issues. Rust for the most part will catch everything but logic issues during/before compilation meaning once the program runs you’ll have very high confidence in it’s runtime behavior leading to time spent “fighting the compiler” instead of figuring out wtf is going wrong at runtime.

What Rust provides is statically guaranteed memory safety. Some C++ types will prevent memory issues however the language itself is unsafe. Playing with raw pointers is just as valid as using std::unique_ptr. In Rust however you must sign a contact (using unsafe) in order to play with raw pointers. Unsafe is you the programmer promising that you followed the rules. This is like how C++ says it’s illegal to write UB and your program will break (and it’s your fault) but enforced through a special type of block

Yes Rust is harder to write than C, that’s basically by design as it’s due to the statically guaranteed memory safety. That’s pretty magical. C doesn’t have that and neither does C++ even with smart pointers and such. Rusts unsafe keyword is poorly named, what it actually does is tell the compiler that you the programmer guarantee Rusts rules are upheld within the unsafe block.

For example

Access or modify a mutable static variable

That is a global, that’s incredibly hard to impossible to statically prove it’s safely done, so you have to do it in an unsafe block. So you violating Rusts rules within an unsafe block is actually using the unsafe block wrong. That’s not what it’s for

Unsafe Rust really just let’s you play with pointers

This is the entirety of what Unsafe Rust allows

• Dereference a raw pointer
• Call an unsafe function or method
• Access or modify a mutable static variable
• Implement an unsafe trait
• Access fields of unions

When it’s easier to think about a system in terms of objects. The classic example is video game Entities/Game Objects. GUI stuff has also been very pleasant with OOP as buttons and the like are all easily conceptualized and worked with when seen as objects.