The struggle with Rust • Hacker News Board

Re: The struggle with Rust

#181

Post by AsyncAwait » Tue, Jan 24, 2017, 5:12 PM UTC

camus2 wrote: post #85

the_af wrote: post #79

Earlier quoted context omitted.

That's my point. I think people complaining that Rust (or Haskell, or whichever paradigm shift) "takes too long to learn" have forgotten what it was to learn their first language. It took them long, because some things take long. Learning something different takes time, but it's easy to forget this once you have a couple of languages under your belt.

> I think people complaining that Rust (or Haskell, or whichever paradigm shift) "takes too long to learn" have forgotten what it was to learn their first language Because they are required to be productive fast. A professional usually doesn't learn a new language just for the sake of it. If the language doesn't yield instant benefits then most people aren't going to bother learning it. If a steep learning curve is e…

I think that OP's point is that Haskell or Rust introduce enough of a different paradigm that it is worth thinking about them anew, rather than trying to map your old programming language knowledge to Rust or Haskell directly.

Re: The struggle with Rust

#182

Post by jnbiche » Tue, Jan 24, 2017, 5:16 PM UTC

stonemetal wrote: post #90

jackmott wrote: post #81

Earlier quoted context omitted.

I don't think they are any error classes that OCaml/F# will let you make that Rust won't.

Rust prevents data races, OCaml/F# don't provide such guaranties. Though it isn't so much of a problem in OCaml since it doesn't have concurrent threads.

OCaml has GIL, is normally single core, and shares no state, so current OCaml doesn't need to provide such guarantees.

Upcoming multicore OCaml will provide such guarantees through algebraic effects [0].

0. http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multico...

Re: The struggle with Rust

#183

Post by GregBuchholz » Tue, Jan 24, 2017, 5:19 PM UTC

Bartweiss wrote: post #98

jnbiche wrote: post #80

Earlier quoted context omitted.

> I want the compiler to tell me when I'm making the mistake, even if it makes things choppier. You don't think the OCaml type system would do this? OCaml gives you just as much safety as Rust does, it just doesn't also give you no GC like Rust does. And the price Rust pays for the absence of GC is the lifetime concept, which adds a very significant layer of complexity to the language. Much like OCaml, Swift and Scal…

OCaml seems like the argument against Rust's claim to trade usability for safety. It's not true for everything, I wouldn't write embedded OCaml, but it's an easy disproof-by-example for "Rust's difficulty is the inevitable price for trustworthy code!" Which isn't to say OCaml is trivial, or Rust is useless (GC and threading both being limitations). It just makes me skeptical of claims that Rust's difficulty is irredu…

>I wouldn't write embedded OCaml

But you can run OCaml on a microcontroller:

http://www.algo-prog.info/ocapic/web/index.php?id=ocapic

Re: The struggle with Rust

#184

Post by lmm » Tue, Jan 24, 2017, 5:19 PM UTC

gravypod wrote: post #150

lmm wrote: post #122

Earlier quoted context omitted.

> From a usability standpoint it does not. The use case of systems programming usually involves many mutators on a single piece of, non-copiable, data. I can see why the person writing the Rust prover would say "yea this is the best" but I can't see why anyone else would because it's filter cuts out a large portion of completely valid code that is not incorrect but instead is "scary" or "spooky". I find passing owner…

> The hard part is forming the model. Once you actually know how it's supposed to work, proving it is the easy part. But I mean, how would you even explain to another human that a given algorithm is safe, if not by arguments along the line of "look, this function owns this piece of data and this function owns this piece of data and they're called one after the other"? One example of how this could work is writing a s…

I don't think I understand your point.

You can use e.g. Nat in Idris to avoid the underflow possibility. A language shouldn't allow silent overflow, and to the extent that Rust encourages a style where you fiddle with overflowing integers this is a problem with Rust, though I don't believe Rust does encourage that style - it provides locks, and if you were writing a custom one for some reason you wouldn't naturally fiddle with an int, you'd use an affine type or some such.

Re: The struggle with Rust

#185

Post by AsyncAwait » Tue, Jan 24, 2017, 5:20 PM UTC

geodel wrote: post #48

the_duke wrote: post #45

Earlier quoted context omitted.

I think the problems with Haskell are quite different than the ones with Rust. Haskell suffers more from being a research playground, bad documentation for both the language and it's libraries, confronting you with many unusual concepts (type theory, monads, laziness,...) and, as a pretty old language, a lot of legacy cruft that makes a lot of things awkward (string handling is the prime example). Rust wants to be a…

> Rust wants to be a widely used language I am sure they want that. But so many responses of Rust enthusiasts to any article/blog less than flattering get very aggressive. May be Steve Jobs got away with 'You're holding it wrong' but I doubt incoming users for Rust will be this kind.

Honestly, Hacker News is too general to base your opinion of the "Rust community" on, try #rust-beginners on irc.mozilla.org or users.rust-lang.org and I think you'll find one of the most welcoming communities on the internet.

Re: The struggle with Rust

#186

Post by rbehrends » Tue, Jan 24, 2017, 5:21 PM UTC

bluejekyll wrote: post #162

rbehrends wrote: post #123

Earlier quoted context omitted.

> First, the expressiveness is all there. You just need to explicitly say you are responsible by using unsafe blocks. So risky pointer and allocation logic becomes the programmer's job, not the borrow checker. No, unsafe would be overkill and if you needed unsafe, it would put Rust at a massive disadvantage vis-à-vis garbage-collected languages. Simply put, Rust doesn't handle multiple ownership well. It results in s…

I think you're implication here is that other languages do handle multiple ownership well. What I think you find in Rust, is that the guarantees you need to make when using unsafe in these limited situations, are the exact same guarantees you need to make in a language like C or C++. Destroying a circular list takes some thought to make sure you don't double free, same as Rust. Rust just makes those sections of code…

Your assumption seems to be that I'm talking about languages with manual memory management. I'm not; I'm talking about garbage-collected languages, where you get memory safety automatically, regardless of ownership rules. In fact, C++ has some of the same problems that Rust has when it comes to multiple ownership.

Re: The struggle with Rust

#187

Post by kibwen » Tue, Jan 24, 2017, 5:22 PM UTC

Bartweiss wrote: post #98

jnbiche wrote: post #80

Earlier quoted context omitted.

> I want the compiler to tell me when I'm making the mistake, even if it makes things choppier. You don't think the OCaml type system would do this? OCaml gives you just as much safety as Rust does, it just doesn't also give you no GC like Rust does. And the price Rust pays for the absence of GC is the lifetime concept, which adds a very significant layer of complexity to the language. Much like OCaml, Swift and Scal…

OCaml seems like the argument against Rust's claim to trade usability for safety. It's not true for everything, I wouldn't write embedded OCaml, but it's an easy disproof-by-example for "Rust's difficulty is the inevitable price for trustworthy code!" Which isn't to say OCaml is trivial, or Rust is useless (GC and threading both being limitations). It just makes me skeptical of claims that Rust's difficulty is irredu…

Rust's difficulty relative to OCaml might be irreducible if we consider the difficulty added by not providing a pervasive GC, which is part of Rust's design goal and not part of OCaml's.

Re: The struggle with Rust

#188

Post by kibwen » Tue, Jan 24, 2017, 5:27 PM UTC

sametmax wrote: post #83

smt88 wrote: post #67

Earlier quoted context omitted.

> smooth brain to text programming This isn't a good thing, in my opinion. Brains make mistakes. I don't want smooth, uninterrupted coding. I want the compiler to tell me when I'm making the mistake, even if it makes things choppier. It's a lot less painful to write code in fits and starts than to write a million tests or spend hours debugging.

It depends a lot of what you code and your constraints. Believe it or not they are a huge crowd of people making a living out of code that is easy to write but crashes. And they are happy about it. E.G: one of my friend has a streaming website. He make banks with ads despite the site having problems all the time. He doesn't care the least. He is not an expert coder and just want to be able to build the features he ne…

And I think that's fine; Rust isn't trying to be the one language to rule them all. It's intended as a foundational language: your friend's streaming website survives despite his own code crashing often, but it won't survive if his off-the-shelf HTTP server crashes often (HTTP servers being the sort of thing one would write in Rust). Likewise, your mathematicians aren't going to be very productive if their Python interpreter crashes often (likewise, interpreters are the sort of thing one would also imagine writing in Rust).

Even in Rust's ideal future, very little of the code atop the stack is written in it. It's the code at the very bottom that underpins everything whose share it hopes to eat.

Re: The struggle with Rust

#189

Post by AsyncAwait » Tue, Jan 24, 2017, 5:28 PM UTC

shadowmint wrote: post #146

vertex-four wrote: post #103

Earlier quoted context omitted.

You're almost certainly not looking for Rust if you don't want your language to prevent a vast variety of bugs, and instead want something that allows and encourages you to design systems which make it easy to shoot yourself in the foot (which all C++ codebases I've ever seen have grown). I don't think language developers are interested in making such a language in general, as it's not interesting - you'd just be reh…

I don't think language developers are interested in making such a language in general... https://inductive.no/jai/ :P I'd argue go came from a desire to have a language that was completely uninteresting in terms of 'interesting ideas', and really just exists to Get Stuff Done. I think more people are interested in that sort of thing than you imagine. Clearly.

Jai is designed on a bunch of false assumptions, which makes it hard to get excited about.

Or more precisely, the designer of Jai uses C++ as "C with classes" and then goes from that, which isn't fair. He also misrepresented a few things in regards to Rust, which he doesn't even know, but comments on etc. etc.

Re: The struggle with Rust

#190

Post by pmoriarty » Tue, Jan 24, 2017, 5:30 PM UTC

gnuvince wrote: post #11

When I first learned OCaml (knowing only Python), I swore a lot at the type checker for refusing to compile code that I knew would work at run-time (e.g., a variable having multiple types, but on strictly disjoint execution paths). It seemed insane to me that people would want to subject themselves to this kind of bondage and discipline. And yet, many years later now, I have learned and internalized how type systems…

I never got past the pain-in-the-ass stage of dealing with the OCaml compiler. I hated wrestling with it for something simple. It really slowed me down to no end.

I remember asking on freenode's #ocaml for help with a convoluted error message, and when I was told what it meant and how to fix it, I asked how the person who helped me knew what it meant. He told me he'd taken two semesters of type theory courses at uni. Having to spend a year taking university-level courses in order to effectively program in OCaml seemed like way too much pain for too little gain when there were so many other less painful languages to program in.

Later I discovered Lisp and then Scheme. Both were a sheer joy to use compared to OCaml. I didn't have to wrestle with the type checker, my programs were quick and easy to write and understand, and in their own way the languages were just as powerful as OCaml was. Sure, OCaml had them beat at safety (at least if you were comparing ordinary Lisps and Schemes, not statically typed versions or extensions with more safety features) but it way, way more painful and slow to program in, for me. I recognize that if you need the safety, then the pain might be worth it. But even then it might be worthwhile to program in a dynamic language like Lisp/Scheme and then once the program matures, rewrite it in a safe language like OCaml. But even then, I think I'd just rather dial up the safety features of Lisp/Scheme or use one of the static versions.

That's just me. I know some people love OCaml. And I'm sure I'm missing some of its wonders that are only apparent when you dive deep enough in to the language. But from what I did learn of it, it just wasn't for me.