Trying to like Rust
-
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
On Slant a lot of people seem to like it for backend development: https://www.slant.co/topics/7812/~programming-language-to-learn-for-backend-developers[^] And systems programming: https://www.slant.co/topics/6032/~systems-programming-languages[^] But often these sites seem to be overpopulated with strange people that seem to prefer LISP style languages. :~
-
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
In my limited experience, the people that don't like OO are the same type that don't like SQL. Or if you don't understand it, there is something wrong with the concept. Instead of realizing it might be the other way around. Or, if your only tool is a hammer... And as always, one should use the right tool for the job. But when looking at all different programming languages around, one realizes there are many shapes to a hammer.
Wrong is evil and must be defeated. - Jeff Ello
-
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
tl;dr I'll be honest, I only read your title, and I thought, with a name like that, who would like Rust? I just spent nearly $2K last year to get rust dealt with and my car repainted. Who picked that name anyway? Does "rust" ever have positive connotations?
-
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
If you have to try to like it why bother.
I do all my own stunts, but never intentionally! JaxCoder.com
-
If you have to try to like it why bother.
I do all my own stunts, but never intentionally! JaxCoder.com
Well, some things are acquired tastes, I'm sure we can all come up with one in particular. But it's also just to get my head around some very different sorts of concepts, and it does have some very different ideas relative to C++.
Explorans limites defectum
-
In my limited experience, the people that don't like OO are the same type that don't like SQL. Or if you don't understand it, there is something wrong with the concept. Instead of realizing it might be the other way around. Or, if your only tool is a hammer... And as always, one should use the right tool for the job. But when looking at all different programming languages around, one realizes there are many shapes to a hammer.
Wrong is evil and must be defeated. - Jeff Ello
Jörgen Andersson wrote:
In my limited experience, the people that don't like OO are the same type that don't like SQL.
In my extensive experience the people who like OO don't like SQL. But to be fair been a very long time since I have even been around anyone that could even express an opinion about non-OO programming. The OO folks do like No-SQL and specifically MongoDBt. Of course they still can't get that right and then I have to support it even though it is often a poor solution.
-
Jörgen Andersson wrote:
In my limited experience, the people that don't like OO are the same type that don't like SQL.
In my extensive experience the people who like OO don't like SQL. But to be fair been a very long time since I have even been around anyone that could even express an opinion about non-OO programming. The OO folks do like No-SQL and specifically MongoDBt. Of course they still can't get that right and then I have to support it even though it is often a poor solution.
I wrote same type of people, not necessarily the same people. The point I tried to convey was that, just because you don't understand it doesn't mean it's wrong.
Wrong is evil and must be defeated. - Jeff Ello
-
Well, some things are acquired tastes, I'm sure we can all come up with one in particular. But it's also just to get my head around some very different sorts of concepts, and it does have some very different ideas relative to C++.
Explorans limites defectum
Agreed, every language has a purpose Pl1, APL, Fortran, etc. I use C and C++ a lot for my embedded stuff. I actually looked at rust a while back and didn't spend the effort.
I do all my own stunts, but never intentionally! JaxCoder.com
-
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
Dean Roddey wrote:
C# is still (despite a lot of efforts) quite Windows oriented
You are kidding, right? C# compiles and runs fine for Linux, iOS, Android, MacOS, and now, WebAssembly. With .NET Core and targeting .NET Standard, cross-platform is a reality.
-
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
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?
-
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
> 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.
-
Dean Roddey wrote:
C# is still (despite a lot of efforts) quite Windows oriented
You are kidding, right? C# compiles and runs fine for Linux, iOS, Android, MacOS, and now, WebAssembly. With .NET Core and targeting .NET Standard, cross-platform is a reality.
Oh, sure, but the reality is what is widely available in terms of jobs, not what is technically doable. The vast bulk of .Net jobs are going to be on the Windows front, at least the ones I've seen. The place where obviously that may (if we are lucky) really change is on the browser with Blazor/WASM. But I'm not much interested in writing browser based code, or writing trivial phone apps either. I'm helping someone with a Blazor based product currently, and it has a lot of promise, or at least as much as anything that runs in a browser and is still fundamentally stuck with HTML/CSS can be. And he is using that combination in hopes of supporting multiple platforms, but only in a browser based context, and the back end is all Windows.
Explorans limites defectum
-
> 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
