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

41–50 of 131 posts

Re: 2016 Rust Commercial User Survey Results

#41

Post by pjmlp »

dreta wrote: post #34
pcwalton wrote: post #28

Earlier quoted context omitted.

> 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 everyone has the privilege to be a single C coder owning the code without anyone else from different skill levels coding in it and without any additional use of third party libraries.

Re: 2016 Rust Commercial User Survey Results

#42

Post by dbaupp »

dreta wrote: post #34
pcwalton wrote: post #28

Earlier quoted context omitted.

> 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…

> What i’d want is a generic support for preventing buffer overflows, or bad memory access where i need it

You have that.

For example, if you have contiguous memory, the various forms of the [T] slice type can be used, they don't impose any allocation expectations. (And, once the standard library allows pluggable allocators, you'll likely be able to use Vec directly, for a growable vector type.)

If you don't have contiguous memory, then it's a bit more work, but one can still use features like generics and privacy to spend a few lines building abstractions that bounds check in the right places. It's not like using a proof language to extract a program that is guaranteed to have no out of bounds accesses, or a compiler that some how deduces what the bounds of your data structure is, but the former has its own complexity downsides, and the latter seems infeasible, in general.

Re: 2016 Rust Commercial User Survey Results

#43

Post by sidlls »

dreta wrote: post #37
sidlls wrote: post #33

Earlier quoted context omitted.

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.

I haven't, either. I've come across plenty that would save me from having painful gdb sessions to fix code inexperienced (or lazy) developers write.

Re: 2016 Rust Commercial User Survey Results

#44

Post by xenadu02 »

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 &…

Supposedly Swift 4 is introducing an optional borrow-checker. Types can opt-in and you get the same kind of lifetime guarantees and semantics as Rust. If you don't opt-in you get copying for value types and reference counts for reference types.

I'm curious how either approach will work out in the long run. I understand why Rust made the decisions it did wrt ditching built-in GC/non-GC support but it will definitely hamper its adoption for writing GUI applications. If Swift manages to thread the needle in supporting systems-level / kernel programming with borrow-checked types while not imposing that mental and maintenance cost on GUI apps it will be an amazing thing.

In any case it is exciting to see high-level languages with memory safety proving you can have something much better than C without going full-on virtual machine, runtime, and JIT.

Re: 2016 Rust Commercial User Survey Results

#45

Post by dreta »

xenadu02 wrote: post #40
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…

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? Ye…

I went through all the Rust features. It doesn’t eliminate memory safety issues at all.

Re: 2016 Rust Commercial User Survey Results

#46

Post by dbaupp »

dreta wrote: post #45
xenadu02 wrote: post #40

Earlier quoted context omitted.

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? Ye…

I went through all the Rust features. It doesn’t eliminate memory safety issues at all.

What's a specific memory safety issue Rust has outside `unsafe` code?

Re: 2016 Rust Commercial User Survey Results

#47

Post by Retra »

sidlls wrote: post #17
dbaupp wrote: post #15

Earlier quoted context omitted.

> - The type system is unusual, and complex. It's hard to do anything without templates. Do you mean the generic types and functions that stop you having to reimplement a whole pile of common patterns and data types yourself? You're welcome to write your own VecInt and VecString and VecMyStruct and VecYourStruct and OptionInt and HashMapIntString, but I'll go out on a limb and say that would be more annoying than 's…

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 standard library will introduce a huge amount of churn and breakage. (And if you try to avoid churn and breakage, you're hamstrung by the current implementation to a num crate that suits nobodies needs.)

Re: 2016 Rust Commercial User Survey Results

#48

Post by pcwalton »

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.

Python uses destructors/finalizers to free OS resources and a GC to free memory. Because Rust has no GC, it uses destructors for memory and OS resources. So adopting Python's scheme for calling destructors would force us into using that for memory as well.

Re: 2016 Rust Commercial User Survey Results

#49

Post by dreta »

dbaupp wrote: post #42
dreta wrote: post #34

Earlier quoted context omitted.

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…

> What i’d want is a generic support for preventing buffer overflows, or bad memory access where i need it You have that. For example, if you have contiguous memory, the various forms of the [T] slice type can be used, they don't impose any allocation expectations. (And, once the standard library allows pluggable allocators, you'll likely be able to use Vec directly, for a growable vector type.) If you don't have con…

None of the things you mentioned, other than the slice type, which i don’t see how it would work on raw memory, are a language feature.

Re: 2016 Rust Commercial User Survey Results

#50

Post by Manishearth »

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…

Though if you want to be polymorphic over "adding things" you can just bound on Add :) If you want to be more restrictive over what you want to bound over then the Num crate comes into play.
Post reply on HN