2016 Rust Commercial User Survey Results • Hacker News Board

Re: 2016 Rust Commercial User Survey Results

#81

Post by [deleted] » Sat, Nov 05, 2016, 2:41 AM UTC

sidlls wrote: post #22

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.

Long time C++ programmer here. I specifically like the immutable-by-default, borrow, and move semantics. I can write safe code without bloating up my source with 'const &', std::move, '&& ...' and the like. The safety issue for me is about the least important thing. Touting it as the big reason to use Rust is a distraction from my point of view.

[deleted]

Re: 2016 Rust Commercial User Survey Results

#82

Post by Manishearth » Sat, Nov 05, 2016, 2:41 AM UTC

cm3 wrote: post #70

This wasn't one of the question of the survey, but while having the right crowd around, I have to ask. When will Rust get 1. function head patterns like other languages in the ML family, although Rust isn't really part of the family, but rather a distant cousin from another continent, which once played with ML and family during a summer vacation 2. support for naturally writing recursive functions

> Rust isn't really part of the family, but rather a distant cousin from another continent, which once played with ML and family during a summer vacation

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.

> function head patterns like other languages in the ML family

could you elaborate? I'm not familiar with this feature (only have dabbled in sml).

> support for naturally writing recursive functions

yeah, I wish we had TCO.

Re: 2016 Rust Commercial User Survey Results

#83

Post by burntsushi » Sat, Nov 05, 2016, 2:43 AM UTC

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 published a regex library for Rust a few years ago. Since then, it's been downloaded a million times and used in over 300 published crates. I've had 0 reports of seg faults or buffer overflows.

Can regex libraries written in C say the same? I don't think so.[1]

[1] - https://www.cvedetails.com/vulnerability-list/vendor_id-3265...

Re: 2016 Rust Commercial User Survey Results

#84

Post by cm3 » Sat, Nov 05, 2016, 2:46 AM UTC

kibwen wrote: post #79

cm3 wrote: post #72

Earlier quoted context omitted.

We are discouraged from writing recursive functions, which comes naturally when expressing many algorithms. Missing TCO is one cited reason to avoid it, so I gather we're not supposed to, generally speaking.

Support for guaranteeing TCE is possible and has been proposed, but there remain a few open questions, e.g. what to do about local variables with destructors (personally I'd statically forbid them from being in scope at the end of tail-call recursive functions).

I know, that's why I wrote "when", knowing it's been considered, but it doesn't appear to be missed by enough developers. I'm just spoiled having used those two features, and anytime someone cites the ML family as part of Rust's influence, it reminds me of these two basic, missing features.

Regarding semantics, without having thought about the Rust semantics too much, I'd suggest to check out the most prominent uses for recursive functions in OCaml, SML or Haskell, then try to consider that as the sweet spot to support in Rust.

Re: 2016 Rust Commercial User Survey Results

#85

Post by cm3 » Sat, Nov 05, 2016, 2:54 AM UTC

Manishearth wrote: post #82

cm3 wrote: post #70

This wasn't one of the question of the survey, but while having the right crowd around, I have to ask. When will Rust get 1. function head patterns like other languages in the ML family, although Rust isn't really part of the family, but rather a distant cousin from another continent, which once played with ML and family during a summer vacation 2. support for naturally writing recursive functions

> Rust isn't really part of the family, but rather a distant cousin from another continent, which once played with ML and family during a summer vacation 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 Rus…

> 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 it broke every week, and was then surprised with the surface of 1.0. It seemed like a different person to talk to.

I've made my peace with the C'ification of Rust as the price to pay for attracting a large crowd of developers who grew up with C, C++, C#, Java, JavaScript, Ruby, Python, the list goes on. It's a reasonable sacrifice to make, but the two mentioned basic features aren't complex things to wish for.

> could you elaborate? I'm not familiar with this feature (only have dabbled in sml).

Imagine being able to hoist your match clauses into function head (signature?).

  oldEnoughToDrink :: Int -> Boolean
  oldEnoughToDrink 21 -> True
  oldEnoughToDrink _  -> False

Not all languages with support for that force you to repeat the function name, and there are good arguments for/against. For example in Erlang, when you define an anonymous function, you do not repeat it:

  OldEnough = fun(21) -> true;
                 (_)  -> false
              end,

Now, this may seem like a stupid little feature, but trust me when I say it's a natural feature to use like recursive functions after you're used to it.

Re: 2016 Rust Commercial User Survey Results

#86

Post by oconnor663 » Sat, Nov 05, 2016, 2:58 AM UTC

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…

>> 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 that's right, it's a complaint I mostly agree with. Functional programming can cram quite a bit into one line, and that's all well and good, but 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.

I agree with your rule of thumb. Functional stuff is great when what it's doing is obvious.

Re: 2016 Rust Commercial User Survey Results

#87

Post by olauzon » Sat, Nov 05, 2016, 2:59 AM UTC

Manishearth wrote: post #76

olauzon wrote: post #67

Earlier quoted context omitted.

Similar story here. Been using Rust in production for only a couple of weeks for a financial analytics pipeline processing billions of events per day and TBs of data, but absolutely no issues so far. The predictable performance of Rust has been wonderful to observe, compared to GC'ed languages this iteration of the pipeline has replaced (JVM, Go). The type system makes otherwise daring refactorings a joy.

-> https://news.ycombinator.com/item?id=12877334 :)

Will ask employer for approval :)

Re: 2016 Rust Commercial User Survey Results

#88

Post by throwmeaway11 » Sat, Nov 05, 2016, 3:09 AM UTC

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.

Re: 2016 Rust Commercial User Survey Results

#89

Post by cm3 » Sat, Nov 05, 2016, 3:11 AM UTC

cm3 wrote: post #70

This wasn't one of the question of the survey, but while having the right crowd around, I have to ask. When will Rust get 1. function head patterns like other languages in the ML family, although Rust isn't really part of the family, but rather a distant cousin from another continent, which once played with ML and family during a summer vacation 2. support for naturally writing recursive functions

I should add 3, Erlang's bit syntax, which would be a perfect and natural fit for the target of Rust code. It's a very natural DSL to parse or build (complex) bit streams. You don't necessarily have to add bit syntax comprehensions.

Re: 2016 Rust Commercial User Survey Results

#90

Post by Manishearth » Sat, Nov 05, 2016, 3:25 AM UTC

cm3 wrote: post #85

Manishearth wrote: post #82

Earlier quoted context omitted.

> Rust isn't really part of the family, but rather a distant cousin from another continent, which once played with ML and family during a summer vacation 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 Rus…

> 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 try though.