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

31–40 of 131 posts

Re: 2016 Rust Commercial User Survey Results

#31

Post by Animats »

pcwalton wrote: post #19
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 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…

You want to force an extra layer of indentation for every Box or Vec you create, and leak memory if you forget to write "with"? No thank you!

No, no, Python like with clauses, for opening files and such.

Re: 2016 Rust Commercial User Survey Results

#32

Post by dbaupp »

dreta wrote: post #29
vvanders wrote: post #25

Earlier quoted context omitted.

You've never hit a NPE or null pointer? Data races or use after free? Const is nothing like references, not even close. I would suggest you spend a bit more time with the language to better understand exactly what Rust brings to the table.

The number of cases where i have to use a generic memory allocator like malloc in a typical project are extremely rare, so no. I never said that const is like anything, i just used it as an example.

One can get all of the problems mentioned with allocators other than malloc, up to and including using only the stack.

Also, sure the implementation of another allocator might use a smattering of `unsafe`, but I'm guess that it will be less than you probably expect: one of Rust's biggest is strengths is the ability to build safe interfaces for things without performance cost. One can see an example for this in http://os.phil-opp.com/ where the author is slowly describing creating an operating system, all while concentrating on how to exploit Rust features to let the compiler help the programmer, such as http://os.phil-opp.com/modifying-page-tables.html .

Re: 2016 Rust Commercial User Survey Results

#33

Post by sidlls »

dreta wrote: post #20

I’d love to see a survey talking about what bugs get actually solved by using one of these modern languages like Rust or Swift, since i personally never once in my career had a bug that wouldn’t have happened if i used const, let alone any of the many other annoying Rust features. For a “systems programming language”, Rust doesn’t let you do anything i’d expect, like let you specify whether a signed integer is 2s com…

I'm sorry, I have plenty of gripes about the Rust team touting safety as much as they do but your comment just misses the mark, in my opinion.

To begin with, "safety" isn't solved by just using const. It simply isn't feasible to write safe code in C without restricted feature usage to the point of being crippled. It's much easier in C++, but requires an incredible level of focus and "cruft constructs" like ' 'const &' and such. Arguably until move semantics were standardized with C++11 it was a challenge to write safe code.

I will agree that Rust's developers have perhaps come down too far on the side of "YOU ARE DOING SOMETHING DANGEROUS BY USING A POINTER." But I think you're exaggerating a bit about how hard it is.

Re: 2016 Rust Commercial User Survey Results

#34

Post by dreta »

pcwalton wrote: post #28
dreta wrote: post #27

Earlier quoted context omitted.

Alright, thanks for clearing that up. I missed those in the documentation, since it doesn’t specify any of this directly. Though, still wide registers aren’t a language feature. I don’t care, nor do i think any other seasoned programmer does, about the language “freeing me from the need to deal with raw memory”. It doesn’t. The types of problems you solve by introducing built-in string types and vectors aren’t proble…

> I don’t care, nor do i think any other seasoned programmer does, about the language “freeing me from the need to deal with raw memory”. I do. Am I a bad programmer? > The types of problems you solve by introducing built-in string types and vectors aren’t problems in the first place. Buffer overflows aren't problems?

I’m not saying you’re bad. I’m saying there’s always a point where you want to go down to managing your own memory when performance is an issue, and no amount of language features is going to change that.

What i’d want is a generic support for preventing buffer overflows, or bad memory access where i need it. Writing my own growable data type using malloc and free is something i can do once, and i just have it, it’s not something that i have to worry about for more than 5 minutes at the beginning of a project.

Re: 2016 Rust Commercial User Survey Results

#35

Post by bfrog »

I'm using it commercially, though wasn't asked in the survey. I've had zero crash causing failures in production with a web interfaced analytics pipeline service I wrote. It just sits there, with its 10's of gigabytes of data running day in day out... handling millions of events every day, crunching business vital numbers. Best thing ever.

Re: 2016 Rust Commercial User Survey Results

#36

Post by papaf »

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 message.

- Match expressions are exhaustive which forces errors to be checked.

Its simple and elegant. I think the documentation is a little overwhelming when it comes to error checking and introduces non-essential craziness without warning.

Re: 2016 Rust Commercial User Survey Results

#37

Post by dreta »

sidlls wrote: post #33
dreta wrote: post #20

I’d love to see a survey talking about what bugs get actually solved by using one of these modern languages like Rust or Swift, since i personally never once in my career had a bug that wouldn’t have happened if i used const, let alone any of the many other annoying Rust features. For a “systems programming language”, Rust doesn’t let you do anything i’d expect, like let you specify whether a signed integer is 2s com…

I'm sorry, I have plenty of gripes about the Rust team touting safety as much as they do but your comment just misses the mark, in my opinion. To begin with, "safety" isn't solved by just using const. It simply isn't feasible to write safe code in C without restricted feature usage to the point of being crippled. It's much easier in C++, but requires an incredible level of focus and "cruft constructs" like ' 'const &…

My point was that i haven’t come across a Rust feature i felt would save me from creating a bug.

Re: 2016 Rust Commercial User Survey Results

#38

Post by dbaupp »

Animats wrote: post #31
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…

You want to force an extra layer of indentation for every Box or Vec you create, and leak memory if you forget to write "with"? No thank you! No, no, Python like with clauses, for opening files and such.

RAII (i.e. destructors that automatically run on values when leaving a scope) is what lets one avoid manually freeing Box and Vec, so you want to split the world into "destructor resources" (RAII) and "with resources", maybe with some guidelines for when to choose which.

Presumably a data type that contains a "with resource" would itself have to be a "with resource" (or else why bother?). This makes "with"-ness abstraction-piercing and infectious, so, for backwards-compatibility, if there was any chance of a type eventually containing a "with resource", the programmer would have to mark the type as such a resource preemptively, or else be forced to make a breaking change to their library. All for a minor syntactic difference in how one constructs values.

Also, how does one return values from `with` clauses? It's useful to be able to write a function that returns a file, so one would need yet more machinery, just to be able to cancel the normal with-cleanup. Again, all for a relatively minor syntactic distinction.

Re: 2016 Rust Commercial User Survey Results

#39

Post by Manishearth »

Animats wrote: post #31
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…

You want to force an extra layer of indentation for every Box or Vec you create, and leak memory if you forget to write "with"? No thank you! No, no, Python like with clauses, for opening files and such.

His comment still stands. RAII is used in Rust for a lot of things, the least of which being managing files. RAII works as an interpoerable, implicit solution for both (unlike Python, where a lot of the use cases get magicked by the GC). with needs to be explicit (or else you leak), and is just more cumbersome to use, given how many things depend on it in Rust. In python you only use with for a few types, so the verbosity (and the fd leaks if you forget it) are no big deal. Rust has no GC, and it uses it for a lot more.

Re: 2016 Rust Commercial User Survey Results

#40

Post by xenadu02 »

dreta wrote: post #27
pcwalton wrote: post #24

Earlier quoted context omitted.

> I’d love to see a survey talking about what bugs get actually solved by using one of these modern languages like Rust or Swift, since i personally never once in my career had a bug that wouldn’t have happened if i used const, let alone any of the many other annoying Rust features. A quick analysis I did showed that half of the critical security vulnerabilities in Gecko would have been prevented by writing content a…

Alright, thanks for clearing that up. I missed those in the documentation, since it doesn’t specify any of this directly. Though, still wide registers aren’t a language feature. I don’t care, nor do i think any other seasoned programmer does, about the language “freeing me from the need to deal with raw memory”. It doesn’t. The types of problems you solve by introducing built-in string types and vectors aren’t proble…

Clearly you haven't done even basic research into Rust. That's OK, but I don't think you should be spouting off in HN comments about how useless it is.

Rust is all about memory safety. The borrow checker gives you compile-time memory safety guarantees (sans unsafe blocks). The address of the struct you passed to some function which then took the address of an inner field and populated a value in a returned object? Yeah... Rust knows whether that's safe or you've set yourself up for a dangling pointer. Bounds-checking is child's play to Rust.

The bulk (if not the majority) of high-impact security vulnerabilities are related to memory safety in some form. Rust eliminates those as an entire class of problem.

Post reply on HN