4 ms·

I'm always interested in new languages and loved your write-up & evaluation of V. I really don't get the purpose of someone exaggerating the capabilities of th

by prirun 4y ago

I'm always interested in new languages and loved your write-up & evaluation of V. I really don't get the purpose of someone exaggerating the capabilities of their language, to the point of outright lies.

dkjaudyeqooe 4y ago
I think people think that's "marketing".
rurban 4y ago
Unfortunately that's needed nowadays to succeed. Java, Rust and many other would not be successful without standing on the shoulders of its big lies
- creata 4y ago
  What lies did the Rust developers make? (Also, "nowadays" must stretch out to many decades if you're including Java!)
  - davidkunz 4y ago
    The marketing sentence "A language empowering everyone to build reliable and efficient software." is not true.
    - deleted 4y ago
      [deleted]
  - rurban 4y ago
    The three securities they guarantee and cannot hold. Fearless concurrency. Java also promised memory safety. I still get Null pointer segfaults in Java code.
    - agluszak 4y ago
      > The three securities they guarantee and cannot hold. Could you elaborate? > null pointer segfaults They are not segfaults and are not related to memory safety. Segfault stands for "segmentation fault", not "runtime exception". https://en.m.wikipedia.org/wiki/Segmentation_fault https://en.m.wikipedia.org/wiki/Segmentation_fault
    - thayne 4y ago
      If you know of a case where rust code violates memory safety without the use of an unsafe block, file a bug and it will probably be fixed within a release or two. "Fearless concurrency" is more subjective, but rust code (again with the caveat that there isn't unsafe code, or unsafe cose upholds all unvariants) dows eliminate certain classes of concurrency bugs. Although, dreadlocks are definitely possible, and certain kinds of race conditions could potentially exist. But I don't know of any claims that concurrency bugs are impossible in rust.
      - seebs 4y ago
        Someone pointed out an obvious one: You can open the file "/dev/mem" or equivalent on many Unix systems and break things horribly, and rust can't tell that you're doing it or stop you. Someone used this to write an unsafe-free transmute, which is probably at least two different war crimes. I doubt the rust team will try to "fix" that.
        creata 4y ago
        But you can get away with that in most languages that are generally considered memory safe, so a sane interpretation of the term "memory safety" wouldn't care about that.
        zaarn 4y ago
        How would anyone go about preventing you from doing that? Keep in mind /dev/mem is just a convention, I can just mknod it at any place in the filesystem I want. I can even put a FUSE overlay on it that would turn it into a regular file instead of a device node, so you wouldn't have any possible way of telling what you're about to do. There is no "defense" against /dev/mem, that's just something you don't do as a sane programmer.

by prirun 4y ago

dkjaudyeqooe 4y ago

I think people think that's "marketing".

rurban 4y ago

Unfortunately that's needed nowadays to succeed. Java, Rust and many other would not be successful without standing on the shoulders of its big lies

creata 4y ago
What lies did the Rust developers make? (Also, "nowadays" must stretch out to many decades if you're including Java!)
- davidkunz 4y ago
  The marketing sentence "A language empowering everyone to build reliable and efficient software." is not true.
  - deleted 4y ago
    [deleted]
- rurban 4y ago
  The three securities they guarantee and cannot hold. Fearless concurrency. Java also promised memory safety. I still get Null pointer segfaults in Java code.
  - agluszak 4y ago
    > The three securities they guarantee and cannot hold. Could you elaborate? > null pointer segfaults They are not segfaults and are not related to memory safety. Segfault stands for "segmentation fault", not "runtime exception". https://en.m.wikipedia.org/wiki/Segmentation_fault https://en.m.wikipedia.org/wiki/Segmentation_fault
  - thayne 4y ago
    If you know of a case where rust code violates memory safety without the use of an unsafe block, file a bug and it will probably be fixed within a release or two. "Fearless concurrency" is more subjective, but rust code (again with the caveat that there isn't unsafe code, or unsafe cose upholds all unvariants) dows eliminate certain classes of concurrency bugs. Although, dreadlocks are definitely possible, and certain kinds of race conditions could potentially exist. But I don't know of any claims that concurrency bugs are impossible in rust.
    - seebs 4y ago
      Someone pointed out an obvious one: You can open the file "/dev/mem" or equivalent on many Unix systems and break things horribly, and rust can't tell that you're doing it or stop you. Someone used this to write an unsafe-free transmute, which is probably at least two different war crimes. I doubt the rust team will try to "fix" that.
      - creata 4y ago
        But you can get away with that in most languages that are generally considered memory safe, so a sane interpretation of the term "memory safety" wouldn't care about that.
      - zaarn 4y ago
        How would anyone go about preventing you from doing that? Keep in mind /dev/mem is just a convention, I can just mknod it at any place in the filesystem I want. I can even put a FUSE overlay on it that would turn it into a regular file instead of a device node, so you wouldn't have any possible way of telling what you're about to do. There is no "defense" against /dev/mem, that's just something you don't do as a sane programmer.