4 points

I like to talk of ‘correctness’ (as in the objective quality) and ‘rigidity’ (subjective; generally better for larger programs and programs that need to be correct, but potentially worse for prototyping and flexibility).

Ultimately, what I care about as a programmer is, if I write/refactor/tweak some code in this language, how many weird edge-cases are ruled out or handled for me? How many unit tests do I have to write, to ensure this myself?

Python is relatively bad at that, even though it’s technically memory-safe, as the post mentions. The dynamic typing, for example, means some refactoring mistakes will just not show, unless you’ve got close to 100% integration test coverage.

So, yeah, I feel like this whole “memory safety” buzzword is lost on pretty much everyone working in a garbage-collected language, even though many of them would be extremely glad about a more correct and/or more rigid language.

permalink
report
reply
4 points

Ive never gotten to write rust professionally, but I have always kinda winder d if it was marketed wrong. My thought was always that it should be sold as “easy” though. Its easy to write code. It’s hard(er) to make mistakes.

I kinda figure there’s a bunch of systems programmers with their heads up their asses who would never be caught dead writing in an “easy” language though, so it couldn’t go that way.

(I got bored and started skimming halfway though this article, but it’s neat to hear about up and coming languages I’ll never use at the end)

permalink
report
reply
1 point

Ive never gotten to write rust professionally, but I have always kinda winder d if it was marketed wrong. My thought was always that it should be sold as “easy” though. Its easy to write code. It’s hard(er) to make mistakes.

I agree, but I don’t think the problem is marketing. The problem is how some elements of Rust’s community desperately try to upsell the language beyond the value it actually can provide, and once that fails they fall back to toxic behavior and basically just mindlessly shitting on anything that’s not Rust. It goes well beyond a cargo cult mentality, and it’s sad that a fine technology is dragged through the mud by those who were expected to show its value.

permalink
report
parent
reply
0 points

How do you succinctly call a language that has all behavior defined or equivalently no undefined behavior (aside from designated regions)? “Memory safety” is nice since it’s concise. Is there another term? Maybe just a “safe” language?

permalink
report
reply
0 points
*

How do you succinctly call a language that has all behavior defined or equivalently no undefined behavior (aside from designated regions)?

I don’t understand this fixation with undefined behavior. Its origins are in the design decision of leaving the door open for implementations to employ whatever optimization techniques they see fit without the specification get in the way. This is hardly a problem.

In practical terms, developers are mindful to not rely on those traits because as far as specifications go they have unpredictable implications, but even so they are never a problem. I mean, even in C and C++ it’s trivial to tweak the compiler to flag undefined behavior as warnings/errors.

Sometimes it sounds like detractors just parrot undefined behavior as some kind of gotcha in ways I’m not even sure they fully understand.

What problem do you think that undefined behavior poses?

permalink
report
parent
reply
1 point

What problem do you think that undefined behavior poses?

Not sure exactly what you mean, could you elaborate or rephrase? What problem does it not pose? I mean any program with undefined behaviour is basically by definition wrong. Avoiding undefined behaviour is definitely a good thing.

permalink
report
parent
reply
1 point
*

I’m just a noob when it comes to low level languages, having only been in C# and python. But I took a course on C++ and encountered something that didn’t seem right. And I asked and got the “that’s undefined behavior”. And that didn’t quite sit tight with me. We don’t know what will happen? It’ll probably crash? Or worse? How can one not know how a programming language will perform? I felt it was wrong.

Now, it’s quite some time since that happened, and I understand why it’s undefined. But I still do not think it should be allowed by default. C and C++ both are “free to do as you want” languages, but I don’t think a language should let you do something that’s undefined especially if you aren’t aware you’re doing it. Everyone makes mistakes, even stupid ones. If we can make a place where undefined behavior simply won’t happen, why not go there? If you need some special tricks, you can always drop the guard where you need it. I guess I’m just reiterating the article here though. But that’s the point for me, if something can enforce “defined behavior” by default then I’d want that.

permalink
report
parent
reply

Rust

!rust@programming.dev

Create post

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits
  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

Community stats

  • 1

    Monthly active users

  • 398

    Posts

  • 396

    Comments