Live data from Hacker News

Rust can be difficult to learn and frustrating, but it's also very exciting

influxdata.com

251–260 of 282 posts

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#251
post #120

Earlier quoted context omitted.

Writing certain data structures in safe Rust can be hard, but not impossible. I’m not aware of any data structures that simply cannot be written in Rust.

Of course, since anything that can be written in C can be written in unsafe Rust. Though, reading the post above yours, I was thinking more about the use of data structures than the implementation of them. In C++, when faced by the need to efficiently iterate through a data structure in different, incompatible orders, the tool of choice is often just to make intrusive linked lists with multiple next pointers per elem…

Thanks for the thoughtful post. I do have a question, that maybe you can answer?

> The languages are all turing-compatible anyway, so it's not about what can be done, it's about what approaches does the language make easy and promote.

Turing completeness is kinda besides the point. We probably wouldn't be talking about it on HN if it wasn't. :)

I guess what I'm wondering is does Rust encourage simpler but possibly slower data structures, or are there some complex data structures which are simpler to ensure safety than other simpler ones?

In other words, does Rust encourage simplicity at the cost of speed?

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#252
post #194
post #179

Earlier quoted context omitted.

But the tooling for editing the code has no support for indenting blocks as trivially as adding braces. Sure, you just run clang-format or such on the block/file, and get all the visual stuff sorted out.

What editor does not support indenting a block? In most editors I know you select the block and hit tab, or shift-tab to outdent.

The difference is that I can add braces in the middle of multiple lines, just need to get my changes to match up, and then I can tell it to reformat the changed section/the whole file. For block indenting, I have to select each block I want to operate on before issuing the block indent command. Braces let me skip the selecting, requiring the same cursor movement but allowing batch insertion of selection begin/end markers, in a sense.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#253
post #244

Earlier quoted context omitted.

> but it's performance is closer to Java, which is a few orders of magnitude slower than C++ A few order of magnitude is an exaggeration. A more reasonable expectation is a 5x slowdown [1]. Depending on your task, a few orders of magnitude can be correct for JVM based languages; they can have very poor startup times (compared to c++) [2]. However, in startup time, go is not similar to Java. [1]: https://benchmarksgam…

> JVM based languages; they can have very poor startup times (compared to c++) [2] Hello world :-) And is 54.55 ms perceptable? (310.81 ms should be).

> And is 54.55 ms perceptable?

Its probably noticeable compared to instantaneously in terms of "feeling" different due to lag. However, it is definitely perceptible in the terminal based on my testing using `sleep`. For me (on my computer + monitor) down to 25ms is noticeable.

Also importantly, the hello world test shows 2 orders of magnitude simply, but the problem for JVM based languages gets worse for large projects (though not proportionally worse). Real java projects can take a second to launch whereas I haven't worked on a project large enough for that to be true in C++, Go or Rust.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#254
post #236

Earlier quoted context omitted.

Could you elaborate a bit on the obvious weaknesses in Go?

Arbitrary examples off the top of my head: lack of references, no generics, verbose error handling, a few quirks (e.g. need to write (*slice)[i]), inconsistencies like new vs. make, interface{} hacks where there could be a zero-cost abstraction, oddities with untyped literals, no way to declare "not null" pointers and the Million Dollar Mistake, built-in functions for built-in primitives (i.e., append(slice, datum) i…

Thank you!

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#255
post #242

Earlier quoted context omitted.

State of the art is pthreads and mutexes. The C++ and Rust wrappers for them are roughly equivalent. Rust has some nice features for handling ownership semantics, but they are not significantly better than those in C++. Meanwhile, Rust still lacks a normal exception handling story. Exception handling is absolutely necessary in 2018 for building real software systems. (And even though Rust claims that errors are nicel…

Haven't spent that much time with rust, but so far Result has sufficed for all my exception-needs; it's not clear to me what the practical difference is between exceptions and result , that would be relevant to implementing real software systems? As I understand it, the primary usage of both is to report, and handle, errors. Rust splits it as panic! and Result , where panic! is naturally left for logic errors (ie sta…

> I'm not sure how often you want to recover from such a state though.

Pretty much always in real systems software.

Imagine a multithreaded server that handles HTTP requests. A catastrophic invariant failure when handling one requests shouldn't bring down the whole server.

Or imagine an application that calls into a money transaction routine. (This routine can itself call other routines, and so on for 12 stack frames deep.) A catastrophic failure in sending money shouldn't bring down the whole app, it should show a clean "money transfer failed, please try again" message.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#256
post #223
post #199

Earlier quoted context omitted.

It is somewhat unfair to compare this to Python, since a lot of the simplicity in Python comes from the semantics (dynamically typed, garbage collected and so on). Rust need to express all this information (types, lifetimes etc.), so it will necessarily be more dense. The question is if this information could be expressed in a more readable syntax. This might be possible, but I would like to see a suggestion of how.…

Here is a simpler syntax: fn accumulate tuples: &[(&'a Str, &Fn(i32) -> Bool)], i: i32 -> t where t: Monoid + From &'a Str + From String, this is how Haskell with lifetimes and borrowing would look like (if arguments were not curried)

I like removing superfluous punctuation, but if parentheses are removed from method signatures than they should also be removed from invocations, which in turn comes with its own set of readability issues. I'm not a fan of the $ operator in Haskell, for example.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#257
post #242

Earlier quoted context omitted.

Haven't spent that much time with rust, but so far Result has sufficed for all my exception-needs; it's not clear to me what the practical difference is between exceptions and result , that would be relevant to implementing real software systems? As I understand it, the primary usage of both is to report, and handle, errors. Rust splits it as panic! and Result , where panic! is naturally left for logic errors (ie sta…

> I'm not sure how often you want to recover from such a state though. Pretty much always in real systems software. Imagine a multithreaded server that handles HTTP requests. A catastrophic invariant failure when handling one requests shouldn't bring down the whole server. Or imagine an application that calls into a money transaction routine. (This routine can itself call other routines, and so on for 12 stack frames…

That's why you would return a Result from all those and handle any failures that way. The Result type is meant to be used any time an operation could fail.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#258
post #251

Earlier quoted context omitted.

Of course, since anything that can be written in C can be written in unsafe Rust. Though, reading the post above yours, I was thinking more about the use of data structures than the implementation of them. In C++, when faced by the need to efficiently iterate through a data structure in different, incompatible orders, the tool of choice is often just to make intrusive linked lists with multiple next pointers per elem…

Thanks for the thoughtful post. I do have a question, that maybe you can answer? > The languages are all turing-compatible anyway, so it's not about what can be done, it's about what approaches does the language make easy and promote. Turing completeness is kinda besides the point. We probably wouldn't be talking about it on HN if it wasn't. :) I guess what I'm wondering is does Rust encourage simpler but possibly sl…

As with all performance questions, the answer is “it depends.” For a look into this question, see http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa...

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#259
post #147

Earlier quoted context omitted.

Actual problems like: - sending dangling references to thread functions. Lambdas with automatic reference capture creating threads from inside functions that exit are terrible here. - returning a pointer or reference to an invalidated iterator - returning a pointer or reference to the contents of a temporary Yes indeed, C++ programmers never actually have these problems, they are purely imaginary. /sarc

Yeah, I don't think there is a professional C++ developer who has any of these problems. It's called static analysis... welcome to a decade ago. Why on earth would an organisation move their codebase to Rust when they can just run Clang? Which they should be doing anyway.....

In my experience, even modern C++ code and cutting-edge static analyzers still have a lot more holes than Rust when it comes to borrowing and lifetimes. Unsound code like this (which in Rust is the most basic form of lifetime error) still manages to slip past the CppCoreGuidelines static analyzer that Microsoft has been developing for years, which includes "lifetime checking":

    #include 
    #include 
    #include 

    int main() {
      std::string s = "Hellooooooooooooooo ";
      std::string_view sv = s + "World\n";
      std::cout 
C++ types simply don't contain the information needed to do Rust-style lifetime analysis. C++ static analyzers have to hard-code this knowledge themselves about every library type (will never be complete for every library in existence), use heuristics (will always have some false positives and false negatives), or rely on whole-program analysis of function bodies rather than signatures/types (runs into incomputability problems, and validity ends up depending on things the analyzer can't know, like which version of a dynamic librariy ends up linked at run time).

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#260
post #244

Earlier quoted context omitted.

> JVM based languages; they can have very poor startup times (compared to c++) [2] Hello world :-) And is 54.55 ms perceptable? (310.81 ms should be).

> And is 54.55 ms perceptable? Its probably noticeable compared to instantaneously in terms of "feeling" different due to lag. However, it is definitely perceptible in the terminal based on my testing using `sleep`. For me (on my computer + monitor) down to 25ms is noticeable. Also importantly, the hello world test shows 2 orders of magnitude simply, but the problem for JVM based languages gets worse for large projec…

"The basic advice regarding response times has been about the same for thirty years :

0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result."

https://www.nngroup.com/articles/response-times-3-important-...

Post reply on HN