TechNom (nobody) @ technom @programming.dev

Posts

0

Comments

160

Joined

2 yr. ago

This is definitely into the territory of misinformation.

I don’t write Rust, but lots of programs I use do and, as I said, they seem to crash about as much as any other compiled language tools I use are written in

I already addressed this before. Regular crashes are almost always (I can't remember any exceptions) due to panics or aborts chosen by the user - especially due to unwraps. Using that to equate Rust programs' stability to 'any other compiled language tools I use are written in' is very disingenuous - because it's just as easy to handle those errors and prevent a crash at all.

If not doing segfaults is what makes a language “safe,” then it seems to me most modern languages are as safe as Rust

You are unnecessarily conflating issues here. 'Most modern languages' are not a replacement for what C, C++ and Rust can do. Go most famously had to retract their 'systems programming language' tag, for example. If a GC language meets your requirements - then by all means, use it. But it's not without reason that many companies have rewritten even their web backends in Rust. Memory safety without GC is a very big feature that a lot of professionals care about. It's not something to dismiss as trivial.

And while at it, you neglecting what segfaults represent. It's just a benign example of memory safety bug. It's benign because it gets caught causes the program to crash. There are a whole lot of them that causes the program to continue running - causing serious vulnerabilities. This is why even the US government and agencies recommend memory safety languages and especially Rust if performance and other limitations matter.

If we include crashes, then as I said, I see Rust programs crashing about as much as any other proglang.

I really don't want to repeat the reason twice in a single comment and 3 times including in my previous comment. But the only way you are going to make Rust crash as much as 'any other prolang' is to neglect idiomatic Rust. That isn't surprising because crashing anything is possible if that's your intention.

You said bugs caused by 'memory problems'. And that Rust programmers vastly overestimate them. Those aren't generic logical bugs that you get in Go or Java. And Rust never claimed to solve logical bugs.

I don't know if you're talking about panics and abort or about crashes caused by memory safety errors. The latter class is very unlikely in safe rust, other than as rare compiler bugs. Panics and aborts are your call. You can easily write code that doesn't panic or abort.

Have you really used Rust or are you spreading FUD? I have not managed to cause even a single segfault in my 8 years of writing Rust code. Nor have I heard anyone else complaining about it, other than deliberately as proof of concept.

So you can't get a Rust program to segfault without trying really hard. I haven't observed a single segfault in the normal Rust code I wrote in the past 8 years.

That's misinformation. There's no overestimation. The problem is so bad that even the US government advocates the use of memory safe languages (including GC languages).

I have used C and C++. You need laser sharp focus to avoid memory safety errors even after you learn what causes them and how to avoid them. It's significantly easier to write programs in Rust because any lapse in care to avoid memory safety bugs are caught by the compiler.

Peter Thiel is insolent enough to say out loud what these companies practice - 'competition is for losers'. These quasi-monopolies aren't here to provide the best value - quite the opposite. They want to kill all competition by any dirty tactic and then use the diminished choice to wring the customers of every penny they have. They want to extract maximum revenue by making sure that their inferior solution is the only option customers have.

This problem isn't solvable by market regulation alone. The world has enough a*****es around who will climb to the top of successful companies and find ways around the regulations. They're being as bad as they can, while skirting the limits of what's illegal. My main gripe is with the engineers, programmers, technicians and all technical creators who enable these scumbags. It's not hard to see that supporting a proprietary solution amounts to yielding the consumers' bargaining power to a monopoly. Despite that, they keep making these choices. For example, it's not uncommon to hear senior engineering managers or technical-lead level employees saying, "I know that Chrome is spyware and I want to quit it. But this

<stupid-webservice-at-office>

If you're a technical creator, your choices matter. It affects a lot more people than you alone. But more often than not, I see such creators surrendering principles in exchange for convenience. They hold as much responsibility as the market-abusers in making the world the way it is now.

Interesting that they started dictating what you can and can't do with YOUR program! Consumer rights are a joke to these quasi-monopolies.

CUDA is an API to run high performance compute code on Nvidia GPUs. CUDA is proprietary. So CUDA programs run only on Nvidia GPUs. Open alternatives like vulkan compute and opencl aren't as popular as CUDA.

Translation layers are interface software that allow CUDA programs to run on non-Nvidia GPUs. But creating such layers require a bit of reverse engineering of CUDA programs. But they are prohibiting this now. They want to ensure that all the CUDA programs in the world are limited to using Nvidia GPUs alone - classic vendor lock-in by using EULA.

What's ironic is that rebases aren't as hard as many consider it to be. Once you've done it a couple of times, you just do it everyday as easily as you commit changes.

I find myself passing copies of values around and things like that, it might be that the compiler just takes care of that,

Rust prefers explicitness over magic. So it does what you tell it and doesn't just take care of that.

If you're copying a lot of values around (I.e cloning. Not moving or borrowing), then you're definitely doing it inefficiently. But you don't have to worry too much about that. If there are too many difficulties in borrowing, it may be because those borrows are problematic with respect to memory safety. In such cases, sacrificing performance through cloning may be an acceptable compromise to preserve memory safety. In the end, you end up with the right balance of performance (through borrowing) and safety (through cloning). That balance is hard to achieve in C/C++ (lacking in safety) or in GC languages (lacking in performance).

If that's the friction you're facing in Rust, then I would say that you're already in a good position and you're just trying too hard.

So are Haskell and Idris (well, if you consider a singing dragon as a person).

they don’t feel like your fighting the language

I really understand what you mean wrt Rust. I really do - I was there once. But it's a phase you grow out of. Not just that - the parts you fight now will eventually become your ally.

and let me feel sort of creative in the way I do things

I had the same experience with C/C++. But as the design grows, you start hitting memory-safety bugs that are difficult to avoid while coding - even after you learn how those bugs arise in the first place. Just a lapse of concentration is enough to introduce such a bug (leaks, use-after-free, deadlocks, races, etc). I've heard that C++ got a bit better after the introduction of smart pointers and other safety features. But, it comes nowhere near the peace of mind you get with garbage collected languages.

That's where Rust's borrow checker and other safety measures kick in. The friction disappears when you acquire system knowledge - concepts of stack, heap, data segment, aliasing, ownership, mutation, etc. These knowledge are essential for C/C++ too. But the difference here is that Rust will actually tell you if you made a mistake. You don't get that with C/C++. The ultimate result is that when a Rust program compiles successfully, it almost always works as you expect it to (barring logical errors). You spend significantly less time debugging or worrying about your program misbehaving at runtime.

The 'friction' in Rust also helps in another way. Sometimes, you genuinely need to find a way out when the compiler complains. That happens when the language is too restrictive and incapable of doing what you need. You use things like unsafe, Rc and Refcell for that. However, most of the time, you can work around the problem that the compiler is indicating. In my experience, such 'workarounds' are actually redesigns or refactors that improve the structure of your code. I find myself designing the code best when I'm using Rust.

but I disagree wholly that it’s the language’s fault that people can exploit their programs. I’d say it’s experience by the programmer that is at fault, and that’s due to this bootcamp nature of learning programming.

Considering that even the best programmers in the world can't write correct programs with C/C++, it's wrong to absolve those languages of the massive level of memory safety bugs in them. The aforementioned best programmers don't lack the knowledge needed to write correct programs. But programmers are just humans and they make or miss serious bugs that they never intended. Having the computing power to catch such bugs and then not using it is the real mistake here. In fact, I would go one step further and say that it isn't the language's fault either. Such computing power didn't exist when these languages were conceived. Now that it does, the fault lies entirely with the crowd that still insist that there's nothing wrong with these old languages and that these new languages are a fad.

Why no Ada or Janet? Or Haskell or Idris?

Have you tried Linux or the BSDs? Having spent a lot of time on Linux and Windows, the former feels like a well oiled machine with many fine tuning screws, while the latter feels like a rusted old trunk that needs a crowbar to get anything done.

Git owes a lot of its popularity to github. Without it, there's a good chance that mercurial would have taken over. In addition, the centralized workflow was what made both git and github popular. It simplified git usage enough to let a lot of novices get started.

I'm in no way a fan of centralization that github represents. But I think a decentralized workflow using git was a lost opportunity. People complain a lot about the git-email workflow. But I see no reason why it couldn't have become as easy as using github if the effort spent on github was spent on git-email tools and user experience.

Python is one of my primary languages (the other one being Rust). But it honestly isn't the easiest language to teach - I'm saying this from experience. There are so many concepts at play - name binding, iterators, generators, exception chains, context managers, decorators, ... . I could go on and on. Teaching becomes hard because any basic question could become a journey into the rabbit hole of python semantics.

Python is, however, a good first language for self learners. (Note: teaching vs learning). Python behaves intuitively. It's designed in such a way that if you guess something about the language, you'll probably be right.

I started from a similar background in school. Learning from books in the library and coding on a sheet of paper. Opportunities to get that in a real computer was hard to come by. Some teachers helped by pitching in to get me a few hours in the school lab. Those who like it start learning well before the resources become available. You don't need to wait till UG to gain those skills.

That said, how often do you see kids these days using a real general purpose computer suitable for coding? Like a desktop or laptop? Not phones, Chromebooks or tablets. In fact, it's bewildering these days to see programming tutorials start with a statement saying that you need such a device. It was a given, back in the day. And the other stories here don't paint a good picture.

I'm yet to hear anyone saying that chatGPT can navigate the complex series of design decisions needed to create a cohesive app (unless of course, it was trained on something exactly the same). Many people report spending an inordinate amount of time rectifying the mistakes these LLMs make. It sounds like a glorified autofill (I haven't used them yet). I shudder to think about the future of the software ecosystem if an entire generation is trained to rely entirely on them to create code.