Programming thread

[Demonslayer1776]

Any windows driver fags here? Looks like Microsoft are pushing for Rust in the kernel. Link

I have absolutely no idea how things like kernel synchronization primitives will translate into Rust though.

Honestly, I really don't see an awful amount of value in Rust drivers. A good driver should be thoroughly tested through all routes with driver verifier and there's plenty of established tools to detect leaks, tagging etc.

I also find that with my drivers that c++ is more than adequate to handle resource lifetimes for me in ctor/dtor.


So what value really am I getting creating new drivers in a language that is hacked around C anyway that is also developed by pajeets and troons?

Edit: lol at supporting shit everyone uses like this Link

I mean we just had one of the largest outages of all time last week due to an error that should have been easily caught, so we cant assume pajeets will thoroughly test things. An extra layer of security isn't a bad thing, even if its overstated. If rust was run by competent engineers who just focused on the code instead of a bunch of insufferable freaks it would probably do a solid job of addressing the problem it sets out to solve. It just gets associated with creepy sex pests, and is sold like a religion to be used in places it isn't needed.

 

[Rusty Metal Skull Gun]

Any windows driver fags here? Looks like Microsoft are pushing for Rust in the kernel.

Look at this nonsense:

#[export_name = "DriverEntry"] // WDF expects a symbol with the name DriverEntry
pub unsafe extern "system" fn driver_entry(
   driver: &mut DRIVER_OBJECT,
   registry_path: PCUNICODE_STRING,
) -> NTSTATUS {
   0
}

"driver_entry" because Rust bitches at you if you dare to deviate from the Holy Snake Case. And it's marked as unsafe, which removes a lot of the benefit of using Rust.

And pub, extern, export_name... do you really need all three of these? If so, kek

 

[Concentrate Juice]

.

All "unsafe" does is enable UB and features that directly lead to UB like the ability to handle pointers (as opposed to non-nullable references like in modern C++) and other things like reinterpret casting. It doesn't even disable the borrow checker, so you still get most of the safety benefits such as preventing UAF and race conditions.
And yeah those are needed to be compatible with the caller's conventions, much like how C++ requires extern "C" to be used for exporting compatibly mangled symbols to a C caller.

 

[SpergRush]

The reason for rust binary size is

Rust is the language of faggots. Dont make excuses for it.

brought to you by the second, worse c++ with npm-style retarded package manager: rust

Correct

All "unsafe" does is enable UB and features that directly lead to UB like the ability to handle pointers (as opposed to non-nullable references like in modern C++) and other things like reinterpret casting.

"Unsafe" is the only way to make Rust performant in the way it claims. And even then its not actually performant enough. For example, Rust does array bounds checking whenever you fuck with an array. Add extra instructions whenever I use an array... im sure you'll be faster than C in no time.

Rust is for faggots who need safe spaces. Also, its hard to learn and I didnt bother. I gave up after 30 minutes because I computer started smelling like KY jelly due to Rusts gayness.

Also because I shouldnt be waiting 30 seconds for "Hello World" to compile. Talk about a language with low development velocity.

Rust will never come close to replacing C and Zig is going to eat Rust's lunch in low-level land.

 

[StealingElectricity]

Rust is for faggots who need safe spaces.

Based

Rust will never come close to replacing C and Zig is going to eat Rust's lunch in low-level land.

Ultimately correct, though in theory Rust has a lot of nice features to improve on due to their (admittedly overhyped) design patterns (strict aliasing rules, immutability, etc). Still, most optimizations are considered either WIP or stalled for some reason, so besides the somewhat uninteresting ownership system, I don't know what else people use it for.

 

[Hall of Cost Payer]

The reason for rust binary size is because it statically compiles dependencies into the binary, which is great for portability (in userland) and not great if you are concerned about binary size. The reason C binaries in userland are small is because they are dynamically linked to most of their dependencies. In a #[no_std] environment such as a kernel driver, you don't have the luxury of a standard library and so it will not be compiled into the driver, All these dependencies will be, so you will get larger kernel drivers all packaging different versions of the same serde code, introducing more risk to the supply chain of privileged execution modes within windows.

This is only partly true. Static linking is one reason that Rust binaries are so big and it is correct that this reason doesn't apply to Kernels or Kernel modules.

But there are more reasons, for example that Rust is heavy on monomorphization which means in many cases functions over interfaces will likely be compiled for every type implementing the interface, leading to a lot of dead code. I heard that Rust wanted to tackle the issue by going harder on dead code analysis but don't know how far they are.

Additionally, I'm not sure if Rusts compiler can optimize down everything as they say. For example a builder pattern. In eg C++ I would just have on object and set the properties there, but the basic code of Rust says to create a bunch of objects and I'm not sure it gets compiled down to one object where the properties are set every time.

 

[Creative Username]

one day some nigger at sodomozilla said "hmm yes today i will make c++ but worse in almost every way" then he made a new programming language called rust

 

[Sperg Coalition]

Ultimately correct, though in theory Rust has a lot of nice features to improve on due to their (admittedly overhyped) design patterns (strict aliasing rules, immutability, etc). Still, most optimizations are considered either WIP or stalled for some reason, so besides the somewhat uninteresting ownership system, I don't know what else people use it for.

What ultimately kills Rust is also the community: it's absolutely bad and the fact that someone is at risk of interacting with trannies if they decide to ask some Rust related questions it's a showstopper for most people.
EDIT: Grammar.

 

[Concentrate Juice]

"Unsafe" is the only way to make Rust performant in the way it claims. And even then its not actually performant enough

This is simply not true. There is nothing inherent about unsafe that increases perf, plus on most benchmarks rust is competitive with C++.

Rust does array bounds checking whenever you fuck with an array. Add extra instructions whenever I use an array... im sure you'll be faster than C in no time.

The compiler elides these checks if it can (as in if you checked for it, they are removed), you can also call .get_unchecked if you're really really superstitious about it. You're not going to get any meaningful perf gains from skipping the bounds checks that you were already doing anyways.

Rust is for faggots who need safe spaces.

Sometimes faggots make great things like rust, what's your point?

Also, its hard to learn and I didnt bother. I gave up after 30 minutes

It isn't + you're bad.

Also because I shouldnt be waiting 30 seconds for "Hello World" to compile. Talk about a language with low development velocity.

And then everyone clapped, right?

Rust will never come close to replacing C and Zig is going to eat Rust's lunch in low-level land.

None of the languages mentioned here are low level, "low level" is below the CPU architecture portability level of abstraction. Nice try, kiddo.

But there are more reasons, for example that Rust is heavy on monomorphization which means in many cases functions over interfaces will likely be compiled for every type implementing the interface, leading to a lot of dead code. I heard that Rust wanted to tackle the issue by going harder on dead code analysis but don't know how far they are.

Monomorphs are a problem in C++ land as well, with all the template-based generics and all that.

Additionally, I'm not sure if Rusts compiler can optimize down everything as they say. For example a builder pattern. In eg C++ I would just have on object and set the properties there, but the basic code of Rust says to create a bunch of objects and I'm not sure it gets compiled down to one object where the properties are set every time.

Builder pattern passes the same struct instance's ownership through each function, and small functions by default are inline, so you will just get your stack allocated ahead of time and then you'll have code that does the thing to get the value for each field writing into that stack space. You can also just define your object to have its properties set where you want.

one day some nigger at sodomozilla said "hmm yes today i will make c++ but worse in almost every way" then he made a new programming language called rust

Besides the package management and static linking which you have made clear you don't like, what do you actually not like about the language itself? Like actual technical reasons, cuz I can't really understand why C++ people would dislike it beyond baby duck syndrome. Shit I'm guilty of that myself coming from a C++ background hating on rust because le tranny menace, then I actually learned it to get some genuine technical reasons to hate on it but I ended up liking it. It's like C++ if it was designed consistently while also avoiding the jeet parts of OOP that make C++ shitty to work with in legacy settings and where jeets have contributed their java-tier POOP-ing of the code.
Also, if you want someone at pozilla to blame, his name is Graydon Hoare.

 

[Sperg Coalition]

Like actual technical reasons

Rust just feels TOO stiff in comparison to C++ where I am allowed to do basically whatever I want while still choosing to write "safe" code. Both C++ and Rust do however suffer from syntax that can become overly complex to understand.
I can say though that Rust's parameterized enums are cool but other than that? I don't see a lot of benefits in using Rust as a C++ substitute.
Plus as I already said, the community is absolutely awful and if you care about your sanity you simply don't go near them.

 

[Creative Username]

Besides the package management and static linking which you have made clear you don't like, what do you actually not like about the language itself? Like actual technical reasons, cuz I can't really understand why C++ people would dislike it beyond baby duck syndrome. Shit I'm guilty of that myself coming from a C++ background hating on rust because le tranny menace, then I actually learned it to get some genuine technical reasons to hate on it but I ended up liking it. It's like C++ if it was designed consistently while also avoiding the jeet parts of OOP that make C++ shitty to work with in legacy settings and where jeets have contributed their java-tier POOP-ing of the code.
Also, if you want someone at pozilla to blame, his name is Graydon Hoare.

I honestly would like to seriously try it out and see how well I'd like it, but it feels pointless to try because the library situation is completely fucked and anything I end up making will likely require downloading tons of shit from crates.io to build, which is absolutely disgusting. If I could install libraries from the system package manager and make cargo use them, I would probably like Rust. The static linking thing honestly isn't too huge of a deal breaker, although it's still somewhat gay.

Both C++ and Rust do however suffer from syntax that can become overly complex to understand.

I also agree with this. I find C++ and Rust's syntax a bit painful to look at, and while you may retort with the fact that getting felted by syntax is a skill issue, there's no reason why you can't make a programming language pretty instead of ugly. In C++'s case, they got shot in the foot by having to make it mostly C-like. Rust doesn't have quite as much of an excuse because they had a clean slate, but they still made it look like C++. I can still program if the language looks ugly as sin, it's just not ideal.

I don't even hate Rust because of all the trannies. It is almost entirely my violent hatred for language-specific package managers that makes me hate it so much.

 

[Concentrate Juice]

Rust just feels TOO stiff in comparison to C++ where I am allowed to do basically whatever I want while still choosing to write "safe" code. Both C++ and Rust do however suffer from syntax that can become overly complex to understand.
I can say though that Rust's parameterized enums are cool but other than that? I don't see a lot of benefits in using Rust as a C++ substitute.
Plus as I already said, the community is absolutely awful and if you care about your sanity you simply don't go near them.

You can just fully ignore them, it's really not a problem. I'd like to know more about what specifically you found stiff about it, and what you were trying to achieve. As for using it as a C++ substitute, it's been a massive success for me, my colleagues and I inherited the most disgusting boomerware windows C++ & visual basic garbage you could imagine and the dude responsible left us with as much as some pencil-drawn diagrams on some old as fuck printer paper for documentation. The port to rust and golang on dockerised linux required some redesigns sure, but it was ultimately for the better, uptime and debugging has never been so good, and onboarding a college grad into the codebase went smoother than expected too.

I honestly would like to seriously try it out and see how well I'd like it

Try it, worst case scenario you spent some time gaining valuable insight on why rust is shit.

 

[Sperg Coalition]

I'd like to know more about what specifically you found stiff about it, and what you were trying to achieve.

Admittedly it has been a while since I've wrote Rust code, but I remember that when I tried learning it the lifetimes were pretty difficult to fully understand whereas C++ 's shared_ptr, unique_ptr et al were immediately understandable.
So in general, the very strict ownership and borrow stuff is what makes Rust feel extremely stiff, granted I am more used with C++ and Scheme (a Lisp dialect) where I have more freedom to do whatever I want and conversely they don't have strict rules for memory ownership.

 

[Concentrate Juice]

Admittedly it has been a while since I've wrote Rust code, but I remember that when I tried learning it the lifetimes were pretty difficult to fully understand whereas C++ 's shared_ptr, unique_ptr et al were immediately understandable.

Okay, so explicit lifetimes and and shared pointers solve different problems. the rust equivalent of shared_ptr is Rc<T>, unique_ptr is Box<T>, Arc<T> is a shared pointer but thread safe (the internal refcounter is an atomic type).

As for explicit lifetimes, you know how in C++, your RAII objects are scope-bound and auto-destruct? That is a lifetime, by default rust lifetimes behave like this, the only time when you need to explicitly define a reference's lifetime is when the lifetime could exist beyond scope boundaries, for example if you have a library that provides a context struct to be used in a callback, that context might want to have references to data owned by your caller code rather than copies of that data. The explicit lifetime definition (within the library, you won't need to do anything as a consumer of the library) is to tell the compiler that the reference to the data will exist in memory for a shorter time than the data itself, once you write that lifetime definition down into the type declaration and accompanying routines where that reference is used, the compiler will forcefully prevent you from creating code paths where that reference could exist after the data it points to is free'd. When you adhere to this and it compiles, you know for a fact that reference can't be re-used in a use-after-free heap exploit, or simply be dereferenced into un-mapped pages causing a crash.

I can see how this could be interpreted as stiffness, but it is really just to avoid improperly formed programs that allow behaviour that is pretty much never intended by the programmer. IMO this is a fantastic tradeoff to make.

 

[Owlbear]

Dave really makes me reconsider Total Boomer Death. What is it with pretty much every tech Gray Beard being lovable, humble, and generally appreciative of the opportunities they were given through the dotcom boom or the starting point of monolithic companies like Microsoft, completely the polar opposite of the greedy meritless boomer stereotypes? Is it just because you couldn't lie and BS your way to the top of that field?

You should consider Total Boomer Death again. Dave Plummer is a scammer who also very confidently lies about technology. I know a few things about storage systems and hard drives, and he says a lot of wrong things about them, for example. Here's a press release on Plummer's company:

https://www.atg.wa.gov/news/news-releases/attorney-general-s-office-sues-settles-washington-based-softwareonlinecom

This is simply not true. There is nothing inherent about unsafe that increases perf, plus on most benchmarks rust is competitive with C++.

Unsafe lets you do stuff that is faster, but unsafe. It is almost tautological that unsafe Rust can be faster than safe Rust. The fact that the troons don't generally use it doesn't mean that it has no benefits. If you have ever worked on the internals of a database, you will realize that something like a borrow checker really makes it hard to build a fast database. Incidentally, databases often get formally verified instead of using the half-measure that is a borrow checker.

Here is an example of someone using unsafe to get better performance on some code: https://users.rust-lang.org/t/rust-vs-c-vs-go-runtime-speed-comparison/104107/15

The troons gave the guy a better algorithm and helped him parallelize things to eventually beat his C implementation (which could have been ported to C also), but they needed unsafe to get close in an apples-to-apples comparison.

None of the languages mentioned here are low level, "low level" is below the CPU architecture portability level of abstraction. Nice try, kiddo.

In that case, Go can be a "low level" language, since it also has SIMD libraries for Intel, AMD, ARM, etc. Most people take "low level" to mean "no GC."

 

[Concentrate Juice]

If you have ever worked on the internals of a database, you will realize that something like a borrow checker really makes it hard to build a fast database

Absolutely why rust isn't the right tool for the job of implementing db internals. It really shines on network-facing things, as well as at security boundaries between systems and subsystems.

The troons gave the guy a better algorithm and helped him parallelize things to eventually beat his C implementation (which could have been ported to C also), but they needed unsafe to get close in an apples-to-apples comparison.

Aside from edge cases where you're gunning hard for perf everywhere, performance is comparable without using unsafe, and the difference is generally negligible between them. Enabling unsafe is just allowing the language to behaviourally be the same as the C implementation, which uses UB prone features of programming languages to achieve those things. At the micro-benchmark level, sure I'll give it to you that unsafe can result in faster implementations, but day-to-day? you won't notice the difference.

In that case, Go can be a "low level" language, since it also has SIMD libraries for Intel, AMD, ARM, etc. Most people take "low level" to mean "no GC."

Go is not a low level language, if you use that logic, then everything that runs on a computer can be a "low level" language because it ultimately ends up executing machine code. The hand-written assembly implementing the SIMD routines are low-level, the go code that calls into that is not, the library simply has an architecture-specific dependency, that doesn't make golang have that dependency.

Dave Plummer is a scammer who also very confidently lies about technology.

I think the ring-0 = kernel, ring-1 = userland thing is just an honest mistake, and he let the knowledge horizon slip a little.

 

[Owlbear]

Absolutely why rust isn't the right tool for the job of implementing db internals. It really shines on network-facing things, as well as at security boundaries between systems and subsystems.

I'll give you that Rust is a language made for web backends that need to be faster than JS, and drivers that are written by people who are too dumb to realize that dumb code is the best code. A lot of other system software relies on weird ownership structures sometimes, and yes, those weird structures and the UB do make code faster.

you won't notice the difference.

You won't measure where the difference is because the slowdowns are spread all over your code, but IME you will notice a difference. When your "Rewrite it in Rust" version is 10% slower than the C++ it replaced and uses 50% more RAM at runtime (Rust default primitives are BIG), there is no clear place to find a speedup because the entire language is just slightly slower. Rust actually gets its reputation for being "as fast as C" because people can micro-optimize around its warts in small benchmarks. In larger pieces of code, the speed difference between languages becomes apparent.

Go is not a low level language, if you use that logic, then everything that runs on a computer can be a "low level" language because it ultimately ends up executing machine code. The hand-written assembly implementing the SIMD routines are low-level, the go code that calls into that is not, the library simply has an architecture-specific dependency, that doesn't make golang have that dependency.

I agree with you that your own definition of "low level" is bad. Also, you should Google what an "intrinsic" means - you can write an equivalent of x86 SIMD ASM directly in Go/C++/Rust. The intrinsics are thin wrappers around single assembly instructions.

I think the ring-0 = kernel, ring-1 = userland thing is just an honest mistake, and he let the knowledge horizon slip a little.

The dude "lets his knowledge slip" in almost all of his videos. He is a bullshitter. He knows a few things, but if you take a junior engineer who thinks he knows everything and age him 40 years (with no corresponding gain of knowledge or wisdom), you get Dave Plummer.

 

[Kosher Salt]

A good driver should be thoroughly tested through all routes with driver verifier and there's plenty of established tools to detect leaks, tagging etc.

Well yeah, I mean pushing out a patch that overwrites the beginning of a kernel-level executable with null bytes and bluescreens the machine couldn't possibly happen. Right?

 

[Marvin]

Wrote this yesterday, didn't hit post.

More python fuckery today. Btw I'm not necessarily shitting on python in general (maybe a little bit), but it's really just this same project.

So our app is returning 500s for what should be 404s. I grab the most recent version of our dev branch, get it running and I start hitting nonexistent endpoints.

I have DEBUG set to true, I have all the logging set to DEBUG, I think.

This is still the most I'm getting in the logs:

{"request": "GET /heknowsclydecash", "user_agent": "curl/8.8.0", "event": "request_started", "level": "info"}
{"code": 500, "request": "GET /heknowsclydecash", "event": "request_finished", "level": "error"}

Some fields omitted, but you get the gist.

Even when the logging is cranked up (I guess there's maybe a trace setting I can try?), I'm still getting basically nothing useful. I even have DEBUG_PROPAGATE_EXCEPTIONS = True set.

When I set urlpatterns to just one handler, that one handler works. But if I request something not handled, I get 500s with the extremely unhelpful logging above.

So going on basically nothing, the most realistic culprit is that the django default 404 handler is shitting the bed, and yet somehow not logging the issue.

...

Oh! And as I write this, I just noticed something. I've been testing this with $ curl -v http://localhost:8000/heknowsclydecash -o /dev/null. I just got rid of the -o, and turns out, a clue! Curl's now spitting out 'HttpResponseNotFound' object has no attribute 'data'.

At first when I saw that, I felt relief. I thought, as gay as this journey has been, at long last I have something I can grep for or google for or something.

And after trying to dig that up for like 15 more minutes or so... I have nothing. I tried a few other things. I tried custom 404 handler, custom 500 handler (no clue if I'm configuring any of these properly), I'm done with this.

Honestly, this was just a 404. Clearly a 404. Should've been a 20 minute fix with 15 of those minutes trying to remember how to get the app running (it bitches if I don't have a postgres server running and have all the env variables set).

But if this codebase is this inscrutable, fuck, my coworker has guaranteed himself magnificent job security.

The “type annotations” Python added are pretty much indefensibly dumb, IMO. To get any use out of them, you need to actually run one of the type checking libraries like mypy, and the only reliable way to remember to do that, IME, is to include linting commands that run mypy, black, etc. in your Makefile, and run those in your CI or whatever. This works fine, but if you don’t set up your repo for that early on, good luck ever doing it.

Yeah, when I discovered that the type annotations didn't do anything and I started bitching to my coworker about it, he mentioned those tools.

I've got "rig up a pre-commit type checker" somewhere on my todo list. But the thought of it is giving me flashbacks to trying to migrate a medium-sized node project to typescript.

Also the whole thing where the typing module exists, but you can do list[str] or typing.List[str] is really fucking stupid. What happened to “there should be one obvious way to do it?”

Oh lol, wonderful.

I like Python a lot, but I went from a team that did their best to define and adhere to best practices, to one that didn’t give a fuck, and that made me way more understanding of the criticisms of Python. At least the new company pays more.

Yeah, that's the thing, I've used Python on and off for years. I've always liked it better than Javascript and thought it had potential, but it's the kind of language that you really need to have discipline to keep the code quality up. Because the language itself won't offer much help.

I pick it up for a project every few years and discover new things I like, new things I hate, and a bunch of new nonsense in the community.

 

[Blorgus]

https://youtu.be/wAzEJxOo1ts

View attachment 6224239

At roughly 7:43, he goes on about signing. While it's true that driver signing turnaround can be a while, this is where things like test signed drivers come into play. You can easily pass a test signed driver to QA they run it in test mode and still follow the AGILE doctrine.
While that's being tested the production driver could easily be simultaneously be signed


That way supposing testing passes then you should have your production signed driver ready to deploy in a release.