How an Engineering Company Chose to Migrate to D
1–10 of 170 posts
Re: How an Engineering Company Chose to Migrate to D
#2Just what we need, another programming language
Re: How an Engineering Company Chose to Migrate to D
#3very impressive and ambitious project
Re: How an Engineering Company Chose to Migrate to D
#4Go did have closure support, where you can assign functions to normal variables and move them around, just like any other primitive data type.
While variables which were declared prior to it in its outer function were available to its inner functions.
Re: How an Engineering Company Chose to Migrate to D
#5Maybe I am too timid, but the closing word saying that once the transpiler is ready they could switch overnight seems a bit optimistic.
I feel that splitting as much as possible the project into chunks/components and then replacing them one by one sounds more realistic (with the appropriate test harness). Maybe that is the plan but it is not touched in the post.
And then maybe an issue that is not that bad, but you are going to have a hard time comparing old_codebase with new_codebase once you've switched. If you have to maintain old branches, porting the fix to recent branches will be more time consuming that simply do a merge.
Re: How an Engineering Company Chose to Migrate to D
#6Go did have closure support, where you can assign functions to normal variables and move them around, just like any other primitive data type. While variables which were declared prior to it in its outer function were available to its inner functions.
Yes, I believe both Rust and for sure Go support closures that can capture enclosing scoped variables.
Unless there is an obvious example of where this breaks down in Go and Rust, I’d certainly like to know how.
Re: How an Engineering Company Chose to Migrate to D
#7While the article states that other languages were evaluated, it seems as though the project was motivated entirely by the author and the evaluation was just paying lip service to what was basically a foregone conclusion. Don't get me wrong, I like D from the small amount of playing I've done with it -- and maybe it is the best tool for their purposes -- but this doesn't strike me as an impartial evaluation.
The need for nested functions bugged me as well. That seems like an odd deal-breaker and hints at code smell, rather than a genuine technical need. If it's just for the sake of one-to-one transpilation, then I can see the point, but a refactoring exercise seems like a better effort to make than language migration. (Also, don't Rust and Go have closures? Surely that would satisfy this requirement.)
Re: How an Engineering Company Chose to Migrate to D
#8Go did have closure support, where you can assign functions to normal variables and move them around, just like any other primitive data type. While variables which were declared prior to it in its outer function were available to its inner functions.
Not directly related, but maybe the lack of genetics in go was a dealbreaker?
Also I inagine the qt bindings are better in D.
Re: How an Engineering Company Chose to Migrate to D
#9... and went bankrupt because of not being able to finding Engineers.
Re: How an Engineering Company Chose to Migrate to D
#10> Nowadays, whenever D is publicly evaluated, the younger languages Go and Rust are often brought up as alternatives. Here, we need not go into an in-depth comparison of these languages because both Rust and Go lack one feature that we rely on heavily: nested functions with access to variables in their enclosing scope.
Maybe I've misunderstood, but aren't Rust's closures [1] exactly what the author is describing? Specifically, you can capture variables from the environment into functions.
[1] https://doc.rust-lang.org/book/first-edition/closures.html