7 ms·

I've been doing programming for ~31 years in total and ~22 years professionally and at this point I have lost all hope that programmers at large will ever gain

I've been doing programming for ~31 years in total and ~22 years professionally and at this point I have lost all hope that programmers at large will ever gain these mythic qualities called "self-reflection" and "introspection". Truth is, these people are simply afraid for their cozy jobs, that's all there is to it. Derivative states of mind like Stockholm Syndrome and Sunk Cost Fallacy are quite normal to appear in these conditions. On OP: I could not agree more. People always downplay their fuck-ups, that's sadly part of being a Homo Sapiens, but the lack of awareness is still both despairing and hilarious to watch. And finally, C/C++'s niches have decreased but these people will not adapt, of course. Almost anything I've done with those languages 15-20 years can today be done with Rust. Or if you are on a tight time budget -- Golang, and you still won't lose too much speed. But sure, "nothing can be done, these things sometimes happen". Sigh.

Xeamek 2y ago
Eh, Rust would be fine if not for the fact that it's too opinionated. Unfortunately you can't just have Rust's safety checks, without opting into restrictions that Rust designers force onto You that aren't inherent to safety checks, but more because 'that's a better practice (according to us)'. And also, easy and fast iteration just isn't there, both because of borrow checker restrictions and compile times
- eterevsky 2y ago
  Unfortunately you have to pick 2 out of: - Lack of restrictions - Safety - Performance If you choose safety and no restriction, you pay the price in performance (for GC etc.)
  - Xeamek 2y ago
    Again, restrictions that are forced you for a price of safety are one thing. But what I'm complaining about are restrictions that don't have to be there to get borrowchecker working, but rather are there because designers arbitrary decided "it's better this way".
    - komali2 2y ago
      As someone just starting to finally learn Rust, I'm curious what some examples of this might be.
      - flohofwoe 2y ago
        All AFAIK, since I only dabble occasionally in Rust: The borrow checker works on "struct granularity", but it would be much more flexible and convenient if borrowing would work on memory location granularity (for instance passing a struct reference into a function "taints" the entire struct as borrowed, even if that function only accesses a single item in the borrowed struct - this 'coarse borrowing' restriction then may lead to all sorts of workarounds to appease the compiler, from 'restructuring' your structs into smaller pieces (which then however may fit one borrowing situation, but not another), or using 'semantic crutches' like Rc, Cell or Box. There are also related restrictions about function call barriers. AFAIK the Rust compiler cannot "peek into" called function bodies to figure out what's actually going on inside those functions (and that information would be very valuable for fine-grained borrow checking), it can only work with the information in the function signature. Again, disclaimer: take this with a grain of salt since I'm not a daily Rust user, but this is how I understood why Rust feels so restrictive.
        pdimitar 2y ago
        > The borrow checker works on "struct granularity", but it would be much more flexible and convenient if borrowing would work on memory location granularity (for instance passing a struct reference into a function "taints" the entire struct as borrowed, even if that function only accesses a single item in the borrowed struct - this 'coarse borrowing' restriction then may lead to all sorts of workarounds to appease the compiler, from 'restructuring' your structs into smaller pieces (which then however may fit one borrowing situation, but not another), or using 'semantic crutches' like Rc, Cell or Box. That's valid, thanks for pointing it out. I seem to recall the team lately mentioning they are starting to consider fixing that. And yes that's a real productivity killer, happened to me as well in the past.
        2y ago
  - flohofwoe 2y ago
    There's a massive Terra Incognita to explore between Rust on one side and Python on the other side (just to pick two extremes). It's not "2 out of 3", it's a triangle where a language can pick a sweet spot anywhere within the triangle (and ideally, it's not a "sweet spot" either, but more like a "sweet area" where the programmer can pick an actual spot within that area defined by the language).
    - pdimitar 2y ago
      That sort of extreme flexibility simply does not exist. I mean it does but then you are firmly in the dynamic languages territory and you are forgoing any hope for close-to-the-metal performance.
      - flohofwoe 2y ago
        IMHO it does and its not restricted to dynamic languages (like JS or Python), look at this Zig function signature for instance (just an example from my current dabbling): fn setData(comptime pins: anytype, bus: anytype, data: u8) @TypeOf(bus) In practice this looks and feels like dynamic typing, yet when looking at the compiler output it still resolves to optimal code (since it's "compile-time dynamic typing" not "run-time dynamic typing", but the difference in practice is surprisingly small).
        SpaceNugget 2y ago
        I'm not super familiar with Zig, but that appears to be the same as the rust function signature fn setData<P, B>(pins: P, bus: B, data: u8) -> B; in rust, the P and B are resolved at compile time, not at runtime. If you wanted dynamic dispatch the types would be Box<dyn B>
        flohofwoe 2y ago
        Yes, it's essentially the same, the comptime attribute on the pins arg is quite important though (in the function body that's not shown).
- self_awareness 2y ago
  Most programmers don't have any opinions, so if they use an unopinionated language, they end up using patterns that opinionated people use. So it's better to have one source of truth for opinions, so that we don't end up using the "wrong" opinions of people who talk more than they think.
  - flohofwoe 2y ago
    Compiler/language people are also just "opinionated people" though. Some have good opinions, some have bad opinions. In the worst case you have opinions which are the result of a 'design by committee/community' process.
    - self_awareness 2y ago
      Single source of truth of opinions can be challenged and changed if one's arguments are good enough. The benefit is that it's easier to see the advantages and disadvantages for those opinions, because they're all in the same place. This is in contrast to C++, where one organization creates a set of guidelines, another organization creates another set of guidelines. Valid arguments of critique in one organization are not seen in the other. Single source of truth is also beneficial to compiler authors as well, because they get more feedback how the language is used and why.
- pdimitar 2y ago
  C/C++ being non-opinionated is the main source of the security vulnerabilities. Let's face it, it felt good to be a lone cowboy carrying a lot of responsibility and knowing what you are doing. I was there myself and I'll admit the ego trip was awesome. These times are long past and naturally, people refuse to adapt. > Unfortunately you can't just have Rust's safety checks, without opting into restrictions that Rust designers force onto You that aren't inherent to safety checks, but more because 'that's a better practice (according to us)'. Show me something that does better and I'll switch tomorrow. But don't tell me C/C++ are better -- they are not. Too much freedom leads to CVEs literally every month somewhere and that's only because we don't have better vetting and checking tools, otherwise I'm sure we'd be getting one every day for a while. > And also, easy and fast iteration just isn't there, both because of borrow checker restrictions and compile times I agree on that, that's why I mentioned Golang. Most of the C/C++ systems I worked on around 15-20 years ago didn't need the close-to-the-metal speed because at least 90% of their time was spent on I/O... frak, even Python would have done well there. And Golang is times faster. It's a very nice compromise if you want to be productive and don't care super much about CPU speed efficiency.
  - Xeamek 2y ago
    There are restrictions out on You by the borrow checker to ensure safety, and then there are restrictions put on You by rust design team 'just because'. Again, the former are fine, it's the latter I have a problem with.
    - pdimitar 2y ago
      In order for me to agree on the "just because" part you'll have to give some examples. What made you think they are arbitrary? And how did they prevent you from doing your job?
      - Xeamek 2y ago
        Comment above, mentioned borrowing while structs instead of borrowing memory. I believe this was once discussed under term 'partial borrows', but the "idiomatic" aproach is to 'just split your structs'. Which isn't really a good aproach to structuring codebase, it's just to appeal to borrow checker inflexibility. Lack of global scope. Lack of function overloading.
- scotty79 2y ago
  Rust is just a different language. It's not C-like or Java-like plus checks or anything like that. It's a value oriented language. Variables mean something completely different than in any other common language. Everything is about the values and where they are kept at the moment.
- hdjksndhsi 2y ago
  So a few things .. Rust is a very good safe language. It also has an unsafe keyword to make the compiler ignore borrows etc. If you want fast iteration, use python and then hand transpile your code into rust. Not every tool has to be used at once ... but Python for the idea and rust for the implementation can be the best of both worlds ... :)
  - Xeamek 2y ago
    Except Rust's unsafe is even worse then any other 'unsafe' languages. And while you can technically prototype in a other language, speed of iteration is always a bottleneck. The only way to escape it is if You are an about master of language, the project you are working on and even the feature you are adding. But that's a verry rare case scenario
    - pdimitar 2y ago
      I don't disagree btw. As a contractor I have found myself very often in a situation where Rust's slower iteration simply didn't work for me so I got back to Elixir and also relearned and started getting proficient in Golang. Rust's slower iteration only disappears when you become a pro as you said and that's my main problem with it. I simply can't invest as much time and effort for free.
yau8edq12i 2y ago
I program MCUs as a hobby. I wish I could use something better than C. Even C++ with RAII would be better. But somehow, even C++ support is spotty, with unsupported features, broken debugging, etc. for seemingly no reason. And all device-specific libraries are written in C, so I'd have to write C++ wrappers for every little thing. Send help...
- pdimitar 2y ago
  That's why I said "almost anything". I am aware that f.ex. kernel development and embedded work is still firmly in the C domain. I am not evangelizing for Rust, Golang or anything in particular. I am evangelizing for periodically asking yourself "Am I still using the best tool for the job?" which most people never do.
  - nottorp 2y ago
    Actually, maybe Rust would get more people interested if it didn't sound like a religion...
    - pdimitar 2y ago
      Maybe it's you and some other curmudgeons projecting -- worth to consider if that's the case. Maybe it's normal for people to praise something that legitimately solved their problems. I know that happened with me.
      - glass-z13 2y ago
        There is a difference between praising and preaching, the latter happens more often with rust
        pdimitar 2y ago
        If you say so. ¯\_(ツ)_/¯ But even if it was true (I'd contest it's not) can't you ignore it and judge the language on its merits? We are not teenagers for a long, long time now, we should be making up our own mind about things.
jokteur 2y ago
I would love to be able to use Rust in my professional project. Unfortunately, I am doing high performance scientific computing. Rust doesn't even come close to offer any good alternative to cross-plateform, cross-device (CPU/GPU) libraries such as OpenMP Target, Kokkos, SYCL, ... I believe we need Nvidia/AMD to take Rust seriously (I'm not sure it is even possible without unsafe everywhere) to be able to offer good libraries. In my world, using C++ is the modern language, because most project are stuck with Fortran.
- pdimitar 2y ago
  That's completely valid and that's why I said "almost anything" -- other things include kernel development and embedded. My broader point was that C/C++ are still kings in some areas but people insist on using them where a bunch of languages do better today.
  - miki123211 2y ago
    Also cross-platform libraries, if you want to be everywhere, from computers and phones to set top boxes to weird Japanese rtoses you haven't even heard of, Rust just won't cut it.
    - p_l 2y ago
      Fortunately there are other languages that are more available cross-platform than Rust with its tiny Tier 1 list. Unless ofc you're contractually obligated to use vendors half-arsed kludget together patchy version of GCC of unknown provenance that they compiled with barely half C support, let alone other GCC languages.
- pjmlp 2y ago
  At least C++ provides the tools to avoid this kind of problems, if one choses to do so, instead of insisting into C idioms.
  - Shorel 2y ago
jalapenos 2y ago
This is one possibility. Have you considered the other, that you're the old-man-yells-at-cloud variety of narcissist? Hence why you choose to interpret things as everyone (except you) is defective. Everyone (except you) is laughable, completely lacking in self-awareness, refusing to adapt and be and do as they should (according to you of course). Because they're all lesser than you! That's why. You write Rust. So obviously, you're so far above them. Like a God looking down at monkeys. Couldn't be reasons like inertia, or lacking the time, or not having the budget to change, or being too tired to learn, or any other such thing that'd let them be equal to you but just with differing priorities. No, because then you wouldn't get your narcissistic supply, allowing your delusion you're better than others, rather than a man distracting himself from his own failings? Just an alternative theory. What do you think?
- pdimitar 2y ago
  > Couldn't be reasons like inertia, or lacking the time, or not having the budget to change, or being too tired to learn, or any other such thing that'd let them be equal to you but just with differing priorities. This is already included in the "almost anything" expression and you are the 4th person deliberately (or accidentally?) not noticing it. There are valid cases for C/C++ both on technical merits and business specifics. I have not denied that. --- The rest of your comment is just projection borne out of your faulty assumptions about my comment and it's thus not interesting at all.
  - FdbkHb 2y ago
    > This is already included in the "almost anything" expression and you are the 4th person deliberately (or accidentally?) not noticing it. I genuinely think that : 1/ this field is dominated by a disproportionate amount of people with autistic traits 2/ their ability to reason only functions in the narrowest sense and their grasp of language (takes everything in the most literal sense, thinks in extremes, prone to putting things in boxes, have a very, very strong attachment to their routine and are unable to ever leave the comfort zone they constructed) makes any attempt at communication beyond painful. I have come to not even bother replying to people who are unable to understand human words such as when they interpret "most" as meaning "all" or "rarely" as "never" as it's one of the telltale signs that it is going to be extremely unproductive. This phenomenon is the cause of most pains and drama. Once you start to see how this pattern develops you understand the true cause of the endless bikeshedding, of why even the idea of having a code of conduct can raise endless anger and storms and so on. You're touching a comfort zone so the temper tantrums are thrown. The routine has been built and it must continue until the end of times. If there's any field in this world that is in need of more neurotypical, emotionally stable adults, this is it.
deleted 2y ago
[deleted]
anon-3988 2y ago
No, more people should be using memory managed languages like Java and Golang. Then educate and expose people to sum types and pattern matching. It is actually insane how people is still unconvinced about sum types. Imagine how insane it is to program without product types? That's exactly what it felt like.
- pdimitar 2y ago
  > It is actually insane how people is still unconvinced about sum types. Oh don't even get me started on this but I agree sooooo much. > No, more people should be using memory managed languages like Java and Golang. Well, I use both Golang and Rust depending on the need. We can have both, it's not an either-or.
  - amarant 2y ago
    I'm feeling my lack of academic training here, but I needed to make sure. When you say sum types, are you referring to enums, or is it a broader concept than that? The Wikipedia article was quite archaic but seemed to support my initial understanding that you're talking about enums. Are you talking about enums?
    - pdimitar 2y ago
      Yes, I am talking Rust enums and OCaml's enumerated data types.
      - williamcotton 2y ago
        Or what F# calls a Discriminated Union.
    - tialaramex 2y ago
      Rust's enum is a sum type. The enum in C is just integers (again) wearing a hat for some reason. This may not be obvious, but if my enum in C seemingly has three possible values it... doesn't, it actually has at least hundreds of possible values, but only three have names - it's just an integer in a hat. A sum type is an idea from type arithmetic. Suppose we have two types A and B, and we want to produce a new type from those, the most common provision in languages is to let you make a product type, it has all the values of A multiplied by all the values of B, this may be available to you as a named tuple, perhaps named a "struct" or "class" in your preferred language. But what if instead we added these types instead of multiplying them? The new type has the values of A plus the values of B ? That's a sum type. Suppose I have three types which resemble booleans: mood (it's either happy or sad), size (huge or tiny) and activity (either sleeping or eating) A sum type of these three would allow me to make a "brief" of a cat as one of the six values, either as its mood, its size or its activity. The cat brief can be sad, or sleeping, or tiny, but it cannot be sleeping and sad [in this model] any more than a cat's size could be both huge and tiny. There are 2 + 2 + 2 = six values of the brief type. In contrast a product type, maybe lets call that "state" of the cat consists of separate values of each of the three constituents, so the state of a cat might be (sad, tiny, sleeping) or (happy, huge, eating) or any other combination. There are 2 * 2 * 2 = eight values of this state type. Just as an arithmetic is kinda crap if it only has multiply but not add, a type system is kinda crap if it can't make sum types. Where complicated hard-to-get-right hacks are used (e.g. C++ std::variant) these are often unsatisfying both ergonomically and in terms of delivered functionality, so hence the desire to have actual sum types in the language.
GoblinSlayer 2y ago
It's possible to write systematically safe code in C, no need to change language. People really just don't want to do it.
- pdimitar 2y ago
  Maybe it is but the last several years of periodic (and quite embarrassing) CVEs suggest otherwise.
  - GoblinSlayer 2y ago
    What they suggest? What I and the discussed article claim is that safe code isn't written because programmers don't want it. CVEs aren't caused by desires, they are caused by unsafe code.
    - pdimitar 2y ago
      Many people suggest to start gradually migrating to either Rust or start investing much more seriously in formally proving C/C++ code (which is IMO a huge endeavor). As I said in multiple other comments, I know there are valid cases for C/C++ where various factors prevent migration. I am not playing a little rebel revolutionary here, I am addressing the people who can migrate away but refuse to do so based on hand-wavy philosophy clashes (or my favorite petty rebellious take: "people praise Rust, I must resist using it!"). Petty stuff and I am pretty disappointed that people who bill themselves as "engineers" refuse to see objective evidence and hold on to only what they know. Those are the people I address with my comment. Not the people who will be never allowed to migrate away a 2 million lines worth of C codebase. They have my deepest sympathies.
      - GoblinSlayer 2y ago
        I didn't propose to migrate to rust.
        pdimitar 2y ago

Xeamek 2y ago

Eh, Rust would be fine if not for the fact that it's too opinionated. Unfortunately you can't just have Rust's safety checks, without opting into restrictions that Rust designers force onto You that aren't inherent to safety checks, but more because 'that's a better practice (according to us)'. And also, easy and fast iteration just isn't there, both because of borrow checker restrictions and compile times

eterevsky 2y ago
Unfortunately you have to pick 2 out of: - Lack of restrictions - Safety - Performance If you choose safety and no restriction, you pay the price in performance (for GC etc.)
- Xeamek 2y ago
  Again, restrictions that are forced you for a price of safety are one thing. But what I'm complaining about are restrictions that don't have to be there to get borrowchecker working, but rather are there because designers arbitrary decided "it's better this way".
  - komali2 2y ago
    As someone just starting to finally learn Rust, I'm curious what some examples of this might be.
    - flohofwoe 2y ago
      All AFAIK, since I only dabble occasionally in Rust: The borrow checker works on "struct granularity", but it would be much more flexible and convenient if borrowing would work on memory location granularity (for instance passing a struct reference into a function "taints" the entire struct as borrowed, even if that function only accesses a single item in the borrowed struct - this 'coarse borrowing' restriction then may lead to all sorts of workarounds to appease the compiler, from 'restructuring' your structs into smaller pieces (which then however may fit one borrowing situation, but not another), or using 'semantic crutches' like Rc, Cell or Box. There are also related restrictions about function call barriers. AFAIK the Rust compiler cannot "peek into" called function bodies to figure out what's actually going on inside those functions (and that information would be very valuable for fine-grained borrow checking), it can only work with the information in the function signature. Again, disclaimer: take this with a grain of salt since I'm not a daily Rust user, but this is how I understood why Rust feels so restrictive.
      - pdimitar 2y ago
        > The borrow checker works on "struct granularity", but it would be much more flexible and convenient if borrowing would work on memory location granularity (for instance passing a struct reference into a function "taints" the entire struct as borrowed, even if that function only accesses a single item in the borrowed struct - this 'coarse borrowing' restriction then may lead to all sorts of workarounds to appease the compiler, from 'restructuring' your structs into smaller pieces (which then however may fit one borrowing situation, but not another), or using 'semantic crutches' like Rc, Cell or Box. That's valid, thanks for pointing it out. I seem to recall the team lately mentioning they are starting to consider fixing that. And yes that's a real productivity killer, happened to me as well in the past.
      - 2y ago
- flohofwoe 2y ago
  There's a massive Terra Incognita to explore between Rust on one side and Python on the other side (just to pick two extremes). It's not "2 out of 3", it's a triangle where a language can pick a sweet spot anywhere within the triangle (and ideally, it's not a "sweet spot" either, but more like a "sweet area" where the programmer can pick an actual spot within that area defined by the language).
  - pdimitar 2y ago
    That sort of extreme flexibility simply does not exist. I mean it does but then you are firmly in the dynamic languages territory and you are forgoing any hope for close-to-the-metal performance.
    - flohofwoe 2y ago
      IMHO it does and its not restricted to dynamic languages (like JS or Python), look at this Zig function signature for instance (just an example from my current dabbling): fn setData(comptime pins: anytype, bus: anytype, data: u8) @TypeOf(bus) In practice this looks and feels like dynamic typing, yet when looking at the compiler output it still resolves to optimal code (since it's "compile-time dynamic typing" not "run-time dynamic typing", but the difference in practice is surprisingly small).
      - SpaceNugget 2y ago
        I'm not super familiar with Zig, but that appears to be the same as the rust function signature fn setData<P, B>(pins: P, bus: B, data: u8) -> B; in rust, the P and B are resolved at compile time, not at runtime. If you wanted dynamic dispatch the types would be Box<dyn B>
        flohofwoe 2y ago
        Yes, it's essentially the same, the comptime attribute on the pins arg is quite important though (in the function body that's not shown).
self_awareness 2y ago
Most programmers don't have any opinions, so if they use an unopinionated language, they end up using patterns that opinionated people use. So it's better to have one source of truth for opinions, so that we don't end up using the "wrong" opinions of people who talk more than they think.
- flohofwoe 2y ago
  Compiler/language people are also just "opinionated people" though. Some have good opinions, some have bad opinions. In the worst case you have opinions which are the result of a 'design by committee/community' process.
  - self_awareness 2y ago
    Single source of truth of opinions can be challenged and changed if one's arguments are good enough. The benefit is that it's easier to see the advantages and disadvantages for those opinions, because they're all in the same place. This is in contrast to C++, where one organization creates a set of guidelines, another organization creates another set of guidelines. Valid arguments of critique in one organization are not seen in the other. Single source of truth is also beneficial to compiler authors as well, because they get more feedback how the language is used and why.
pdimitar 2y ago
C/C++ being non-opinionated is the main source of the security vulnerabilities. Let's face it, it felt good to be a lone cowboy carrying a lot of responsibility and knowing what you are doing. I was there myself and I'll admit the ego trip was awesome. These times are long past and naturally, people refuse to adapt. > Unfortunately you can't just have Rust's safety checks, without opting into restrictions that Rust designers force onto You that aren't inherent to safety checks, but more because 'that's a better practice (according to us)'. Show me something that does better and I'll switch tomorrow. But don't tell me C/C++ are better -- they are not. Too much freedom leads to CVEs literally every month somewhere and that's only because we don't have better vetting and checking tools, otherwise I'm sure we'd be getting one every day for a while. > And also, easy and fast iteration just isn't there, both because of borrow checker restrictions and compile times I agree on that, that's why I mentioned Golang. Most of the C/C++ systems I worked on around 15-20 years ago didn't need the close-to-the-metal speed because at least 90% of their time was spent on I/O... frak, even Python would have done well there. And Golang is times faster. It's a very nice compromise if you want to be productive and don't care super much about CPU speed efficiency.
- Xeamek 2y ago
  There are restrictions out on You by the borrow checker to ensure safety, and then there are restrictions put on You by rust design team 'just because'. Again, the former are fine, it's the latter I have a problem with.
  - pdimitar 2y ago
    In order for me to agree on the "just because" part you'll have to give some examples. What made you think they are arbitrary? And how did they prevent you from doing your job?
    - Xeamek 2y ago
      Comment above, mentioned borrowing while structs instead of borrowing memory. I believe this was once discussed under term 'partial borrows', but the "idiomatic" aproach is to 'just split your structs'. Which isn't really a good aproach to structuring codebase, it's just to appeal to borrow checker inflexibility. Lack of global scope. Lack of function overloading.
scotty79 2y ago
Rust is just a different language. It's not C-like or Java-like plus checks or anything like that. It's a value oriented language. Variables mean something completely different than in any other common language. Everything is about the values and where they are kept at the moment.
hdjksndhsi 2y ago
So a few things .. Rust is a very good safe language. It also has an unsafe keyword to make the compiler ignore borrows etc. If you want fast iteration, use python and then hand transpile your code into rust. Not every tool has to be used at once ... but Python for the idea and rust for the implementation can be the best of both worlds ... :)
- Xeamek 2y ago
  Except Rust's unsafe is even worse then any other 'unsafe' languages. And while you can technically prototype in a other language, speed of iteration is always a bottleneck. The only way to escape it is if You are an about master of language, the project you are working on and even the feature you are adding. But that's a verry rare case scenario
  - pdimitar 2y ago
    I don't disagree btw. As a contractor I have found myself very often in a situation where Rust's slower iteration simply didn't work for me so I got back to Elixir and also relearned and started getting proficient in Golang. Rust's slower iteration only disappears when you become a pro as you said and that's my main problem with it. I simply can't invest as much time and effort for free.

yau8edq12i 2y ago

I program MCUs as a hobby. I wish I could use something better than C. Even C++ with RAII would be better. But somehow, even C++ support is spotty, with unsupported features, broken debugging, etc. for seemingly no reason. And all device-specific libraries are written in C, so I'd have to write C++ wrappers for every little thing. Send help...

pdimitar 2y ago
That's why I said "almost anything". I am aware that f.ex. kernel development and embedded work is still firmly in the C domain. I am not evangelizing for Rust, Golang or anything in particular. I am evangelizing for periodically asking yourself "Am I still using the best tool for the job?" which most people never do.
- nottorp 2y ago
  Actually, maybe Rust would get more people interested if it didn't sound like a religion...
  - pdimitar 2y ago
    Maybe it's you and some other curmudgeons projecting -- worth to consider if that's the case. Maybe it's normal for people to praise something that legitimately solved their problems. I know that happened with me.
    - glass-z13 2y ago
      There is a difference between praising and preaching, the latter happens more often with rust
      - pdimitar 2y ago
        If you say so. ¯\_(ツ)_/¯ But even if it was true (I'd contest it's not) can't you ignore it and judge the language on its merits? We are not teenagers for a long, long time now, we should be making up our own mind about things.

jokteur 2y ago

I would love to be able to use Rust in my professional project. Unfortunately, I am doing high performance scientific computing. Rust doesn't even come close to offer any good alternative to cross-plateform, cross-device (CPU/GPU) libraries such as OpenMP Target, Kokkos, SYCL, ... I believe we need Nvidia/AMD to take Rust seriously (I'm not sure it is even possible without unsafe everywhere) to be able to offer good libraries. In my world, using C++ is the modern language, because most project are stuck with Fortran.

pdimitar 2y ago
That's completely valid and that's why I said "almost anything" -- other things include kernel development and embedded. My broader point was that C/C++ are still kings in some areas but people insist on using them where a bunch of languages do better today.
- miki123211 2y ago
  Also cross-platform libraries, if you want to be everywhere, from computers and phones to set top boxes to weird Japanese rtoses you haven't even heard of, Rust just won't cut it.
  - p_l 2y ago
    Fortunately there are other languages that are more available cross-platform than Rust with its tiny Tier 1 list. Unless ofc you're contractually obligated to use vendors half-arsed kludget together patchy version of GCC of unknown provenance that they compiled with barely half C support, let alone other GCC languages.
pjmlp 2y ago
At least C++ provides the tools to avoid this kind of problems, if one choses to do so, instead of insisting into C idioms.
- Shorel 2y ago

jalapenos 2y ago

This is one possibility. Have you considered the other, that you're the old-man-yells-at-cloud variety of narcissist? Hence why you choose to interpret things as everyone (except you) is defective. Everyone (except you) is laughable, completely lacking in self-awareness, refusing to adapt and be and do as they should (according to you of course). Because they're all lesser than you! That's why. You write Rust. So obviously, you're so far above them. Like a God looking down at monkeys. Couldn't be reasons like inertia, or lacking the time, or not having the budget to change, or being too tired to learn, or any other such thing that'd let them be equal to you but just with differing priorities. No, because then you wouldn't get your narcissistic supply, allowing your delusion you're better than others, rather than a man distracting himself from his own failings? Just an alternative theory. What do you think?

pdimitar 2y ago
> Couldn't be reasons like inertia, or lacking the time, or not having the budget to change, or being too tired to learn, or any other such thing that'd let them be equal to you but just with differing priorities. This is already included in the "almost anything" expression and you are the 4th person deliberately (or accidentally?) not noticing it. There are valid cases for C/C++ both on technical merits and business specifics. I have not denied that. --- The rest of your comment is just projection borne out of your faulty assumptions about my comment and it's thus not interesting at all.
- FdbkHb 2y ago
  > This is already included in the "almost anything" expression and you are the 4th person deliberately (or accidentally?) not noticing it. I genuinely think that : 1/ this field is dominated by a disproportionate amount of people with autistic traits 2/ their ability to reason only functions in the narrowest sense and their grasp of language (takes everything in the most literal sense, thinks in extremes, prone to putting things in boxes, have a very, very strong attachment to their routine and are unable to ever leave the comfort zone they constructed) makes any attempt at communication beyond painful. I have come to not even bother replying to people who are unable to understand human words such as when they interpret "most" as meaning "all" or "rarely" as "never" as it's one of the telltale signs that it is going to be extremely unproductive. This phenomenon is the cause of most pains and drama. Once you start to see how this pattern develops you understand the true cause of the endless bikeshedding, of why even the idea of having a code of conduct can raise endless anger and storms and so on. You're touching a comfort zone so the temper tantrums are thrown. The routine has been built and it must continue until the end of times. If there's any field in this world that is in need of more neurotypical, emotionally stable adults, this is it.

deleted 2y ago

[deleted]

anon-3988 2y ago

No, more people should be using memory managed languages like Java and Golang. Then educate and expose people to sum types and pattern matching. It is actually insane how people is still unconvinced about sum types. Imagine how insane it is to program without product types? That's exactly what it felt like.

pdimitar 2y ago
> It is actually insane how people is still unconvinced about sum types. Oh don't even get me started on this but I agree sooooo much. > No, more people should be using memory managed languages like Java and Golang. Well, I use both Golang and Rust depending on the need. We can have both, it's not an either-or.
- amarant 2y ago
  I'm feeling my lack of academic training here, but I needed to make sure. When you say sum types, are you referring to enums, or is it a broader concept than that? The Wikipedia article was quite archaic but seemed to support my initial understanding that you're talking about enums. Are you talking about enums?
  - pdimitar 2y ago
    Yes, I am talking Rust enums and OCaml's enumerated data types.
    - williamcotton 2y ago
      Or what F# calls a Discriminated Union.
  - tialaramex 2y ago
    Rust's enum is a sum type. The enum in C is just integers (again) wearing a hat for some reason. This may not be obvious, but if my enum in C seemingly has three possible values it... doesn't, it actually has at least hundreds of possible values, but only three have names - it's just an integer in a hat. A sum type is an idea from type arithmetic. Suppose we have two types A and B, and we want to produce a new type from those, the most common provision in languages is to let you make a product type, it has all the values of A multiplied by all the values of B, this may be available to you as a named tuple, perhaps named a "struct" or "class" in your preferred language. But what if instead we added these types instead of multiplying them? The new type has the values of A plus the values of B ? That's a sum type. Suppose I have three types which resemble booleans: mood (it's either happy or sad), size (huge or tiny) and activity (either sleeping or eating) A sum type of these three would allow me to make a "brief" of a cat as one of the six values, either as its mood, its size or its activity. The cat brief can be sad, or sleeping, or tiny, but it cannot be sleeping and sad [in this model] any more than a cat's size could be both huge and tiny. There are 2 + 2 + 2 = six values of the brief type. In contrast a product type, maybe lets call that "state" of the cat consists of separate values of each of the three constituents, so the state of a cat might be (sad, tiny, sleeping) or (happy, huge, eating) or any other combination. There are 2 * 2 * 2 = eight values of this state type. Just as an arithmetic is kinda crap if it only has multiply but not add, a type system is kinda crap if it can't make sum types. Where complicated hard-to-get-right hacks are used (e.g. C++ std::variant) these are often unsatisfying both ergonomically and in terms of delivered functionality, so hence the desire to have actual sum types in the language.

GoblinSlayer 2y ago

It's possible to write systematically safe code in C, no need to change language. People really just don't want to do it.

pdimitar 2y ago
Maybe it is but the last several years of periodic (and quite embarrassing) CVEs suggest otherwise.
- GoblinSlayer 2y ago
  What they suggest? What I and the discussed article claim is that safe code isn't written because programmers don't want it. CVEs aren't caused by desires, they are caused by unsafe code.
  - pdimitar 2y ago
    Many people suggest to start gradually migrating to either Rust or start investing much more seriously in formally proving C/C++ code (which is IMO a huge endeavor). As I said in multiple other comments, I know there are valid cases for C/C++ where various factors prevent migration. I am not playing a little rebel revolutionary here, I am addressing the people who can migrate away but refuse to do so based on hand-wavy philosophy clashes (or my favorite petty rebellious take: "people praise Rust, I must resist using it!"). Petty stuff and I am pretty disappointed that people who bill themselves as "engineers" refuse to see objective evidence and hold on to only what they know. Those are the people I address with my comment. Not the people who will be never allowed to migrate away a 2 million lines worth of C codebase. They have my deepest sympathies.
    - GoblinSlayer 2y ago
      I didn't propose to migrate to rust.
      - pdimitar 2y ago