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

The struggle with Rust

ayende.com

Post reply on HN
Print view View original

101–110 of 301 posts

Re: The struggle with Rust

#101

Post by gcp »

eternalban wrote: post #73
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…

You came from interpreted Python to compiled OCaml and I suspect that your initial encounter with a compiler is the underlying issue. (For example, being new to FP but very friendly with compilers -- C, C++, Java, C# -- I found the initial OCaml encounter surprisingly pleasant. Haskell was something else though :)) I looked at Rust specs 1.0 when they were released and immediately recognized that Rust is not a 'datin…

And imho the initial promise of addressing the out of control complexity of C++ was not met.

I'm not sure. Type traits seem to be much more manageable than how the same thing is handled in C++ template code, no?

Also, if we can bring in ecosystem effects such as cargo...

Re: The struggle with Rust

#102

Post by rubber_duck »

the_af wrote: post #84
rubber_duck wrote: post #28

Earlier quoted context omitted.

Yes but going from one to the other is relatively straightforward and possible in small steps of progression - Rust forces you to deal with a lot of things up front which is why people complain. eg. if you're a C++ developer you'll pick up Java very fast, it will take a while to be super productive but you can start working really fast.

That's because a lot of things (let's not debate exactly how many here) translate well between C++ and Java. But my point wasn't about going between relatively similar languages; it was about learning something radically different for the first time, like it was when you learned your first programming language.

But that's not going to work in practice - there are many skilled C++ devs and C++ has many ingrained legacy issues which another systems programming language could solve - but the bridge between that language and C++ must exist for this to happen. Like in the post, OP is a competent programmer - he can solve his problem in C++ - why would he invest months in to Rust to do the same thing ? If your answer is safety then OK that will matter to some but a lot of people don't care enough about it to pay the cost of switching.

Re: The struggle with Rust

#103

Post by vertex-four »

rubber_duck wrote: post #94
zzzcpan wrote: post #87

Earlier quoted context omitted.

There might be an easy solution, they could provide more flexibility on using safety features, kind of like Perl did it, i.e. let anyone disable/enable a particular strict feature for a particular scope, for example "no borrowcheck;" or something. This will make it easier and more flexible for everyone, newcomers will be able to gradually learn more about the language and still get things done in the meantime, and po…

They have that with the "unsafe" blocks but like I said promoting it as something you should use when things don't fit borrow-checker goes against their primary goal of making things safe. I guess there are two camps, one that wants compile time safety guarantees - those people made Rust, and the other wants a C++ replacement with modern tooling and no legacy garbage - those are looking at Rust and getting discourage…

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 rehashing ideas from multiple decades ago with new syntax, and not making anything particularly easier to do.

Re: The struggle with Rust

#104

Post by zzzcpan »

rubber_duck wrote: post #94
zzzcpan wrote: post #87

Earlier quoted context omitted.

There might be an easy solution, they could provide more flexibility on using safety features, kind of like Perl did it, i.e. let anyone disable/enable a particular strict feature for a particular scope, for example "no borrowcheck;" or something. This will make it easier and more flexible for everyone, newcomers will be able to gradually learn more about the language and still get things done in the meantime, and po…

They have that with the "unsafe" blocks but like I said promoting it as something you should use when things don't fit borrow-checker goes against their primary goal of making things safe. I guess there are two camps, one that wants compile time safety guarantees - those people made Rust, and the other wants a C++ replacement with modern tooling and no legacy garbage - those are looking at Rust and getting discourage…

As I understand it, you can't disable just borrow checker somewhere where you don't need it.

Re: The struggle with Rust

#105

Post by gcp »

bronson wrote: post #76
justinlaster wrote: post #21

>So I spent a few evenings with Rust I stopped reading. There is literally nothing you could possibly say that'd be worthwhile after "a few evenings" with Rust, especially when you lack the proper background in the first place. This trend of "The problem with Rust: A naive and inexperienced perspective"-esque articles is already old.

I made it to > I have a buffer, that I want to mutate using pointers Turns out you were right.

Yeah, that entire paragraph is basically a list of all the things safe Rust will not allow you to do. It should be a sign that you're tackling the problem the wrong way around...

Re: The struggle with Rust

#106

Post by pka »

bpicolo wrote: post #30
rubber_duck wrote: post #22

Earlier quoted context omitted.

>It takes months of steady investment (and yes, frustration), but the payoffs are spectacular. This was the exact same thing I kept reading back when functional programming was becoming in vogue - people were pushing for Haskell, saying that purity and laziness were amazing, type system could almost prove correctness at compile time, etc. etc. You just need to meditate deeply on category theory and draw direction gra…

I'm a big fan of hybrid functionals. I think being able to fall back to somewhat imperative code makes sense on occasion. Some things are better expressed in either paradigm, and that's OK.

You can do that perfectly fine even in a pure language like Haskell.

Re: The struggle with Rust

#107

Post by kernelbandwidth »

> The very same trie code that I tried to write in Rust I wrote in one & half evenings in C++

Use unsafe. No, really, just use unsafe.

Clearly a big value of Rust is that it's a safe language, and the design patterns around safety and affine typing are emerging and good. We should want people to write and use safe code as much as possible. But the trie example seems, to me, to be very much the sort of thing unsafe is for. Writing in C++ is essentially doing everything in unsafe. Unsafe is not evil; it's an important part of the language and when it's called for, it's called for.

Re: The struggle with Rust

#108

Post by ajmurmann »

trishume wrote: post #18
adwhit wrote: post #5

These sorts of articles are starting to pop up a bit more frequently, presumably because Rust is starting to get a bit of traction. The theme is "I know $LOW_LEVEL_LANGUAGE therefore I should be able to program Rust. I spent a few days and couldn't. I don't like Rust." Unfortunately, things aren't that simple and Rust really is different from other languages. It takes months of steady investment (and yes, frustration…

Agreed. Rust is different from other languages in that it is HARD to learn. It took me 3 projects and thousands of lines of code before I finally felt like I'm okay at Rust. Each project involved tons of compiler fighting that I now know how to avoid or solve. The problem is that instead of a general technique for solving borrow checker issues, every issue has a different specific technique. Hash map matches (like th…

The issues and solutions you list sound super valuable. Do you know if there is a write up about those issues somewhere or did you just learn through blood and sweat?

Re: The struggle with Rust

#109

Post by Bartweiss »

omouse wrote: post #96
rubber_duck wrote: post #22

Earlier quoted context omitted.

>It takes months of steady investment (and yes, frustration), but the payoffs are spectacular. This was the exact same thing I kept reading back when functional programming was becoming in vogue - people were pushing for Haskell, saying that purity and laziness were amazing, type system could almost prove correctness at compile time, etc. etc. You just need to meditate deeply on category theory and draw direction gra…

To get any programming done, you have to learn certain things, you can't complain that it takes weeks to learn a new programming language and months to assimilate it's model of thinking. But saying "you need to spend a few months to get intimately acquainted with the language" is just not going to work in practice if you're hoping about breaking in to the mainstream. You mean it's okay for everyone to struggle to wor…

> You mean it's okay for everyone to struggle to work with JavaScript for years and years trying to come up with an OO system and a module system and trying to just bundle the files for the browser, but it's not okay to spend months on getting intimately acquainted with the language?

You're saying that like those things are a contrast, not two incarnations of the same issue. Safe-and-usable is the holy grail for exactly this reason - right now we have usable-but-unsafe. Javascript isn't a few months to get acquainted: it's a few days to get passable results and a lifetime to get good ones.

So there's a huge need for a better mainstream tool, because the alternative is letting the existing ones endure. That doesn't have to be Rust - there's plenty of space for languages that are hard, but good for key applications like safe browsers. But it has to be something - lecturing people doesn't actually reduce reliance on easy-to-learn, hard-to-secure options.

Re: The struggle with Rust

#110

Post by the_af »

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…

C++ has a pretty steep learning curve, yet people use it.

Many things in tech are tradeoffs. Sometimes the additional tools a language brings to the table are worth the learning curve, sometimes they aren't. There are people in the industry for which FP (or Rust, or whatever) is worth it. For you it isn't. That's life.

Post reply on HN