Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

2016 Rust Commercial User Survey Results

internals.rust-lang.org

Post reply on HN
Print view View original

91–100 of 131 posts

Re: 2016 Rust Commercial User Survey Results

#91

Post by cm3 »

Manishearth wrote: post #90
cm3 wrote: post #85

Earlier quoted context omitted.

> It's actually more of a sibling in the family who ran away from home at the age of 6 and fell in with the crowd on the wrong side of the tracks. > Initially Rust was very much like ocaml. It isn't anymore :) Many of the normally-in-functional-languages features in Rust come from these days. Others were lost and re-added later. It's a very complex history. Yeah, having tried Rust in those days, I kinda stopped when…

Oh, yeah, I see what you mean by function head patterns. I'm aware of the coding pattern from Haskell, just didn't know the name :) I don't think Rust will get support for that. You can simulate it with macros (and, later, syntax extensions). Of course, that isn't as clean as pure language support. I know why it makes recursion (esp tail recursion) easier to use though. You could always bring it up on the forums and…

1 and 2 go hand in hand in recursive functions, but 1 is useful without.

Say you have a function that should will tell you a file extension is likely to be that of a text file:

  isTxt("txt") -> true;
  isTxt("org") -> true;
  isTxt(_)     -> false.
With a more comfortable syntax, this can be expressed more concisely, but I just wanted to show that this isn't only useful for recursive functions.

If Rust is planned to get HKT, then I don't see why I cannot get pattern matching in function heads when there's also guards as found in ML languages.

Re: 2016 Rust Commercial User Survey Results

#92

Post by pcwalton »

oconnor663 wrote: post #86
pcwalton wrote: post #19

Earlier quoted context omitted.

> - The type system is unusual, and complex. It's hard to do anything without templates. You need generics to have the borrow checker that you praise above. Otherwise references would be basically crippled. > The template libraries are heavily biased towards closure-oriented functional programming. No, they aren't. I use for loops all the time in Rust, and it's totally natural to do so. My general guideline in my own…

>> The template libraries are heavily biased towards closure-oriented functional programming. > No, they aren't. I think that came off more combative than you meant it to :) >> Parts of expressions are nameless and have no visible type. >Are you thinking of unboxed closures here? I think Animats is complaining about the functional style in general, which is at least more common in Rust than in C++ or Python. And if t…

> a lot of the savings comes from omitting the variable names that are usually there in imperative code, and some clarity gets lost when you don't name things.

Are you talking about point-free style? Point-free style is rare in Rust, partially by convention, partially due to the fact that references and values are different and often you need to wrap in a closure to convert one to the other.

Re: 2016 Rust Commercial User Survey Results

#93

Post by pcwalton »

throwmeaway11 wrote: post #88
Animats wrote: post #13

From the article: "...fourteen companies responded to our outreach" That's not a survey, that's a focus group. I'm impressed with Rust. The borrow checker is the biggest advance in memory safety since garbage collection. But there's a lot about Rust that's unnecessarily weird. - The type system is unusual, and complex. It's hard to do anything without templates. - The template libraries are heavily biased towards clo…

You speak as if you're so sure of yourself. Not with opinions but apparently presenting facts. Problem is most of your "facts" are wrong. Thankfully the actual experts are patient enough to explain this. But not a single "Oh, sorry, I was wrong about that." Just silence on the things you were called out on, as if you weren't just called out on them. This is the worst side of this place.

I don't mind criticism of Rust. In fact I often upvote it when I see legitimate criticism turn gray.

Re: 2016 Rust Commercial User Survey Results

#94

Post by Manishearth »

cm3 wrote: post #91
Manishearth wrote: post #90

Earlier quoted context omitted.

Oh, yeah, I see what you mean by function head patterns. I'm aware of the coding pattern from Haskell, just didn't know the name :) I don't think Rust will get support for that. You can simulate it with macros (and, later, syntax extensions). Of course, that isn't as clean as pure language support. I know why it makes recursion (esp tail recursion) easier to use though. You could always bring it up on the forums and…

1 and 2 go hand in hand in recursive functions, but 1 is useful without. Say you have a function that should will tell you a file extension is likely to be that of a text file: isTxt("txt") -> true; isTxt("org") -> true; isTxt(_) -> false. With a more comfortable syntax, this can be expressed more concisely, but I just wanted to show that this isn't only useful for recursive functions. If Rust is planned to get HKT,…

> I just wanted to show that this isn't only useful for recursive functions.

Oh, I know that it's useful; I've used it in Haskell often. And the `fn foo (x) { match x {}}` pattern isn't uncommon in Rust.

> If Rust is planned to get HKT then I don't see why I cannot get pattern matching in function heads when there's also guards as found in ML languages.

The HKT proposal logically extends existing associated types syntax so that you effectively have HKT. It's particularly elegant in that it's something folks (who are unaware of what HKT is) on learning about associated types expect associated types to support. I've had folks ask countless times as to why you can't `type Foo` in an associated type.

It also opens up access to patterns that weren't possible in the past.

OTOH function heads would just be sugar for fn + match. It doesn't open up new possibilities, it just makes some patterns easier to type. And frankly, with blocks being expressions, it's not much easier to type. You have to provide the function signature somehow, and it's there. The match arms are also there in both the Rust and haskell versions. The only thing exclusive to the Rust version is that you need to explicitly say `match`. Meh.

Languages have a "complexity budget" -- spend too much of it and folks won't learn your language because it's too complex. Rust has spent a lot of it on the borrow checker. Adding random bits of syntax spends this budget, and you need a compelling reason to do so. This is why I'm quite fond of the current HKT proposal -- I'd always thought HKT in Rust was pie-in-the-sky, but the current proposal ends up with a very unsurprising and natural-looking syntax (and doesn't feel "new"), which makes me think that it has a good chance of succeeding.

If you can come up with a good proposal for function heads, who knows, it might happen! But it will have to be good; I don't think just proposing function heads without tons of justification and/or a syntax that fits in naturally will work.

Re: 2016 Rust Commercial User Survey Results

#95

Post by duneroadrunner »

quantumhobbit wrote: post #18
sdegutis wrote: post #3

Earlier quoted context omitted.

Why do you specifically enjoy it more than C++? As far as I know, the main goal of Rust is to be safer than C++, not more enjoyable to write.

Merely being safer than c++ is enjoyable because I don't have to be quite so paranoid about introducing bugs. Also rust has some more modern functionalish constructs like lambadas and pattern matching.

> Merely being safer than c++ is enjoyable because I don't have to be quite so paranoid about introducing bugs.

For those times when you have to use C++, SaferCPlusPlus[1] should help.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

Re: 2016 Rust Commercial User Survey Results

#96

Post by throwmeaway11 »

pcwalton wrote: post #93
throwmeaway11 wrote: post #88

Earlier quoted context omitted.

You speak as if you're so sure of yourself. Not with opinions but apparently presenting facts. Problem is most of your "facts" are wrong. Thankfully the actual experts are patient enough to explain this. But not a single "Oh, sorry, I was wrong about that." Just silence on the things you were called out on, as if you weren't just called out on them. This is the worst side of this place.

I don't mind criticism of Rust. In fact I often upvote it when I see legitimate criticism turn gray.

Legitimate being the key word.

Re: 2016 Rust Commercial User Survey Results

#97

Post by Animats »

papaf wrote: post #36
Animats wrote: post #13

From the article: "...fourteen companies responded to our outreach" That's not a survey, that's a focus group. I'm impressed with Rust. The borrow checker is the biggest advance in memory safety since garbage collection. But there's a lot about Rust that's unnecessarily weird. - The type system is unusual, and complex. It's hard to do anything without templates. - The template libraries are heavily biased towards clo…

The hacks needed to avoid the need for exceptions are uglier than exceptions. I felt like this when I read the scary documentation: https://doc.rust-lang.org/book/error-handling.html However, in the total 4 hours or so that I have been programming in rust the way of handling errors seems very sensible. - Match expressions instead of "if (error) dosomething()" - Match expressions with destructuring gives the error mes…

Rust now has not just "panic", but "panic::recover", with unwinding. That's an exception system. It's just one with weak syntax and semantics. Go went down this route, too. In the beginning, Go errors were fatal. Then the Go crowd added "recover". With unwinding. Both languages now have the heavy machinery for exceptions without full language support for them. The discussions of this on Rust mailing lists show much unhappiness with the situation.

If you don't put in exceptions, you seem to end up re-inventing "longjmp".

Re: 2016 Rust Commercial User Survey Results

#98

Post by Animats »

Retra wrote: post #47
sidlls wrote: post #17

Earlier quoted context omitted.

Rust's generics have significant limitations, especially when mixing types, and are cumbersome to use. For example try writing even a basic function accepting two scalars of type T and U and performing arithmetic on them. The way the Rust compiler works it isn't possible without specifying various bounds on the traits (which I appreciate, actually, for explicitness). And even then there are limitations around casting…

The num crate is an open problem. There's a lot of contention around what it is supposed to support. Mathematicians, scientists, HPC programmers, prototyping programmers, embedded system programmers, pointer-arithmetic-doing programmers... they all want something different from a number crate. That's why it is not in the std library: there's no agreement on what it should do, and iterating toward perfection in the st…

That's always hard. I was involved in the arguments over this for Go. Most languages today have multidimensional array support inferior to FORTRAN. This is not only embarrassing, it's why some heavy number-crunching is still done in FORTRAN.

Some people want nice, simple, dense multidimensional arrays. Some want the ability to extract a square section from an array as a subarray. Some want that for N dimensions. Some don't want the overhead for that generality slowing down their matrix multiply. Some are content with arrays of arrays. Some want ragged arrays (rows not the same length). Some want arrays in a format a GPU can use.

Passing the buck to each package, though, results in recopying arrays as matrices move from a function in one package to a function in another. One reason people use MATLAB, FORTRAN, and Python's NumPy is that they at least have a standard representation and matrix functions interoperate. I'd argue for supporting dense arrays in the language (and the optimizer) and doing the fancy stuff in packages.

Re: 2016 Rust Commercial User Survey Results

#99

Post by papaf »

burntsushi wrote: post #73
papaf wrote: post #36

Earlier quoted context omitted.

The hacks needed to avoid the need for exceptions are uglier than exceptions. I felt like this when I read the scary documentation: https://doc.rust-lang.org/book/error-handling.html However, in the total 4 hours or so that I have been programming in rust the way of handling errors seems very sensible. - Match expressions instead of "if (error) dosomething()" - Match expressions with destructuring gives the error mes…

> introduces non-essential craziness without warning. Like what? (Disclaimer: I originally wrote that chapter as a blog post[1], so I'm curious to hear what I could have cut out. I tried to find things to cut, but given my target audience, I couldn't find anything substantial.) [1] - http://blog.burntsushi.net/rust-error-handling/

First, thanks for taking time to write essential blog posts/documentation.

Here would be my suggestions, I hope they are useful:

1. Its about error handling. Options are conceptually similar but they're not error handling. Options can go somewhere else, maybe a previous chapter.

2. From what I understand from my almost zero experience of rust, the match/deconstruct with a Result type will do 99% of error handling -- even though it might be verbose or ugly to some. Its also the basis for the combinators. This can be the short and simple error handling chapter.

3. The combinators are nice constructs to make code more linear looking and are convenient when working with the std library. If they are stated as an optional convenience then they become less scary. Error handling is so fundamental that I should not have to learn about combinators to do it.

What I suggest is a rearrangement of the material. The documentation itself is clear -- its just too much.

Re: 2016 Rust Commercial User Survey Results

#100

Post by burntsushi »

papaf wrote: post #99
burntsushi wrote: post #73

Earlier quoted context omitted.

> introduces non-essential craziness without warning. Like what? (Disclaimer: I originally wrote that chapter as a blog post[1], so I'm curious to hear what I could have cut out. I tried to find things to cut, but given my target audience, I couldn't find anything substantial.) [1] - http://blog.burntsushi.net/rust-error-handling/

First, thanks for taking time to write essential blog posts/documentation. Here would be my suggestions, I hope they are useful: 1. Its about error handling. Options are conceptually similar but they're not error handling. Options can go somewhere else, maybe a previous chapter. 2. From what I understand from my almost zero experience of rust, the match/deconstruct with a Result type will do 99% of error handling --…

Interesting. I couldn't disagree more! Combinators are very handy for error handling in Rust. More than that, combinators (and their limits) are essential to understand in order to motivate `try!`. Indeed, in Rust, matching against a Result type explicitly isn't especially common. Instead, one uses `try!`. `try!` abstracts three things at once: case analysis, error conversion and control flow. The chapter actually goes into detail and demonstrates why combinators and match expressions are insufficient for ergonomic error handling. IMO, this approach leads to the greatest understanding, because everything is laid bare and follows a nice progression from first principles.

With that said, in a book, I totally agree that the chapter could be broken up into more manageable pieces. But I do think all of the content there is essential for understanding how to do error handling in Rust. I feel pretty safe in saying that I use all of those concepts in most crates I've published.

Thank you for replying by the way. I'll continue to noodle on your thoughts and see if there's a happy place between us. (I kind of suspect that happy place is the new book, with content delivered in more manageable chunks. Alas, my blog is not book. :P)

Post reply on HN