21–30 of 170 posts
... and went bankrupt because of not being able to finding Engineers.
Developers can learn new languages though if a company lets them. (Edited to be less glib. bad habit)
It's not that they're not capable, but some will not want to risk several years of their career to learn it.
> 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? Spe…
Closures are, but functions defined using "fn" syntax cannot capture from the environment. This is a useful feature, and I can see why people would want it, but it was considered ultimately not consistent with Rust's aims to be excellent at the low level. See [1] for more discussion of the tradeoffs and why Rust chose not to include the feature. [1] https://users.rust-lang.org/t/inner-functions-not-closed-ove...
> 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? Spe…
Go also certainly supports this. Here's a playground example: https://play.golang.org/p/_BLguocGBRn
While 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…
I think the author makes it clear that direct conversion from Pascal is the primary goal. I'm guessing that once the codebase is fully transpiled to D, refactoring would be the logical next step.
... and went bankrupt because of not being able to finding Engineers.
Developers can learn new languages though if a company lets them. (Edited to be less glib. bad habit)
Airbnb dropping react native due to a lack of qualified candidates that were articulate in both the native and javascript realm is a great example. Something can work flawlessly with the right conditions (for instance, developers that understand and can implement the path of least resistance across native and react), yet if its prohibitive to create those conditions you are back where you started.
If the dominant ideology among developers is that learning X language or technology costs more of their career than its worth, it dies out. Same goes for the company and their resources.
... and went bankrupt because of not being able to finding Engineers.
The article title is misleading. They still have not migrated.
Earlier quoted context omitted.
Closures are, but functions defined using "fn" syntax cannot capture from the environment. This is a useful feature, and I can see why people would want it, but it was considered ultimately not consistent with Rust's aims to be excellent at the low level. See [1] for more discussion of the tradeoffs and why Rust chose not to include the feature. [1] https://users.rust-lang.org/t/inner-functions-not-closed-ove...
I believe the story here is the same in C++. Functions are just a pointer to some compiled code. Closures are an object that represents all the captured variables, in addition to the code. That object has a size, and a destructor, and the variables it's holding might have pointer lifetimes that you need to worry about. In Rust, quite a lot of type system machinery gets invoked when you create a closure, to make sure…
D has support for nested functions: I love nested functions. It's good when you need a quick local function, and don't want to expose it to the rest of the code base. But, how do you systematically unit test nested functions?
You don't. You test the enclosing function. The nested function is just an implementation detail like any other line of code in that function.
> it will possibly take a year, and probably longer, to migrate to D The article title is misleading. They still have not migrated.
I mean, they have chosen to migrate. That doesn't imply they're done with the implementation.