11–20 of 90 posts
Earlier quoted context omitted.
I was under the impression that `Option ` and `Result ` were monads.
Yes but the Rust type system cannot express monads, so they aren't monads in the type sense (they don't implement a specific Monad trait).
1: The program that proved this no longer compiles, so we're not sure if the type system is or is not at the moment.
Additionally, the C++ example doesn't produce the same output ("Value: (x: 7)" and "Value: (x: 5, y: 10)"). The addition of that goal might lead the programmer to treat the C++ version of print_me as something more abstract, accepting a string and having class Foo and class Bar simply return their own string representations.
I acknowledge that the premise was "a beginner C++ developer", getting hyped up about inheritance and using it as the only tool in their toolbelt, but how many people are learning C++ as a first language these days? It used to be the norm, back in the OO-will-save-us-all heydey, but has anyone run into it lately?
Earlier quoted context omitted.
> In this regards, Rust is actually the Blub I'm not so sure. We are aware of the features that they have; we just prefer the strongly-typed versions to the stringly-typed[1] versions. We do desire more meta-programming features, and they will happen. Like all decisions, we don't want to rush into them. 1: This is not _entirely_ accurate, but I'm slightly at a loss for how to exactly characterize this at this particu…
The last statement was more in regards to the Blub definition implied by the article. Of course, people who are immersed in programming language theory are not Blub programmers - they are aware of what is possible, but are also aware of the inherent tradeoffs. With regards to Rust, do you have any idea when more meta-programming features like variadics and non-type template parameters might be available in the langua…
It's hard to say because the work for those features hasn't even been started; the MIR refactoring is still underway. Once that's done, RFCs for this stuff will start to appear, and we'll have a better idea of overall schedule. I would say that the current schedule is "longer than months, shorter than a few years".
I myself _really_ want higher kinded types, but at the same time, I would rather wait and do it right than rush and regret thing slater. We have a solid language as it is; the need to get these more advanced features is not particularly urgent, in my opinion. I like to think on the long scale when it comes to the language: if it's going to be around 40 or 50 years, we're in year one. There's plenty of time.
And there it is. I programmed in C++ long enough to "know" this, but I still remember more jr. Engineers and even arguments with more sr. Engineers around this type of question.
Rust has removed this kind of question almost entirely from the language.
Personally, I have no intention of ever going back to C/C++ for any new project I work on.
I think "blub" is relative. I look at people who think that cluttering code with boilerplate for error handling, and even those who think that boilerplate is sufficient is sufficiently papered over using macros, have yet to understand why exceptions are interesting or (often) how to use them correctly (as many uses of exceptions that people like to poke at are entrenched wrongness, much like how many people who hate…
I would be very interested in a blog post on this.
I haven't written C++ with any significance in a few years, and done little with Rust at all. So while I don't feel qualified to speak to the comparison at the core of the blog post, I did find the first example to be disingenuous. It rests entirely on assuming the C++ programmer will rely on inheritance to achieve polymorphism, simply because they can? Additionally, the C++ example doesn't produce the same output ("…
edit: It's worth the down votes on this. Multiple inheritance is pure evil and confusion. In fact, even in Java I now rely on aggregation over inheritance.
http://stackoverflow.com/questions/269496/inheritance-vs-agg...
"No, you don't have to learn monads." Ha! This is ironic because a present discussion over some syntactic sugar (maybe more) to make Rust error handling feel more part of the language and more ergonamic may be ad-hoc monads. Not that the programmer needs to know that - it's just something that should happen to play nice in the rest of the Rust type ecosystem
I was under the impression that `Option ` and `Result ` were monads.
I think "blub" is relative. I look at people who think that cluttering code with boilerplate for error handling, and even those who think that boilerplate is sufficient is sufficiently papered over using macros, have yet to understand why exceptions are interesting or (often) how to use them correctly (as many uses of exceptions that people like to poke at are entrenched wrongness, much like how many people who hate…
> I have spent a lot of time studying error handling and even now have a sort of "theory of errors" that I will sometimes draw out for people on a blackboard I would be very interested in a blog post on this.
I think "blub" is relative. I look at people who think that cluttering code with boilerplate for error handling, and even those who think that boilerplate is sufficient is sufficiently papered over using macros, have yet to understand why exceptions are interesting or (often) how to use them correctly (as many uses of exceptions that people like to poke at are entrenched wrongness, much like how many people who hate…