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

My “grand vision” for Rust

blog.yoshuawuyts.com

Post reply on HN
Print view View original

251–260 of 323 posts

Re: My “grand vision” for Rust

#251

Post by thomasmg »

rapnie wrote: post #168
ChadNauseam wrote: post #155

Earlier quoted context omitted.

I honestly just don't believe that Rust is more complex to onboard to compared to languages like Python. It just does not match my experience at all. I've been a professional rust developer for about three years. Every time I look at python code, it's doing something insane where the function argument definition basically looks like line noise with args and kwargs, with no types, so it's impossible to guess what the…

The language itself is not more complex to onboard. For Scala also not. It feels great to have all these language features to ones proposal. The added complexity is in the way how expert code is written. The experts are empowered and productive, but heightens the barrier of entry for newcomers by their practices. Note that they also might expertly write more accessible code to avoid the issue, and then I agree with (…

Hm, you claim that Rust and Scala are not more complex to onboard than Python... but then you say you never used Python? If that's the case, how do you know? Having used both, I do think Rust is harder to onboard, just because there is more syntax that you need to learn. And Rust is a lot more verbose. And that's before you are exposed to the borrow checker.

Re: My “grand vision” for Rust

#252

Post by School-Cotton »

9rx wrote: post #243
School-Cotton wrote: post #241

Earlier quoted context omitted.

Can you enlighten us to what you’re talking about instead of vagueposting like this? What’s the supposed way of simulating sum types in go?

I am not sure how would you would simulate them. With enums and structs, I suppose? However, it also has true sum types: type SumType interface { isSumType() } type A string func (A) isSumType() type B int func (B) isSumType() But as you can see the syntax leaves a lot to be desired and may not be all that obvious to those who are hung up thinking in other languages.

interfaces in go aren’t types, so no, that’s not a sum type, it’s just an interface.

The set of objects that can fulfill that interface is not just string and int, it’s anything in the world that someone might decide to write an isSumType function for.

Re: My “grand vision” for Rust

#253

Post by thomasmg »

gignico wrote: post #157
QuantumNoodle wrote: post #94

I write production Rust code that becomes critical infra for our customers. I got tired of nil checks in Go and became a squeaky wheel in incident retros, where I finally got the chance to rewrite parts of our system in Rust during a refactor. I admit the skill issue on my part, but I genuinely struggled to follow the concepts in this article. Working alongside peers who push Rust's bleeding edge, I dread reviewing t…

I think the misunderstanding here is that the article was not intended to users but to other language designers. As a user, using a feature such as pattern types will be natural if you know the rest of the language. Do you have a function that accepts an enum `MyEnum` but has an `unreachable!()` for some variant that you know is impossible to have at that point? Then you can accept a `MyEnum is MyEnum::Variant | MyEn…

> the article was not intended to users but to other language designers.

That might be true, but it shows the direction that Rust is talking: put in the kitchen sink, just like C++ and Scala did. And _that_ is very much important for users.

Re: My “grand vision” for Rust

#254

Post by 9rx »

School-Cotton wrote: post #252
9rx wrote: post #243

Earlier quoted context omitted.

I am not sure how would you would simulate them. With enums and structs, I suppose? However, it also has true sum types: type SumType interface { isSumType() } type A string func (A) isSumType() type B int func (B) isSumType() But as you can see the syntax leaves a lot to be desired and may not be all that obvious to those who are hung up thinking in other languages.

interfaces in go aren’t types, so no, that’s not a sum type, it’s just an interface. The set of objects that can fulfill that interface is not just string and int, it’s anything in the world that someone might decide to write an isSumType function for.

> it’s anything in the world that someone might decide to write an isSumType function for.

No. Notice the lowercase tag name. It is impossible for anyone else to add an arbitrary type to the closed set.

Unless your argument is that sum types fundamentally cannot exist? Obviously given a more traditional syntax like,

   type SumType tagged {
      A | B
   }
...one can come along and add C just the same. I guess that is true in some natural properties of the universe way. It is a poor take in context, however.

Re: My “grand vision” for Rust

#255

Post by [deleted] »

QuantumNoodle wrote: post #94

I write production Rust code that becomes critical infra for our customers. I got tired of nil checks in Go and became a squeaky wheel in incident retros, where I finally got the chance to rewrite parts of our system in Rust during a refactor. I admit the skill issue on my part, but I genuinely struggled to follow the concepts in this article. Working alongside peers who push Rust's bleeding edge, I dread reviewing t…

[deleted]

Re: My “grand vision” for Rust

#256

Post by zamalek »

Pedro_Ribeiro wrote: post #60
zamalek wrote: post #42

I'm terrified by the notion of try fns. Are we getting exceptions (and therefore losing one of rust's greatest features)?

Isn't his point exactly that we don't want to have too many function colors and instead want a generic way of declaring side effects so people can do what they want (be it try fns, IO, async, etc..., no panicking)?

From the article:

> And on nightly it also has support for try fn and gen fn.

I haven't been able to figure out what a try fn is.

Re: My “grand vision” for Rust

#257

Post by DangitBobby »

ozgrakkurt wrote: post #165
ChadNauseam wrote: post #153

Earlier quoted context omitted.

You didn't mention parametric polymorphism, which is incredibly useful and important to the language. I'm guessing you intentionally excluded async, but to describe it as "not that useful" would just be wrong, there is a large class of programs that can be expressed very simply using async rust but would be very complicated to express in sync rust (assuming equivalent performance).

Generics are incredibly overused in rust like most other features. I’m pretty sure most programs don’t need generics outside of use cases like HashMap

Lack of generics generally makes a modern language DoA unless some company dumps ungodly amounts of money into it.

Re: My “grand vision” for Rust

#258

Post by hu3 »

theknarf wrote: post #216

I'm surprised by the backlash in the comment section here, all of these things seems like the obvious next step for Rust. It seem people are scared of big words?

> It seem people are scared of big words?

Classic "skill issue" hubris by the language community.

Re: My “grand vision” for Rust

#259

Post by Folcon »

kibwen wrote: post #227
QuantumNoodle wrote: post #94

I write production Rust code that becomes critical infra for our customers. I got tired of nil checks in Go and became a squeaky wheel in incident retros, where I finally got the chance to rewrite parts of our system in Rust during a refactor. I admit the skill issue on my part, but I genuinely struggled to follow the concepts in this article. Working alongside peers who push Rust's bleeding edge, I dread reviewing t…

> I genuinely struggled to follow the concepts in this article I read the HN comments before I read the OP, which made me worry that the post was going to be some hifalutin type wonkiness. But instead the post is basically completely milquetoast, ordinary and accessible. I'm no type theorist--I cannot tell you what a monad is--and I confess that I don't understand how anyone could be intimidated by this article.

I think you're underestimating your competency

Things like effects aren't obvious to people, at least based on my experience of trying to teach it to people

Re: My “grand vision” for Rust

#260

Post by QuantumNoodle »

aw1621107 wrote: post #230
QuantumNoodle wrote: post #226

Earlier quoted context omitted.

I have no argument against using the right tool for a job. Decorating a function with a keyword to have more compile-time guarantees does sound great, but I bet it comes with strings attached that affect how it can be used which will lead to strange business logic. Anecdotally, I have not (perhaps yet) run into a situation where I needed more language features, I felt rust had enough primatives that I could adapt the…

> Could you share a situation where the behavior is necessary? The effects mentioned in the article are not too uncommon in embedded systems, particularly if they are subject to more stringent standards (e.g., hard realtime, safety-critical, etc.). In such situations predictability is paramount, and that tends to correspond to proving the absence of the effects in the OP.

Ah, the embedded application. Very valid point. I'm guilty of forgetting about that discipline.

I do wonder if it is possible to bin certain features to certain, uh, distributions(?), of rust? I'm having trouble articulating what I mean but in essence so users do not get tempted to use all these bells and whistles when they are aimed at a certain domain or application? Or are such language features beneficial for all applications?

For example, sim cards are mini computers that actually implement the JVM and you can write java and run it on sim cards (!). But there is a subset of java that is allowed and not all features are available. In this case it is due to compute/resource restrictions, but something to a similar tune for rust, is that possible?

Post reply on HN