New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Which isn't necessarily a bad thing as long as you never pass a NULL pointer into the function. Sure, safety checks are nice but doesn't anyone think of the 5 cycles wasted on the CMP and the possibility of a mispredicted branch?
I do perl alot and javascript and c++, python very little I just can't get into a language that depends on indentation, thats just nuts....
I didn't mean to say that functions like these don't exist in standard libraries of these languages, but these are usually bad implementations that production code avoid, so that people end up using 3rd party libraries anyway.
Well, i wouldn't necessarily call Cs standard library badly implemented. The overall design is a total mess though (and i say that as someone who loves C). In my opinion a lot of the initially stated gripes with Cs memory management to a good part come from exactly that.
Just having something very basic like a general/transparent linked list implementation or an actual string builder drastically changes how the resulting code looks and what most time writing it is spent on. The downside of this is that it becomes kinda tempting to throw overly complex functionality at problems just because its nicer to write though.
The
randfunction in the standard C library is the source of many CVEs. Nobody should use it in production code if you actually need randomness.I'm not going to challenge you on that but then i feel like you are bit cherry picking there. Who in their right mind would blindly rely on rand and just without question expect it to produce cryptographically secure results?
You can obviously construct a bunch of scenarios where you make a wrong assumption and shoot yourself in the foot. A standard library isn't supposed to be a universal be all end all answer and C isn't a safe-by-default language. Make an assumption without knowing and chances are it'll come back to bite you. Nothing really special or surprising about that. The average user wants/needs a reasonably random number that's what rand gets him.
Besides, which implementation are you referring to anyways? There's no the standard library. Some might very well come up with something non-predictable. If that's an important property the person writing the code will obviously still make sure to get it one way or the other. Actually the fact that you don't really know what you will practically get when calling rand will be more than enough reason to make very sure it provides what you are expecting when it's about finer details.
Why choose a programming language that looks like c but not all features of c. Its like buying a ferrari without the v12 motor.
Indeed:
https://man.openbsd.org/rand
"Standards insist that this interface return deterministic results. Unsafe usage is very common, so OpenBSD changed the subsystem to return non-deterministic results by default. To satisfy portable code, srand() may be called to initialize the subsystem. In OpenBSD the seed variable is ignored, and strong random number results will be provided from arc4random(3). In other systems, the seed variable primes a simplistic deterministic algorithm."
Yeah, about that...
Is that a transformed Nissan Leaf or a real Ferrari?
This guy here is turning his Nissan Leaf into a Ferrari and saving huge money.
That is a good representation of the new political correct c like hipster languages.
Hipster "programmers" are always too bold making excuses and too shy to do the hard work, blaming the tool is one of their favorite sports.
I think it is a very powerful and useful language for scripting due to its memory safety and great performance. However, I think for bigger projects like the Linux kernel, there is no place for it.
I personally like Rust as a language, but I hate the culture that surrounds it. I think it's replacing memory safety issues with supply chain issues, since even the most trivial program is going to pull in many third party components.
Rust is quite ugly, but Go gains most of its safety from runtime checks, which reduces performance. Rust gains almost all of its safety from compile-time guarantees, so its performance can match C and C++. So Go is great, but if you need a replacement for C/C++, then Go might not be enough.
u wot m8
I don't code Rust so I can't speak from a Dev point of view, but I find building/compiling Rust applications is quite involved because of Cargo. It might be that I'm not well enough informed to have an opinion, and it's quite possible I just don't know what I'm doing, but in my limited experience the build process is clunky and comes with a lot of overhead.
Rust feels like a language designed by people who got tired of debugging production at 3AM. Go asks you to be disciplined. Rust assumes you aren't.
Most people don't hate Rust's syntax, they hate being told by the compiler about bugs they would have found in production.
So rust is a tool for the undisciplined? I get it, makes total sense.
Now, may I know who the heavy cargo is for?
That is the new Ferrari Luce, designed by Jony Ivey and costing $535,000...to look like a Nissan Leaf.
For the PR and lolz, Nissan should sue.
Rust is the vegan of programming languages. The information that a program is written in rust or a dev uses rust is always provided to you without your initiation.
Cargo's the one piece the Go crowd quietly wishes they had. To be fair to my own take, though: I didn't say Rust is for the undisciplined. I said it assumes you are, and budgets for it. Go trusts you to remember the lock, close the channel, check the err. Rust assumes 3AM-you won't, so it drags that cost forward to compile time, instead of production (a pager and an incident write-up).
Who's the heavy cargo for? Anything where a 3AM crash costs more than an afternoon losing arguments to the borrow checker, payment rails, schedulers, anything holding money or state. For a CRUD API behind a load balancer? Go all day.
So if you don't need to be babysat then you don't need Rust but in many important situations you need to be babysat and Rust does the job with competence. Cargo plays an important part as it enables Rust to do its "magic."
I get it! Baby sitters can be somewhat inconvenient but in some situations they are indispensable.
Huh? I think you have that backwards.
The Golang or Python standard library is the one piece the Rust crowd quietly wishes they had, because it eliminates so many supply chain attacks.
And besides, what's the difference between "go get" with a Github URL and "crate"? Both add a wide variety of third party packages to your project.
The difference is that with Golang you don't need to use third-party packages so much.