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

211–220 of 301 posts

Re: The struggle with Rust

#211

Post by sh_tinh_hair »

rev_null wrote: post #86
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…

When the blub programmers look up the ladder, they see a bunch of type theory, monads, and laziness. They don't see the use for these features as they think in blub.

Exactly what I rail against in Rust. What do you see when you toss a coin friendo?

Re: The struggle with Rust

#212

Post by rbehrends »

rntz wrote: post #199
rbehrends wrote: post #153

Earlier quoted context omitted.

> This is pseudo-jargon. How do you measure expressiveness? Actually, not jargon. I had Matthias Felleisen's characterization of expressiveness [1] in mind (incidentally, he's also one of Racket's authors). > Do you have any substantive evidence that "good" typesystems don't reduce it? If we want to be precise, there is a continuum from statically to dynamically typed language. A dynamically typed language is, after…

EDIT: I've been chewing over the following: > This means that we can trivially translate a dynamically typed program into a statically typed program, though obviously we don't gain anything by that at this point (this is essentially an argument that Bob Harper has advanced before) and we pay for it in additional verbosity. This is exactly the opposite of the argument I advance below; you're claiming that there is a "…

> Great! I believe, by that definition, your assertion that "good" typesystems don't reduce expressiveness is false, at least for common type systems such as Haskell's, Java's, ML's, etc.

Haskell is not very good at extensible runtime polymorphism (one of its weaknesses). Try OCaml's polymorphic variants.

Re: The struggle with Rust

#213

Post by sh_tinh_hair »

mkawia wrote: post #144
burntsushi wrote: post #56

Earlier quoted context omitted.

If "correct" corresponds to "if and only if safe," then no, it's not correct because the code I posted in my previous comment is safe, but the borrow checker rejects it. I only posted samples to demonstrate working with the borrow checker. Think about this code: let mut owned = vec![1, 2]; let x = &mut owned[i]; let y = &mut owned[j]; What are the values of `i` and `j`? If they are equivalent, then this code is unsaf…

When in doubt be extra safe.

I guess that is equivalent to 'if it might be broke, break it'?

Re: The struggle with Rust

#214

Post by mtanski »

dman wrote: post #205
pcwalton wrote: post #165

Earlier quoted context omitted.

Just use petgraph. It manages all of this for you.

I work on databases and I ran into similar problems implementing index data structures. While I understand petgraph solves some/all of these problems completely - it would be great if the barrier to writing trees / graphs from scratch in Rust would be lower than it is currently.

Same problem. Working on an OLAP database toolkit (tried to in Rust)... writing typical database data structures is excruciating painful in Rust.

Trees, indexes (including bitmaps), buffer allocators and even just keeping state in streaming cursors (Volcano model). Are all pain in the ass in to implement.

In fact implementing a Cursor trait for like 10 different Cursor (SrcView, Join, Project, Compute, ...) became painful because each cursor struct has it's own complex lifetime params and those lifetimes were trying to leak into the main Cursor trait.

Right now I can't do that without resolving to runtime using RefCell. In my case the plans could be entirely materialized at compile time, so not really a win.

The situation won't get better until there's some kind of abstraction over lifetimes (HKT?).

Re: The struggle with Rust

#215

Post by pjmlp »

Recurecur wrote: post #171
jnbiche wrote: post #53

Earlier quoted context omitted.

> I believe that we are seeing the same kind of phenomenon in Rust: I don't know. I picked up OCaml fairly quickly, but I have consistently struggled with Rust, trying it for a while before abandoning it in frustration with lifetimes, 2 or 3 times. I can program in Rust, but it still seems like an ongoing struggle, as opposed to the smooth brain to text programming I've gotten used to in Python, JavaScript, OCaml, an…

> I think Rust may be ideal for embedded software development, or low-level systems software, but for general application development, I think OCaml or perhaps Swift or Scala are more ideal, at least for me (or at least until I decide to try Rust again, perhaps it will stick this time). If you're not aware of it, scala-native looks very interesting... It looks to be active project. https://github.com/scala-native/sca…

A benefit that Swift has over Rust in regards to market adoption, is that an OS vendor has the power to say "My way or the highway" to developers that want to target their platform.

However Rust is already picking up steam in Firefox modules, hobby OS development, university CS degrees and GNOME modules, so there might be a path there.

Re: The struggle with Rust

#216

Post by pjmlp »

Manishearth wrote: post #206
braveo wrote: post #166

Earlier quoted context omitted.

In other words, you weren't using it as the systems language it's billed as. Which is fine, but it's claimed to be a systems level language, and if it's really that painful to do systems level things, then there's a problem somewhere. Which is what's being discussed.

Rust contests the claim that you actually need to do pointer arithmetic and stuff often in systems languages. You need to do it a bit to implement your abstractions, maybe, but it is not the first tool you should need to reach for. The code in the blog post looks very much like C-translated-to-rust. Right now, systems programming mostly does look like C/C++ because those are the only two mainstream languages that wor…

> Do you really need to use malloc to allocate memory in a systems language? Do you really need to use pointer arithmetic to deal with things in a systems language?

To add to this point, my answer would be a big NO, if one would look to the C alternatives that sadly became niches.

Sadly the adoption of C has lead to younger generations thinking that those are the only valid paths in system languages.

Thankfully new languages, including Rust, are changing that.

Re: The struggle with Rust

#217

Post by Etzos »

threatofrain wrote: post #203
Etzos wrote: post #89

Earlier quoted context omitted.

I don't typically respond to comments like this anywhere, but I think this kind of view is dangerous to have. And it's one the Rust community at large seems to try to shy away from. This kind of attitude towards people trying out a new language is damaging to the person trying the new language and to people who are part of that languages community. The former because it will give them the notion that the community is…

For a language like Rust that puts all the pain up-front, I want to hear whether the pain is worth it. But someone who spends only a few days can't give you a weighing of whether the pain is worth it. I'm reluctant to even listen to someone's Amazon product opinion if they've only used it 2 days.

I certainly agree that an opinion piece like this has less weight than one which comes from someone who has spent a considerable amount of time with a language. However, saying that an opinion formed after only a few days is "worthless" is taking it too far.

Plus if one completely ignores pieces like this then they are more likely to fall into a rut where pain points like this are forgotten or ignored completely. While the actual pain of getting used to the Rust way of doing things may be harder to mitigate perhaps there is some insight in opinions like the ones presented in the blog here which can lead to a way to help people get over that pain in a quicker/less painful way.

Re: The struggle with Rust

#218

Post by bluejekyll »

spullara wrote: post #193
bluejekyll wrote: post #167

Earlier quoted context omitted.

Yes, and I understand how frustrating it can be, I had to learn it, too. My only point is that after you spend the time with it, the cognitive load becomes a lot less and you've learned some new things about programming at the same time.

I believe this. However, my concern is that the number of people willing to make it through that learning curve is small and will limit the adoption of Rust.

I'm hoping that things like the Rust Language Server and it's integration into some of the IDE's out there will help with the initial learning curve; already the rustc error output is a million times better than when I started with it.

I definitely share your concern; for me, Rust was like putting on a glove perfectly shaped for my hand. It works and prevents every basic pattern that it took 10 years to learn and start applying to all my code thereafter. If I had Rust all those years ago, it would have saved me a ton of time... but I probably would have turned my nose up at it, b/c I wouldn't have had the experience to understand what it was saving me from.

So yes, I want the learning curve to be lower, but not at the expense of losing all of the safety it brings to developing fast and reliable software.

Re: The struggle with Rust

#219

Post by draw_down »

omouse wrote: post #99

I know about GDB, that ain’t a good debugging experience I can't take this article seriously after reading that and after reading this: So I spent a few evenings with Rust How long did it take you to learn C, C++, Java, Python, Ruby, Perl or other languages? MONTHS. Many many many months. Sure you could get something up and running in a few evenings but after many months did you realize that earlier code could be bet…

I agree with him about GDB.

Re: The struggle with Rust

#220

Post by codygman »

rbehrends wrote: post #212
rntz wrote: post #199

Earlier quoted context omitted.

EDIT: I've been chewing over the following: > This means that we can trivially translate a dynamically typed program into a statically typed program, though obviously we don't gain anything by that at this point (this is essentially an argument that Bob Harper has advanced before) and we pay for it in additional verbosity. This is exactly the opposite of the argument I advance below; you're claiming that there is a "…

> Great! I believe, by that definition, your assertion that "good" typesystems don't reduce expressiveness is false, at least for common type systems such as Haskell's, Java's, ML's, etc. Haskell is not very good at extensible runtime polymorphism (one of its weaknesses). Try OCaml's polymorphic variants.

After quickly scanning https://realworldocaml.org/v1/en/html/variants.html, isn't the same thing accomplished by GADTs?
Post reply on HN