Live data from Hacker News

Rust is mostly safety

graydon2.dreamwidth.org

401–410 of 474 posts

Re: Rust is mostly safety

#401
The memory safety of Rust is over consumed.

1. several small languages also introduce the type system to try to solve the memory safety problem. But all of them are less famous. Because there are many reasons that makes a language being accepted massively from other tons.

2. in many cases, it is not hard to do manual memory management. There are many great software done with manual memory management. Although I admit the quest to memory management is always wonderful for system. But go to the follow #3.

3. linear/affine type system[1] is not the panacea. The case of "used exactly once" is just a small case. Forcely to this pattern makes large boilerplates. And constraints and verifications to system can not be done many levels and aspects. Is this truly valuable to add all into type system?

4. memory safety of Rust comes with price, which have added many complexities and language burdens to itself. Who like to read the following function declaration?(just borrowed as example):

fn foo(x: &'a str, y: &'b str) -> &'a str

5. So, finally, the question arises: does the current form of the memory safety of Rust deserve as the hope of next industry language? I'm afraid...

[1] https://en.wikipedia.org/wiki/Substructural_type_system

Re: Rust is mostly safety

#402
post #391
post #359

Earlier quoted context omitted.

I haven't looked at rust, and this sentiment is exactly what has kept me away. I watched perl, java, python, ruby, node and c++ (boost) fall into the trap of "we know better than the end-user/developers/sysadmins/os vendor, so let's reinvent dpkg poorly". Why should cargo be any different? It is solving a problem I don't have (debian, ubuntu, openbsd, and freaking illumnos all have acceptable package management), and…

> talking about rust dll hell No, what that thread is talking about is that somebody wrote a library to exercise unstable features in the nightly branch of the Rust compiler, and that inspired somebody else to write a sky-is-falling blogpost claiming that nightly Rust was out of control and presented a dozen incorrect facts in support of that claim, so now we have to bother refuting the idea that nightly Rust is some…

From the thread, I got the impression that it is not trivial to backport packages from the nightly tree to the stable tree--people are talking about when packages will land in stable, but I'd expect that to all be automated by test infra, and too trivial for developers to work around to warrant a forum thread.

Anyway, it sounds like I stepped on a FUD landmine. Sorry.

It sounds like you work in this space. From my perspective, debian successfully unified the developer and end-user centric package manager in the '90s, and it supports many languages, some of which don't seem to have popular language-specific package managers.

What's missing? Is it just cross-platform support? I can't imagine anything I'd want beyond apt-get build-dep and apt-get source.

Re: Rust is mostly safety

#403

Earlier quoted context omitted.

I wasn't saying you were shilling to dodge competition so much as better performance is in your marketing material like many others. ;) I agree that a lot of the space they should be targeting won't have a humongous difference between a well-tuned GC and a typical, native implementation. You're right on that. "Companies that sell ultra-low latency GCs for a fraction of the cost it would take for enterprise shops to a…

With rust you don't need to rewrite though. Just integrate it a little at a time.

Hopefully. With the legacy codebases or preferences, that means hiring people that really know C or C++, training them for Rust, and maintaining two codebases in one. It becomes trickier. Hopefully the incremental option works well for Rust but it didn't with most languages & platforms.

Re: Rust is mostly safety

#404
post #35

Earlier quoted context omitted.

When have they broken stuff post 1.0?

Since the parent is content to just argue, in the interest of transparency, we have made one or two small fixes so far. Specifically, I'm thinking of https://github.com/rust-lang/rfcs/pull/1214 , which was a soundness fix that went through warnings in 1.4 and became an error in 1.7. Code like this: struct Foo { f: fn(&'a X) } Would compile on 1.4, but not 1.7. The fix is: struct Foo { The compiler would tell you exac…

  struct Foo {
take a look at tha example. Just look at it! Are you redirecting from stdin and then redirecting to stdout? Or is this supposed to be C++ templates? 'a, X: a' is shell escaping, or what? The syntax is insane, and even if Rust lived up to all of your (plural) claims, how could I ever bring myself to program in something as hideous as that?

Some more syntax insanity which is Rust:

  let path = Path::new("../word.lst");
let's map this to your target demographic again (me):

I first learned of "let" in BASIC. Path::new - so we're doing C++ now? C++ BASIC. And then there's "new", which means I'm instantiating an object. Do you seriously expect system programmers to start programming in an object oriented language, when it's clear to us that it's a horrible way to reason about data? (Hint: go back to the '50's and '60's, you'll find this wonderful paradigm called functional programming, which has a lovely sideeffect of being both stateless and reentrant. And then you'll discover this wonderful language called LISP.)

  Err(why) => panic!("failed to open {}: {}", path.display(),
So what is this now, =>, SmallTalk? And exception handling! I. HATE. EXCEPTION. HANDLING. Why? Because if I'm using exception handling, it means that I was too lazy to do proper error checking and correction in the algorithm of my program! That is unacceptable for system programs, and frankly, for any type of a program.

  Error::description(&why)),
Then all of a sudden, we're back to C++. C++ is an epic, colossal failure, precisely because of its complexity: it introduced more problems than it solved.

So Rust is a mish-mash of all these different syntaxes, and maps to zero in the C programmer's model and domain. When you (plural) embarked upon this project, didn't you know that if you want to replace something with something else, you have to map to your target audience's prior experience and knowledge?

And I still haven't addressed your claim (which you (plural) completely ignored too), that your language and the compiler, and the algorithms for memory management and safety have no flaws. That's the implication of a safe language, that the programmer's implementation of memory management is flawless! Where does Rust come from? Ah yes, from the Mozilla Firefox team. And do you know how badly Firefox runs on my Solaris 10 system? It crashes all the time, it's slow, and the latest version I have (45.5.1 ESR), the audio started cracking and popping. There is no way I'm going to trust the caliber of programmers who don't care about my platform and about code quality so as to release something like that (and that's not the first time).

We are not friends right now: your product is bad, and I don't trust you. And you (plural) are very aggressively pushing for replacing something simple which works (C) with your insane programming language. Between Rust and ANSI Common LISP, the choice is clear for me: anything that I can't implement in C, shell, or AWK, LISP is going to be my destination. Functional programming. Machine code when I'm done in the REPL. Metaprogramming. Stateless. Perfect. I'd just as soon program in Ada again, rather than Rust.

By the way, I watched your talk on Ruby and Rust[1]. After watching the amount of insanity you had to go through to print one line on stdout, I wanted to cut my veins and throw myself out of the window: I could have printed half of encyclopaedia Britannica in shell or AWK by that time. But that wasn't the worst part. The worst part was that you saw absolutely nothing wrong with all of that insanity, in fact you found it "cool".

[1] https://www.youtube.com/watch?v=Ms3EifxZopg

Re: Rust is mostly safety

#405
Who are you fooling? I'm well aware of the author's history with Rust. Sorry if I confused you. Do you support his "experienced" view that all of the C or C++ programmers who don't put a particularly high value on safety are either ignorant or negligent? Now's your chance - take a stand and support your team mate!

> Can you give me an example of a comment in this thread that you find to be from a pretentious beginner?

No great examples in this thread. Does that mean I'm wrong?

Re: Rust is mostly safety

#406

Earlier quoted context omitted.

They do expand to code. They shouldn't mess up debugging or confuse tooling. They're much more similar to Lisp-style macros than the C preprocessor.

Oh, ok, the word macro is heavily overloaded and it seems I misinterpreted the Rust use of macros. But oh boy it costs lots of rep to ask a question.

Trust me, every C and Lisp programmer in the world is upset that both languages use "macro" to mean such wildly different things. :)

Re: Rust is mostly safety

#407
post #373

Earlier quoted context omitted.

> Memory safety is important for everything because it is a prerequisite for any other form of correctness. That's obviously true, but not what I (or the OP) was talking about. My point was that in many applications memory safety doesn't rank highly as a separate concern, in addition to computing correct output from expected input. Because of this, describing Rust as a language that solely focuses on memory safety is…

> My point was that in many applications memory safety doesn't rank highly as a separate concern, in addition to computing correct output from expected input Indeed, I was trying to cover that in my comment. I agree that it isn't an explicit selling point to such people, but I think that it should be: - numerics/scientific computing/machine learning are slowly taking over the world. It is bad to have random/occasiona…

Thanks for this great comment thread, Huon. :) I didn't know we had fastmath stuff now!

Re: Rust is mostly safety

#408
post #130

The daily post about Rust and Go is getting tiresome... every single day we've got one.

Yep, it's getting reeeaaalllyyy tiresome, and if people actually start programming en masse in Rust, you might soon end up having to maintain and debug programs written in that insane language. And you might even get to be really good at it. No sooner than you master it, someone else is going to come up with something new and shiny, and everybody will just move on to that, leaving you with holding the bag. But of course, that never happens in the computer industry. People never go for new and shiny. That's just... hypothetical.

Re: Rust is mostly safety

#409

Earlier quoted context omitted.

Since the parent is content to just argue, in the interest of transparency, we have made one or two small fixes so far. Specifically, I'm thinking of https://github.com/rust-lang/rfcs/pull/1214 , which was a soundness fix that went through warnings in 1.4 and became an error in 1.7. Code like this: struct Foo { f: fn(&'a X) } Would compile on 1.4, but not 1.7. The fix is: struct Foo { The compiler would tell you exac…

struct Foo { take a look at tha example. Just look at it! Are you redirecting from stdin and then redirecting to stdout? Or is this supposed to be C++ templates? 'a, X: a' is shell escaping, or what? The syntax is insane , and even if Rust lived up to all of your (plural) claims, how could I ever bring myself to program in something as hideous as that ? Some more syntax insanity which is Rust: let path = Path::new(".…

Quite a few comments you've posted recently have crossed into incivility. You can't do this on HN. If you keep doing it, we will ban your account.

Please take extra care to be civil when disagreeing on HN. Snark, acerbic overstatement, and personal rudeness are all unwelcome here.

We've had to warn you about this more than once before. You've also posted some good comments, so I'm inclined to give you another chance, but if you want to keep posting here, please fix this and make sure it stays fixed.

Re: Rust is mostly safety

#410

Earlier quoted context omitted.

>But Rust can compete on so many more levels How ? There are languages with more expressive type systems high level type systems (Haskel/OCaml presumably). There are languages with much more mature libraries, ecosystems and tooling (C#/Java). There are languages with both (F#/Scala). What is it that makes Rust a good applications programming language ? You said it your self GC doesn't really matter that much in this…

When I write in Rust, I have feeling "that's how programming should work". I don't know how to express it in more scientific way. Errors handling, pattern matching, Result type - it's all how it should work. I know, some other languages have similar features, but Rust also has race-conditions protection (very important thing), good package manager out of the box, testing tool (cargo test), very smart compiler and gre…

[deleted]
Post reply on HN