Trying to like Rust
-
> One I ran into tonight is that there's no such thing as a constructor The problem you're describing is not the absence of a constructor but the absence of function overloading. Rust doesn't have constructors, because there's no need for a constructor as a separate function. That said, rust differentiates between function identifiers and struct identifiers, so you can create a function with the same name as the struct and call it. It will look just like a constructor in C++. The reason rust doesn't have overloading is explained here.
But, either way, it lacks the incredibly obviously important means to do convenient and controlled initialization with various parameter combinations in a standardized way. That seems crazy-like to me. It doesn't seem to me that making an exception on overloading just for ctors would be such a huge compromise and would get rid of a raft of repeated silliness in every program.
Explorans limites defectum
-
Your concerns about Rust may be justified (I'm not taking sides!) but I noticed two things: (1)
Dean Roddey wrote:
But of course Rust may never get beyond the interesting idea phase and get seriously used.
Rust is in serious use right now. There is Rust code shipping in Firefox. (2)
Dean Roddey wrote:
And Rust may suffer in other ways from not having any real single driving force.
Rust does have a single corporate backer/driving force: It is Mozilla. Indeed, this is a source of criticism from some quarters since people say that Rust is structured to solve Mozilla's particular issues with C++ in a very large code base. As for "not a glorified scripting", what do you think of Go or D?
Ok, Mozilla is of course an entity, though a fair bit different from one like Microsoft, it seems to me, having a large part of it being a non-profit foundation, and having a lot of community driven input at least as I understand it. Given that Firefox is also Mozilla's I wouldn't count that overly heavily in Rust's favor as being in real use. They'd probably look the other way far more than another company would in terms of issues and such. I mean it obviously proves it's doable, but from what I'm reading once you get beyond the language to practical issues of packaging and large development structures and such that it still is pretty raw. Though sometimes it's hard to tell what info is really accurate and/or up to date. Not yet looked at Go or D, since I just have had the impression that there wouldn't maybe be much of a career path improvement in those directions, though I could be wrong on that. Given my interest in large scale frameworks and such I'd definitely want something that has the same breadth as C++, or close thereto. I'm not sure Go fits that description?
Explorans limites defectum
-
But, either way, it lacks the incredibly obviously important means to do convenient and controlled initialization with various parameter combinations in a standardized way. That seems crazy-like to me. It doesn't seem to me that making an exception on overloading just for ctors would be such a huge compromise and would get rid of a raft of repeated silliness in every program.
Explorans limites defectum
I've been programming in rust since 2016. The number of times I thought "man, having function overloading would be really nice" can be counted on the fingers of one hand. If you have a case where you need overloading and the code looks more readable with overloading, you're welcome to discuss it on the language design forum.
-
I've been programming in rust since 2016. The number of times I thought "man, having function overloading would be really nice" can be counted on the fingers of one hand. If you have a case where you need overloading and the code looks more readable with overloading, you're welcome to discuss it on the language design forum.
Well, it wasn't about actual overloading, but construction. Object (or structure) initialization in Rust seems very weak to me, for the reasons I enumerated in my original post. Obviously we can live without overloading in general. My own CML language doesn't support it in general. But it does support it for constructors, for the same obvious reason that we want a consistent, formalized means for controlled initialization of data structures with variable parameter sets, not a somewhat ad hoc set of mechanisms that are either convenient but unsafe or safe but inconvenient.
Explorans limites defectum
-
Ok, Mozilla is of course an entity, though a fair bit different from one like Microsoft, it seems to me, having a large part of it being a non-profit foundation, and having a lot of community driven input at least as I understand it. Given that Firefox is also Mozilla's I wouldn't count that overly heavily in Rust's favor as being in real use. They'd probably look the other way far more than another company would in terms of issues and such. I mean it obviously proves it's doable, but from what I'm reading once you get beyond the language to practical issues of packaging and large development structures and such that it still is pretty raw. Though sometimes it's hard to tell what info is really accurate and/or up to date. Not yet looked at Go or D, since I just have had the impression that there wouldn't maybe be much of a career path improvement in those directions, though I could be wrong on that. Given my interest in large scale frameworks and such I'd definitely want something that has the same breadth as C++, or close thereto. I'm not sure Go fits that description?
Explorans limites defectum
I should say before I comment further that I'm not a fan of Rust as such but it does look like it has a future to me.
Dean Roddey wrote:
Given that Firefox is also Mozilla's I wouldn't count that overly heavily in Rust's favor as being in real use. They'd probably look the other way far more than another company would in terms of issues and such.
Other way round, surely. I.e. If there's a problem then they can and will fix it. Additionally, Firefox is a heavyweight code base and is surely as real as it gets.
Dean Roddey wrote:
Not yet looked at Go or D, since I just have had the impression that there wouldn't maybe be much of a career path improvement in those directions, though I could be wrong on that. Given my interest in large scale frameworks and such I'd definitely want something that has the same breadth as C++, or close thereto. I'm not sure Go fits that description?
With Go being backed by Google I think it might well have a massive future. Sadly D's future does seem more questionable. I think it has suffered due to not having big time corporate backing like MS, Google, Apple or even Mozilla (in this context at least). I don't claim to be a Go expert but it certainly does seem, as I understand it, to be intended to have the "same breadth as C++" but of course it could depend on what that means in practice for you.
-
I should say before I comment further that I'm not a fan of Rust as such but it does look like it has a future to me.
Dean Roddey wrote:
Given that Firefox is also Mozilla's I wouldn't count that overly heavily in Rust's favor as being in real use. They'd probably look the other way far more than another company would in terms of issues and such.
Other way round, surely. I.e. If there's a problem then they can and will fix it. Additionally, Firefox is a heavyweight code base and is surely as real as it gets.
Dean Roddey wrote:
Not yet looked at Go or D, since I just have had the impression that there wouldn't maybe be much of a career path improvement in those directions, though I could be wrong on that. Given my interest in large scale frameworks and such I'd definitely want something that has the same breadth as C++, or close thereto. I'm not sure Go fits that description?
With Go being backed by Google I think it might well have a massive future. Sadly D's future does seem more questionable. I think it has suffered due to not having big time corporate backing like MS, Google, Apple or even Mozilla (in this context at least). I don't claim to be a Go expert but it certainly does seem, as I understand it, to be intended to have the "same breadth as C++" but of course it could depend on what that means in practice for you.
I dunno. I think that, if you really want to use something, you'll overlook a lot of 'beauty marks'. I imagine that they would do that because they want to use it. Obviously they would fix anything causes bugs, but things that might make it less practical for real use (which may be things well outside the language itself such as packaging, build schemes, tools integration, whatever, and obviously ongoing changes to the language) they might well very much give the benefit of the doubt that it will get taken care of and put in the work to get around it, whereas another company wouldn't commit until after those things are taken care of in most cases because they can't afford to do otherwise. There's a huge chicken and egg thing all around. I wouldn't commit to learning a language like Go or Rust (meaning seriously, not just poking around) unless I knew there was a substantial likelihood it would benefit me career-wise (which translates to there are lots of jobs doing it) but there won't likely be lots of jobs doing it unless companies believe that there is a large talent pool out there to draw from.) And of course with Go there's the problem that Google drops projects right and left all the time and a lot of people wouldn't want to commit themselves to anything that fundamentally if it comes from Google because they could get seriously screwed. And I imagine a fair number of folks don't want to contribute any more to Google's hold on the industry (and the world.)
Explorans limites defectum
-
So I've been giving myself a double dose of pain trying to learn both Linux and Rust together on the side. Rust has some interesting ideas, but man some of the stuff just seems crazy to me. One I ran into tonight is that there's no such thing as a constructor. You can create a method to gen up a structure instance and return it, but there's no overloading at all. So if you wanted to allow different sets of parameters (enormously likely and sometime quite a few) you'd have to have differently named methods for every variation which would get really awkward. Of course you can just make all the members public and let everyone directly set them without any constraint using the {} type initialization, which is a complete NO in almost all cases in any sane world, and utterly bizarre for a language that is so otherwise anal retentive. Or, you can use the 'builder pattern' which is the most convoluted way of constructing a structure of all and I can't imagine why anyone would want to do it (see the Builder Pattern section.) Method Syntax[^] I mean, it's like they are trying so hard not to be C++ that they really are making some of the most obvious stuff way harder than it needs to be. I mean, come on, a single exception to support some sort of constructor concept and to maybe make an exception on overloading for that? Or even allow you to do a 'post validation' after a 'direct member' type initialization or something, to check for constraint violation. Or just provide a way to map a direct initialization with a given set of values provided to a method that will handle it for validation and defaulting of unprovided values (which may be different depending on the particular set of provided values, so a single fixed value isn't sufficient necessarily.) Ultimately I'm not sure why I'm bothering since there's probably fewer Rust jobs out there than women who want to sleep with me. But I'm trying to broaden my horizons and the way C++ is going is getting scarier and scarier to me, with people now claiming that using OOP is a dangerous and outdated practice and can't possibly work (despite the fact that it's been used for decades.) I don't want to be around to suffer through all these people re-living the 80s and finally coming out the other side a decade later finally realizing why software development back then sucked. So having
BTW, while I'm whining... Who made the choice not to use an explicit return statement? That seems particularly non-optimal. There's absolutely no visual difference between the last statement falling out the bottom and an incomplete line of code just from looking at it. I mean readability is far more important than saving a few characters.
Explorans limites defectum
-
So I've been giving myself a double dose of pain trying to learn both Linux and Rust together on the side. Rust has some interesting ideas, but man some of the stuff just seems crazy to me. One I ran into tonight is that there's no such thing as a constructor. You can create a method to gen up a structure instance and return it, but there's no overloading at all. So if you wanted to allow different sets of parameters (enormously likely and sometime quite a few) you'd have to have differently named methods for every variation which would get really awkward. Of course you can just make all the members public and let everyone directly set them without any constraint using the {} type initialization, which is a complete NO in almost all cases in any sane world, and utterly bizarre for a language that is so otherwise anal retentive. Or, you can use the 'builder pattern' which is the most convoluted way of constructing a structure of all and I can't imagine why anyone would want to do it (see the Builder Pattern section.) Method Syntax[^] I mean, it's like they are trying so hard not to be C++ that they really are making some of the most obvious stuff way harder than it needs to be. I mean, come on, a single exception to support some sort of constructor concept and to maybe make an exception on overloading for that? Or even allow you to do a 'post validation' after a 'direct member' type initialization or something, to check for constraint violation. Or just provide a way to map a direct initialization with a given set of values provided to a method that will handle it for validation and defaulting of unprovided values (which may be different depending on the particular set of provided values, so a single fixed value isn't sufficient necessarily.) Ultimately I'm not sure why I'm bothering since there's probably fewer Rust jobs out there than women who want to sleep with me. But I'm trying to broaden my horizons and the way C++ is going is getting scarier and scarier to me, with people now claiming that using OOP is a dangerous and outdated practice and can't possibly work (despite the fact that it's been used for decades.) I don't want to be around to suffer through all these people re-living the 80s and finally coming out the other side a decade later finally realizing why software development back then sucked. So having
-
So I've been giving myself a double dose of pain trying to learn both Linux and Rust together on the side. Rust has some interesting ideas, but man some of the stuff just seems crazy to me. One I ran into tonight is that there's no such thing as a constructor. You can create a method to gen up a structure instance and return it, but there's no overloading at all. So if you wanted to allow different sets of parameters (enormously likely and sometime quite a few) you'd have to have differently named methods for every variation which would get really awkward. Of course you can just make all the members public and let everyone directly set them without any constraint using the {} type initialization, which is a complete NO in almost all cases in any sane world, and utterly bizarre for a language that is so otherwise anal retentive. Or, you can use the 'builder pattern' which is the most convoluted way of constructing a structure of all and I can't imagine why anyone would want to do it (see the Builder Pattern section.) Method Syntax[^] I mean, it's like they are trying so hard not to be C++ that they really are making some of the most obvious stuff way harder than it needs to be. I mean, come on, a single exception to support some sort of constructor concept and to maybe make an exception on overloading for that? Or even allow you to do a 'post validation' after a 'direct member' type initialization or something, to check for constraint violation. Or just provide a way to map a direct initialization with a given set of values provided to a method that will handle it for validation and defaulting of unprovided values (which may be different depending on the particular set of provided values, so a single fixed value isn't sufficient necessarily.) Ultimately I'm not sure why I'm bothering since there's probably fewer Rust jobs out there than women who want to sleep with me. But I'm trying to broaden my horizons and the way C++ is going is getting scarier and scarier to me, with people now claiming that using OOP is a dangerous and outdated practice and can't possibly work (despite the fact that it's been used for decades.) I don't want to be around to suffer through all these people re-living the 80s and finally coming out the other side a decade later finally realizing why software development back then sucked. So having
Things have moved on quite a bit since you wrote this. It has become a thing, with most of [Big Tech](https://foundation.rust-lang.org/members/) backing it and now using it a lot. Even Google with Go sees a need for it. They will be using it in Android, for example.
Kevin
-
Things have moved on quite a bit since you wrote this. It has become a thing, with most of [Big Tech](https://foundation.rust-lang.org/members/) backing it and now using it a lot. Even Google with Go sees a need for it. They will be using it in Android, for example.
Kevin
Actually I've dug into it quite a lot since then, and the more I use it the more I'm gravitating away from it. I get it of course. The memory safety is a huge, almost overriding benefit. But I just hope that these ideas get incorporated into a language I like better on the whole.
Explorans limites defectum