[deleted]
Monads and GATs in Nightly Rust
91–100 of 176 posts
Re: Monads and GATs in Nightly Rust
#92Earlier quoted context omitted.
> Is this a pain point at the moment for Rust devs? No, in rust as long as you don't use a feature you don't need to know about it. > Or is there actually a really large variety of styles? There are official(-ish?) style guidelines. So while there are a variety of styles most code uses mostly the same style. > I'm personally of the opinion that less is more. Sure, but you normally want to have a "complete well rounde…
> in rust as long as you don't use a feature you don't need to know about it. Is that not the same in C++ and in most languages? ... until someone else in your team uses it in your code base. And then you need to know about it in Rust as well.
The difference is that with rusts safety you can to some degree "try thinks out". Which doesn't work with C++ as you might have hidden UB.
Also C++ has a bunch of "hidden" features and unexpected interactions with other features and UB like e.g. forward guarantee because of which `while(1);` is UB.
Re: Monads and GATs in Nightly Rust
#93Too many cooks spoil the broth
I want a language designed by one very smart person, a dictator. I'm looking forward to Jai but for now the best native language is still C++. It also has too many features like Rust but at least it works.
Re: Monads and GATs in Nightly Rust
#94GAT = Generic Associated Type
Thank you. The article doesn’t unpack the initialism, and the author just links to a Rust Playpen (or whatever) site which supposedly uses this three-word thing.
Re: Monads and GATs in Nightly Rust
#95It seems that Rust just keeps getting more and more features. Do people generally feel like the more features the better the language? I'm personally of the opinion that less is more. Is this a pain point at the moment for Rust devs? Do you feel like the code you write is the same code 99% of other Rust developers would write to solve the same problem? Or is there actually a really large variety of styles?
As someone who uses Rust, "more features" is not a win. Most of the time it rarely impacts me - especially in Rust it seems that a "Box" here or there can fix code at the potential cost of performance.
But there are cases, often for libraries, where features can be quite helpful and make me faster. If a feature is basically "make code that should have already worked actually work", that's a huge win.
A lot of Rust features tend to be that. It's like "OK, we have 'impl trait', but it only works in some places. Let's let it work in more places." So,yeah, sure, that's a new feature - impl trait in new positions - but it's really just supporting code that many people would have expected to work.
I see this GAT feature similarly. It wouldn't be hard to "accidentally" try to have a generic associated type - in fact, I have probably run into this myself. And so GAT isn't really adding more complexity to me, it's just unlocking code that I would have already written.
Similarly, with GAT, we can unlock 'async' in traits. I already know 'async', I know it on functions and methods. So this is, again, just making an existing feature more consistent.
Re: Monads and GATs in Nightly Rust
#96Earlier quoted context omitted.
Lifetimes do not influence code generation (besides potential specialization on 'static, which I'm not sure if it's a thing). But besides that the amount work is indeed very close by each other. Which is why there is currently no plan to first have lifetime only GATs stable as far as I know.
You're not wrong that they don't influence codegen, but I don't know why you're bringing that up. I don't see the connection. You cannot specialize on lifetimes, it is not sound.
Because to have lifetime only GATs you need to change the syntax and liftime checker but once you checked the type
you can treat it ignoring lifetimes and in turn ignoring the GAT aspect.
But then if you did so you probably already implemented most/all of the code to typecheck non lifetime GATs and then doing the rest proper is probably not to hard either and might be not harder then doing liftime only GATs.
> You cannot specialize on lifetimes, it is not sound.
Good to know, given that specialization was stuck in nightly in the last years I didn't use it and in turn didn't look to much into it.
Re: Monads and GATs in Nightly Rust
#97I saw Scala taken over and destroyed by the FP fanatics who want to turn every language into Haskell. I hope they don't do the same to Rust. Just use Haskell and leave the rest of us alone! It sounds silly but its true.. as you increase the complexity of the language, the hardcore users making the libraries adopt those features, which means users have to adopt those features as well. Pretty soon everyone is talking a…
FP has little to do with real-world programming and not even much to do with computer science. Look through Knuth, Dijkstra, Turing, etc. and find an example of FP--you can't. It's the mentally challenged stepchild of CS for programmers who have developed physics envy (or perhaps more appropriately, string theory envy).
Re: Monads and GATs in Nightly Rust
#98Earlier quoted context omitted.
Your claims are at odds with each other. If the people who are passionate about a language are the ones who pursue its advanced features (and therefore somehow force them on the rest of the world), who then is left to "actually build shit"? Why, if simple functionality is such a strong requirement of productivity, aren't those who stick to simple features productive enough to maintain an ecosystem without the Archite…
> If the people who are passionate about a language are the ones who pursue its advanced features (and therefore somehow force them on the rest of the world), who then is left to "actually build shit"? Some people are passionate about the language itself, and programming language theory in general. Others are passionate about solving whatever particular problem their project solves. A simple thought experiment - thin…
>A simple thought experiment - think about the most widely used libraries and tools across the whole developer ecosystem. How many are built in Haskell? I count maybe one, Pandoc.
Purescript and Elm are two more. If you don't count languages, then Xmonad and Darcs are another two. Both Github and Facebook's efforts in mass source-code searching are written in Haskell (though Facebook's is not really released to the whole developer ecosystem).
This is also a misguided thought experiment - Haskell is relatively unpopular anyways (as Rust is). It has a reputation for being difficult to learn (as Rust does). How many tools across the developer ecosystem are written in Rust? Ripgrep, and maybe Alacritty. Does this reflect badly on Rust? No, it's immature and needs a lot of developer support - which is why much of Rust's development effort is in new libraries.
Does a(n alleged) lack of tools reflect badly on Haskell? No, both because it was for a long time considered an academic language, and because Haskell's great successes have also been outside of the "developer ecosystem" - in webservers, for example.
And none of this addresses my original objection to your point: why, if simplicity is so productive, is it not easy to replace complicated libraries with simpler versions? In Haskell, the answer is that the simpler versions are much less powerful, and the power of advanced languages features is actually a boon for productivity, because encoding your invariants in a good type system saves you work elsewhere. That's the whole benefit of Rust's borrow-checker over C++. There is no real risk of Rust getting "too complicated", because these advanced concepts still let people build shit.
Re: Monads and GATs in Nightly Rust
#99I saw Scala taken over and destroyed by the FP fanatics who want to turn every language into Haskell. I hope they don't do the same to Rust. Just use Haskell and leave the rest of us alone! It sounds silly but its true.. as you increase the complexity of the language, the hardcore users making the libraries adopt those features, which means users have to adopt those features as well. Pretty soon everyone is talking a…
FP has little to do with real-world programming and not even much to do with computer science. Look through Knuth, Dijkstra, Turing, etc. and find an example of FP--you can't. It's the mentally challenged stepchild of CS for programmers who have developed physics envy (or perhaps more appropriately, string theory envy).
> not even much to do with computer science
That is very debatable.
Lambda calculus is a BFD in the subfield of programming languages, which is the topic at hand.
Re: Monads and GATs in Nightly Rust
#100I saw Scala taken over and destroyed by the FP fanatics who want to turn every language into Haskell. I hope they don't do the same to Rust. Just use Haskell and leave the rest of us alone! It sounds silly but its true.. as you increase the complexity of the language, the hardcore users making the libraries adopt those features, which means users have to adopt those features as well. Pretty soon everyone is talking a…
FP has little to do with real-world programming and not even much to do with computer science. Look through Knuth, Dijkstra, Turing, etc. and find an example of FP--you can't. It's the mentally challenged stepchild of CS for programmers who have developed physics envy (or perhaps more appropriately, string theory envy).
I would say that it has a lot to do with CS. Basically there's two equivalent ways to look at computing: as Turing machines or lambda calculus. The first is far more popular as early machines and even our current day hardware is close to this. As machines have become more powerful we can do more useful work using formulation based on function composition. If anything this is a trend. What we don't yet have is common sense/knowledge on how to use it judiciously.