zlacker

[parent] [thread] 51 comments
1. Pragma+(OP)[view] [source] 2022-10-02 15:12:48
I’ve been using Rust for a while, and I’m so, so tired of hearing this argument.

Yes, we know. We get it. Rust is not an absolute guarantee of safety and doesn’t protect us from all the bugs. This is obvious and well-known to anyone actually using Rust.

At this point, the argument feels like some sort of ideological debate happening outside the realm of actually getting work done. It feels like any time someone says that Rust defends against certain types of safety errors, someone feels obligated to pop out of the background and remind everyone that it doesn’t protect against every code safety issue.

replies(7): >>TillE+D2 >>chrsig+i3 >>flohof+L3 >>jmull+R3 >>Yoric+0f >>oconno+wg >>pjmlp+Pv
2. TillE+D2[view] [source] 2022-10-02 15:29:13
>>Pragma+(OP)
It's really common to see people say meaningless stuff like "Rust is a safe language" which is either deeply confused or deeply misleading.

Rust provides certain guarantees of memory safety, which is great, but it's important to understand exactly what that means and not to oversell it.

replies(1): >>pornel+T4
3. chrsig+i3[view] [source] 2022-10-02 15:33:21
>>Pragma+(OP)
I mean, it's felt like anytime anyone mentions any code base not written in rust, someone pops in and points out that it's not safe, and should be rewritten in rust.

I think it's all part of the language maturing process. Give it time, zealots will either move on to something new (and then harass the rust community for not meeting their new standard of excellence) or simmer down and get to work.

replies(1): >>IshKeb+l32
4. flohof+L3[view] [source] 2022-10-02 15:35:06
>>Pragma+(OP)
> Rust is not an absolute guarantee of safety and doesn’t protect us from all the bugs.

That's not exactly the vibe I'm getting from the typical Rust fanboys popping up whenever there's another CVE caused by the usage of C or C++ though ;)

Rust does seem to attract the same sort of insufferable personalities that have been so typical for C++ in the past. Why that is, I have no idea.

replies(3): >>lucasy+C4 >>Test01+R4 >>ok1234+ej
5. jmull+R3[view] [source] 2022-10-02 15:35:42
>>Pragma+(OP)
I think it keeps getting said because there appear to be a lot of people who don't understand this.
◧◩
6. lucasy+C4[view] [source] [discussion] 2022-10-02 15:40:06
>>flohof+L3
It protects against the leading 70 percent of CVEs, which are due to memory safety issues. This is all Rust has ever claimed to solve and it's all I've ever seen anyone cite when advocating for it.

If these people are insufferable to you, that I can't change your mind on. That said you might want to get used to it since major areas of industry are already considering C/C++ as deprecated (a paraphrasing from the Azure CTO recently)

replies(1): >>Test01+B5
◧◩
7. Test01+R4[view] [source] [discussion] 2022-10-02 15:41:38
>>flohof+L3
I wouldn't say the Rust community parallels the C++ community in any way. The rust community is more like the insufferable Haskell/FP community who, despite producing very little measurable commercial value continue to look down on everyone else.

Indeed, there's a lot of damage control going on in this thread walking back Rust's guarantees of safety despite that, up until this point, being Rust's only real selling point. It seems like every C/C++/Go/whatever repository has at least one issue suggesting a complete rewrite in Rust.

replies(6): >>ChrisS+A7 >>Wastin+X8 >>avgcor+Og >>timeon+Vl >>mwcamp+rp >>Pareto+wFa
◧◩
8. pornel+T4[view] [source] [discussion] 2022-10-02 15:41:51
>>TillE+D2
It's an unproductive pedantry to expect every mention of the generalisation to be followed by a full disclaimer about exceptions and edge cases.

People say "it's raining" without having to add "except under roofs".

replies(4): >>lifthr+29 >>II2II+w9 >>mslm+1R1 >>phendr+Jgb
◧◩◪
9. Test01+B5[view] [source] [discussion] 2022-10-02 15:45:51
>>lucasy+C4
I didn't know the Azure CTO was the CTO was the C++ community. I'm sure the billions of lines of code written in C++ for the finance industry would love to have a word.

The insufferable nature of the people isn't the advocating of safety. It's that Rust seems to have evolved a community of "X wouldn't have happened if Y was written in Rust!" and then walking away like they just transferred the one bit of knowledge everyone needed. They occupy less than 1% of the programming community and act like they single-handedly are the only people who understand correctness. It's this smug sense of superiority that is completely undeserved that makes the community insufferable. Not the safety "guarantees" of the language.

replies(2): >>znpy+Td >>lucasy+Hg
◧◩◪
10. ChrisS+A7[view] [source] [discussion] 2022-10-02 15:57:30
>>Test01+R4
There's no "walking back" here. From Rust 1.0 the language was "guaranteed memory safety" https://web.archive.org/web/20150516132407/https://www.rust-...
◧◩◪
11. Wastin+X8[view] [source] [discussion] 2022-10-02 16:05:19
>>Test01+R4
> Haskell/FP community

As someone who worked on a lot of OCaml projects, I would like to assure you that the issue really is the Haskell community which I too find completely unbearable. The rest of the FP community is far nicer/less smug.

For a long time, they just thought it was a shame some innovative constructs seemed to be stuck in their favourite languages (first class functions, variant types, inference) and not percolating to the mainstream. This fight has mostly be won which is great.

replies(1): >>jstimp+he
◧◩◪
12. lifthr+29[view] [source] [discussion] 2022-10-02 16:05:41
>>pornel+T4
I think, if the wording was exactly "Rust is safe" it is indeed too vague as there are many notions of safety, and annoyingly enough people do say this. But "Rust provides memory safety" is clear enough and doesn't need further quantification.
replies(1): >>pornel+Ma
◧◩◪
13. II2II+w9[view] [source] [discussion] 2022-10-02 16:08:14
>>pornel+T4
Think of it as elaborating, rather than disclaiming. There is a real problem in the realm of Rust advocacy where people make a blanket claim, either wrongfully assuming it is true or assuming that others are aware of the limitations of the claim. This is a problem when the reader is not aware of the limits of what is being said, while creating conflict when the reader calls out the limitations.

Reading a book on Rust programming is an entirely different matter since authors tend to elaborate upon what they are claiming. The reader has to understand how things work and what the limits are. As such, there is less opportunity for misinformation to spread and less room for conflict.

◧◩◪◨
14. pornel+Ma[view] [source] [discussion] 2022-10-02 16:15:02
>>lifthr+29
Official Rust materials are careful not to overpromise and to be clear on the extent of what is guaranteed and what isn't.

The safety is always with an asterisk. Rust provides memory safety — provided that unsafe blocks, FFI, and other code running in the same process, and the OS itself, and the hardware doesn't misbehave.

But if you accept that Python and Java can be called safe languages then Rust can be too. The other ones also have unsafe escape hatches and depend on their underlying implementations to be correct to uphold safety for their safe side.

replies(1): >>HelloN+Tj
◧◩◪◨
15. znpy+Td[view] [source] [discussion] 2022-10-02 16:29:47
>>Test01+B5
> They occupy less than 1% of the programming community and act like they single-handedly are the only people who understand correctness.

Maybe I’m too young (just past 30) but is it just me or is that some kind of attitude that emerged in the last 10-15 years?

And I mean not only in programming, but in general.

A small amount of people which is very vocal about something and start pushing everybody else to their thing while simultaneously shaming and/or making fun of those who either disagree or aren’t generally interested.

I kinda see a pattern here.

Either way, it’s very annoying.

Going back to the rust topic… I recently started working with some software written in a mix of C++ and Java. I don’t own the codebase, I “just” have to get it working and keep it working. So i had to reach to another person for some performance issues and this guy starts the usual “should be rewritten in rust” … jesus christ dude, I don’t care for your fanboyism right know, either help me or tell me you won’t so I’ll looks somewhere else.

And of course, if as an outsider this is the experience I have to go through every time I deal with rust people… I’ll try to minimise my exposure to such people (and to the language, if necessary).

replies(1): >>ok1234+3k
◧◩◪◨
16. jstimp+he[view] [source] [discussion] 2022-10-02 16:31:39
>>Wastin+X8
To be fair, the Haskell hype train has long passed, and I never perceived the Haskell community as insufferable. They're just preconcerned formulating everything in way too mathsy frameworks to the point of being extremely inproductive as from a "real world" programmer's perspective.
replies(1): >>Pareto+UFa
17. Yoric+0f[view] [source] 2022-10-02 16:35:27
>>Pragma+(OP)
It's really weird.

I keep seeing claims that Rust users are insufferable and claim that Rust protects against everything. But, as someone who has started using Rust around 0.4, I have never seen these insufferable users.

I imagine that they lurk on some communities?

replies(2): >>lifthr+yj >>3a2d29+Vj
18. oconno+wg[view] [source] 2022-10-02 16:42:39
>>Pragma+(OP)
Fwiw, the original article/email is less about "Rust has unsafe" and more about "panicking/crashing to avoid triggering UB isn't a viable strategy in the kernel."
replies(1): >>pas+Og1
◧◩◪◨
19. lucasy+Hg[view] [source] [discussion] 2022-10-02 16:43:57
>>Test01+B5
This is not the first time it's happened. JS is effectively deprecated in favor of TS in the hearts of programmers in that ecosystem. There was a lot of disagreement about this a decade ago, but TS is now at its 10 year anniversary and any serious project in that world should be written with static type definitions. It had the early adopters that were insufferable at the time, but they were right about the path and those that have jumped in are having a way better experience.

I think history will show that we can do a lot better than C/C++ and Rust is one of the best steps yet to show that. Rust will be replaced by something better some day and the cycle will repeat.

◧◩◪
20. avgcor+Og[view] [source] [discussion] 2022-10-02 16:44:14
>>Test01+R4
There’s nothing to walk back since the post does not contest Rust’s safety guarantees at all. The link is (by design or not) effectively click bait “Linus Torvalds says that Rust is not really safe”, when in reality it is just him saying that panicky (panic on programmer error) Rust code is inappropriate for the kernel and that Rust-in-Linux code should by default limp on when it has encountered an error. That is a perfectly reasonable point to make, but has got nothing to do with “safety” in the sense that the Rust project talks about that term.
◧◩
21. ok1234+ej[view] [source] [discussion] 2022-10-02 16:58:34
>>flohof+L3
When the CVEs appear in Rust, they use that as proof that their technology is better because they found those errors. Or, those were just unsafe and therefore not "real" Rust.
◧◩
22. lifthr+yj[view] [source] [discussion] 2022-10-02 17:00:26
>>Yoric+0f
I believe it boils down to hasty generalization, where you only recall (or are aware of) a few particularly noisy Rust users and take them as a representative of all Rust users. This kind of stereotype is unfortunately very hard to break.
◧◩◪◨⬒
23. HelloN+Tj[view] [source] [discussion] 2022-10-02 17:01:58
>>pornel+Ma
All this safety, as Linus points out, is safety for plain programs, but a complex of serious problem for the kernel. "Safe languages" are only safe up to a point and in context; Rust has clearly been designed to write safe applications, not safe kernels.

So if some enthusiasts are trying to use Rust at cross purposes for Linux they are likely to appear obnoxious and entitled, and it is perfectly right to challenge them to prove that they can make Rust suitable.

There's more high quality and polite preaching earlier in the thread, for example:

  > Please just accept this, and really *internalize* it.  Because this isn't actually just about allocators. Allocators may be one very common special case of this kind of issue, and they come up quite often as a result, but this whole "your code needs to *understand* the special restrictions that the kernel is under" is something that is quite fundamental in general.
◧◩
24. 3a2d29+Vj[view] [source] [discussion] 2022-10-02 17:02:05
>>Yoric+0f
Okay, just to fact check this. I am a fan of Rust, but pretending there aren't these aggressive rust users is a bit putting your head in the sand.

Like any language that has very cool features, there are people that take that tool as not a tool but a religion.

You can even look in my comment history and see people arguing with me when I say I was a rust fan, but memory safety isn't a requirement in some areas of programming. One person made it there mission to convince me that can't possibly be the case and in (in my example of video games) that any memory bug crashes and game and will make users quit and leave.

replies(1): >>maxbon+3l
◧◩◪◨⬒
25. ok1234+3k[view] [source] [discussion] 2022-10-02 17:02:34
>>znpy+Td
>A small amount of people which is very vocal about something and start pushing everybody else to their thing while simultaneously shaming and/or making fun of those who either disagree or aren’t generally interested.

It's called manufacturing consent and it's all around us.

replies(2): >>znpy+qE >>vlovic+JE
◧◩◪
26. maxbon+3l[view] [source] [discussion] 2022-10-02 17:08:00
>>3a2d29+Vj
I, too, have not encountered these toxic Rust fanboys. I don't believe my head is in the sand. I do regularly see people degrading Rust and it's community, and so am convinced these toxic Rust fanboys are largely a myth based on uncharitable interpretations of otherwise reasonable statements. I think people often read "I advocate for the deprecation of all C/C++ codebases" into the statement "Rust is a 'safe' language, for a certain meaning of that term," but I don't think it's actually common to advocate for such a deprecation outside of security-critical applications.

I feel like it's a defensive reaction, that people feel like Rust is seeking to obviate arcane skills they've built over the course of their careers. Which I don't think is true, I think there will always be a need for such skills and that Rust has no mission to disrupt other language communities, but I can understand the reaction.

> You can even look in my comment history

Is this the thread you're referring to?

https://news.ycombinator.com/item?id=32878868

Because I genuinely don't see what you're talking about. No one seems to "make it their mission" and no one seems to be arguing for Rust in particular, as much as this category of languages.

replies(2): >>moldav+ps >>3a2d29+Uy
◧◩◪
27. timeon+Vl[view] [source] [discussion] 2022-10-02 17:13:05
>>Test01+R4
This seems to me more like wishful thinking. The post is barely talking about memory safety. You have confused combination of title and some post reacting to title of the post.
◧◩◪
28. mwcamp+rp[view] [source] [discussion] 2022-10-02 17:31:50
>>Test01+R4
I wonder if the Rust community now is similar to what the C++ community was like when C++ was as young as Rust is now. Any old-timers want to comment on this?

Edit to add: My guess is that the Rust community might still be worse because now we have widespread Internet access and social media.

replies(1): >>pjmlp+Cw
◧◩◪◨
29. moldav+ps[view] [source] [discussion] 2022-10-02 17:48:07
>>maxbon+3l
I've seen both sides of this, as a Rust user and as a Go user.

Rust users are generally friendly to one another, and to people who are interested in Rust. Hoever, some Rust users are toxic when talking to people outside the community or to people who disagree.

That's why a lot of us (in the Rust community) don't notice it; we spend most of the time inside our own community talking to each other and being friendly to each other.

This is a trait common to any bubble or insular community whether it be about politics, religion, economics, or whatever. It's fairly easy to recognize once you get in the habit of dis-identifying with your own side.

There's also a phenomenon in human psychology where we tend to forgive "our side's" misbehavior, presumably because it's in service to a higher ideal and therefore forgivable. It's the difference between "passionately spreading the good word" and "aggressive evangelism", two views of the same action. After learning about this I've even seen it in myself, though hopefully I've learned to counteract it a bit.

Note that this isn't unique to Rust, other languages have this too to an extent.

It's something I really hope we can leave behind, because it's hurting an otherwise beneficial message that Rust can bring a new tradeoff that is favorable for a lot of situations.

replies(2): >>lifthr+Ew >>Yoric+fO
30. pjmlp+Pv[view] [source] 2022-10-02 18:06:19
>>Pragma+(OP)
It is the same argument that C folks used against Modula derived languages, Object Pascal and Ada.

If there isn't 100% safety then why bother, it is the usual argument for the last 40 years.

◧◩◪◨
31. pjmlp+Cw[view] [source] [discussion] 2022-10-02 18:12:33
>>mwcamp+rp
And back then we had flamewars on comp.lang.c and comp.lang.c++, hence the .moderated versions of them.

I always been on the C++ side, when arguing on C vs C++ since 1993, already considered C a primitive option, coming from Turbo Pascal 6.0, and finding such a simplistic pseudo-macro assembler.

So yeah, in a sense the Rust community is similarly hyped as we were adopting Turbo Vision, CSet++, OWL, MFC, PowerPlant, Tools.h++, POET, and thinking C would slowly fade away, and we could just keep on using a language that while compatible with C, offered the necessary type system improvements for safer code.

But then the FOSS movement doubled down on C as means to write the GNU ecosystem, on the first editions of the GNU manifesto, and here we are.

◧◩◪◨⬒
32. lifthr+Ew[view] [source] [discussion] 2022-10-02 18:12:48
>>moldav+ps
> Hoever, some Rust users are toxic when talking to people outside the community or to people who disagree.

I'm not even sure if this is the case. I have seen enough toxic Rust users, but at least in my experience they rarely overlap with who are active in the community. This suggests that they are experiencing typical newcomer syndrome, comparable to Haskell newcomers' urge to write a monad tutorial, and also explains that why a disproportional number of non-Rust users observe toxic Rust users---if you are a Rust user but don't preach about Rust everywhere, how can others tell if you are indeed a Rust user? :-)

◧◩◪◨
33. 3a2d29+Uy[view] [source] [discussion] 2022-10-02 18:27:27
>>maxbon+3l
No I am not referring to that thread. I am referring to the thread further down where someone compares using a memory unsafe language to an illegal activity.

If you need an example of the rust community being toxic, I give you https://github.com/actix/actix-web

Look up the history and realize they bullied an open source project leader into leaving open source for good.

replies(1): >>maxbon+3B
◧◩◪◨⬒
34. maxbon+3B[view] [source] [discussion] 2022-10-02 18:39:45
>>3a2d29+Uy
So this thread? https://news.ycombinator.com/item?id=32879558

I still don't understand the relevance, this neither appears toxic nor to be a discussion of Rust; this looks like they put forward an out-there idea and you didn't care for it, which just seems like a discussion about consumer protection laws. I also don't see the connection from Actix drama to the idea that people are exaggerating the capabilities of Rust or causing problems for other language communities - I don't know much about it, I'm fully willing to believe toxicity was involved, but a breakdown in communication between a maintainer and their community doesn't seem like the behavior we're discussing and I don't see any evidence this was peculiar to Rust and not a phenomenon in open source at large.

I don't want to relitigate some thread I wasn't even a part of, I just don't understand.

replies(2): >>3a2d29+wJ1 >>3a2d29+HK1
◧◩◪◨⬒⬓
35. znpy+qE[view] [source] [discussion] 2022-10-02 19:01:33
>>ok1234+3k
If you’re citing the book from 1988, that looks interesting, I’ll add that to my to read list.

If not, would you care to drop some links?

◧◩◪◨⬒⬓
36. vlovic+JE[view] [source] [discussion] 2022-10-02 19:04:01
>>ok1234+3k
That’s extremely ungenerous. I see the legitimate challenges with Rust as do most people I talk with who are C++ veterans. But we also all agree that C/C++ isn’t tenable in the long term. It might not be Rust that wins eventually but only because a better alternative pops up. Without a better alternative it’s going to be Rust. And let me tell you. The Rust team to date has been very good at building a very attractive ecosystem and bringing people along. The people who are Rust advocates that I’ve come across tend to be extremely thoughtful individuals and not just fanboys latching onto something cool.
◧◩◪◨⬒
37. Yoric+fO[view] [source] [discussion] 2022-10-02 20:10:10
>>moldav+ps
Fair enough.
◧◩
38. pas+Og1[view] [source] [discussion] 2022-10-02 23:26:52
>>oconno+wg
it might be in a virtualized/development env. but otherwise that's why all those defensive coding practices are recommended in low-level code. to deal with this.
◧◩◪◨⬒⬓
39. 3a2d29+wJ1[view] [source] [discussion] 2022-10-03 03:43:00
>>maxbon+3B
I think the part where I have several negative votes on those comments, despite making points I think are valid, is what I don’t like.

My understanding is that negative votes is for things that don’t contribute to discussion, yet all my comments are in the negatives except when I mentioned I actually am using rust. Then suddenly the commenter stops talking about our discussion all together and starts to mention learning rust.

It’s frustrating because I like rust, but I can’t seem to criticize it in the slightest.

◧◩◪◨⬒⬓
40. 3a2d29+HK1[view] [source] [discussion] 2022-10-03 03:58:48
>>maxbon+3B
Not to mention there was this whole issue: https://news.ycombinator.com/item?id=29501893

After saying everyone was empowered to use their tool, they tried to kick someone off the team for working for Palantir.

Regardless of politics, kinda unfair to make political statements using the rust accounts, then turn around and say other people can’t be part of rust because they work for a company who is political.

◧◩◪
41. mslm+1R1[view] [source] [discussion] 2022-10-03 05:17:47
>>pornel+T4
Except everyone understands it's not raining under roofs. When someone says 'Rust is safe', they assume it infallible. It's been oversold.
◧◩
42. IshKeb+l32[view] [source] [discussion] 2022-10-03 07:25:57
>>chrsig+i3
Well they're right. Most code written in C is horribly unsafe. Most code written in Rust is very safe. No code is guaranteed to be 100% safe - not even formally verified code.

There's a clear safety spectrum, with C near the bottom and Rust near the top. It's tedious for people to keep saying "well it's not right at the top so we should just keep using C".

I'm sure pro-seatbelt people were called "zealots" back in the day too.

replies(3): >>greyha+V03 >>chrsig+oW3 >>phendr+lgb
◧◩◪
43. greyha+V03[view] [source] [discussion] 2022-10-03 14:43:15
>>IshKeb+l32
> Most code written in C is horribly unsafe.

I think that is untrue. I worked at the Network Systems arm of Bell Labs for sixteen years, and we could demonstrate five-nines of uptime on complex systems written entirely in C.

C is a rough tool, I will grant you that, and Rust is a welcome addition to the toolkit, but saying that most code written in C is horribly unsafe, does not make it true.

replies(1): >>paoda+fj3
◧◩◪◨
44. paoda+fj3[view] [source] [discussion] 2022-10-03 15:57:49
>>greyha+V03
Perhaps I misunderstand, but I don't imagine most individuals or companies writing production C code to be on the same "level of competency" as a research company as prestigious as Bell Labs.
replies(1): >>pjmlp+854
◧◩◪
45. chrsig+oW3[view] [source] [discussion] 2022-10-03 18:34:02
>>IshKeb+l32
The issue isn't correctness. The issue is annoyingness.

> I'm sure pro-seatbelt people were called "zealots" back in the day too.

Given that vehicles were grandfathered in, pro-seatbelt people were irrelevant to owners & drivers of said vehicle.

Just like some rust zealot asserting that some existing project with millions of lines of code should be rewritten in rust is irrelevant to the project maintainers.

◧◩◪◨⬒
46. pjmlp+854[view] [source] [discussion] 2022-10-03 19:14:43
>>paoda+fj3
UNIX was found to be less secure than Multics, thanks to the additional safety guarantees provided by PL/I type system.

https://www.acsac.org/2002/papers/classic-multics.pdf

So not even back then.

◧◩◪
47. Pareto+wFa[view] [source] [discussion] 2022-10-05 16:28:47
>>Test01+R4
> insufferable Haskell/FP community who, despite producing very little measurable commercial value continue to look down on everyone else.

I just took a break from creating measurable commercial value in Haskell.

Grab a Starbucks, shop at Target, or use Facebook recently?

Congrats, you used production Haskell code delivering measurable commercial value to you and millions of others.

◧◩◪◨⬒
48. Pareto+UFa[view] [source] [discussion] 2022-10-05 16:30:12
>>jstimp+he
> To be fair, the Haskell hype train has long passed, and I never perceived the Haskell community as insufferable. They're just preconcerned formulating everything in way too mathsy frameworks to the point of being extremely inproductive as from a "real world" programmer's perspective.

See my comment upthread, you seem to be misinformed on the use and prevalence of Haskell in the real world.

◧◩◪
49. phendr+lgb[view] [source] [discussion] 2022-10-05 19:02:47
>>IshKeb+l32
Rust isn't seatbelts, Rust is a tank. It's hard to steer, you need 4 people to operate it, but it's safe from bullets. It can also sink in quicksand or mud very easily. Rust advocates ignore the usability problems and say "Drive a tank everywhere, it's bullet-safe". Meanwhile the average programmer will get lost in the complexity of Rust and invent shortcuts like using unsafe {} in exactly the wrong place.
replies(1): >>dureui+vUn
◧◩◪
50. phendr+Jgb[view] [source] [discussion] 2022-10-05 19:04:57
>>pornel+T4
This is the patronizing attitude that keeps getting Rust advocates into trouble. "I don't need to be pedantic, I know better than you, so I'll just simplify my argument down to the point that it's actually a lie, but you'll thank me later"
◧◩◪◨
51. dureui+vUn[view] [source] [discussion] 2022-10-10 06:45:18
>>phendr+lgb
This runs contrary to my experience.

1. Coming from C++, my productivity is x2-x3 in Rust, making Rust a middle point between C++ and Python (about x8 productivity). What's more, if we factor maintenance time in, the lower costs of maintenance of Rust code makes the multiplier tend to x10, which is equal or better than Python (whose maintenance costs are important).

2. I have a colleague coming from Python (so a very different background than my C++ background), and he doesn't "get lost in the complexity of Rust" but after some use of Rust makes pretty much the same conclusions as I do: initial coding slower than Python, but roughly equal when you factor in maintenance time. He now writes the quick tools that could be Python scripts in the past in Rust when we suspect that they won't be one-off scripts (which happens very often). We get ease of distribution (static binaries), portability (to Linux and Windows), and better performance out of it too.

Although this is a comparison with C++ and Python, not C, the reasons why are simple and apply equally so to C:

1. Easy access to a good ecosystem. Adding dependencies in C or C++ is a pain. Very easy to do in Rust, preventing the need of reinventing the wheel (squarely). C suffers even more from this, given its lack of standard library and data structures (everything is a linked list :-D)

2. Memory safety and lack of UB in safe Rust brings a definitive simplicity in coding, code review and debug.

3. Result-oriented APIs and generally expressive type system are what end-up bridging the gap with Python with time.

What Rust definitely has is a learning curve. It is not optimized for taking the language without deep diving into it, or learning it in a short time. IMO it is a reasonable trade-off, given that the experience past the learning curve is so good, and that many of the things that make the learning curve so steep are integral to that experience (exclusive borrows, trait system, ...).

replies(1): >>phendr+e7y
◧◩◪◨⬒
52. phendr+e7y[view] [source] [discussion] 2022-10-13 05:55:15
>>dureui+vUn
You misunderstood my argument. My argument is that if forced to use Rust (given, say, a tectonic shift in the coding world where Rust becomes dominant - something many people are clamoring for), most average developers would have a difficult time writing secure code, because they'll have to keep a higher level of complexity in mind. Productivity is irrelevant. This is the classic trap of not being able to measure thing ABC, so you measure thing XYZ and assume that it's the same.

TL;DR: Let's see what happens when average C programers are forced to use Rust. Will their code be more secure? I see no convincing arguments one way or the other. Only measuring XYZs.

[go to top]