Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How an Engineering Company Chose to Migrate to D

dlang.org

Post reply on HN
Print view View original

141–150 of 170 posts

Re: How an Engineering Company Chose to Migrate to D

#141

Post by AndrewSChapman »

abiox wrote: post #119
oh-kumudo wrote: post #85

How do they plan to solve the hiring problem? I am curious.

if you mean "hiring d programmers", i think it's somewhat of a nonissue. afaik d isn't particularly esoteric, so any new hire should be able to get up to speed quickly.

I'm not so sure about that. For the basics that's definitely true, and no doubt if you're a C++ programmer then it will be an easier transition, but if you're coming from a higher level language like Java, C#, PHP etc then there's a lot to get your head around. That said, it's absolutely worth it :-)

Re: How an Engineering Company Chose to Migrate to D

#142

Post by WalterBright »

steveklabnik wrote: post #138
tikue_ wrote: post #137

Earlier quoted context omitted.

At least in Rust, capture granularity is per-variable, so I think closures don't contain a stack frame pointer? Though, I'm not sure why this would matter to a user evaluating Rust's closures vs. D's nested fns?

It’s a pointer to the environment, and a pointer to the function. So yes, not a stack frame pointer. The environment is a struct containing what is captured; so for example, it would contain an &T if your closure captures a T by reference. You don’t need to walk a set of stack pointers to find it, just follow the reference directly there.

That's distinctly different from D's, which has a pointer to the enclosing stack frame.

If it is the enclosing function, it's just a single pointer to it. The "walking" comes from if you're accessing the enclosing function's enclosing function's frame.

Re: How an Engineering Company Chose to Migrate to D

#143

Post by arunc »

Const-me wrote: post #120

I’m surprised to see a lot of criticism in the comments. Generally, I prefer mainstream languages myself, that’s why I mostly code C++ and C#. But “generally” is the key here. For some projects, or some parts of it, picking a non-mainstream language can be a huge win in terms of productivity. I never used D in production, but I can remember several occasions where I picked unusual languages, both specialized and gene…

> I’m surprised to see a lot of criticism in the comments.

I'm not surprised to see criticism for D on HN. While reading HN comments on posts related to D, I've always found pro Rust/Go comments.

Re: How an Engineering Company Chose to Migrate to D

#144

Post by arunc »

baybal2 wrote: post #66

All Rust, D and Go pass as "better C++" To me, the evaluation goes solely as ecosystem vs. ecosystem There D is ahead not so much by number of features, than by lack of showstopper flaws

Personally/Syntactically I've found that coding in D is much pleasant than C++. Consistent '.' operator for the equivalent '.' '->' '::' in C++, template meta programming for humans, modules, UFCS, etc, etc.

But a killer feature that's available in C++, but not available in D is pure RAII idiom. Sure D does scoped destruction (via struct's destructor), but is in no way equal to the contructor+destructor combination in C++. struct's in D don't have default constructor, so RAII in D is just incomplete.

Automem[1] is a boon for D, but is useful only for heap memory resource. Not for all kinds of resources (like locks, etc).

On the other hand D has scope exit/failure, which is not available in C++.

[1] https://dlang.org/blog/2017/04/28/automem-hands-free-raii-fo...

Re: How an Engineering Company Chose to Migrate to D

#145

Post by steveklabnik »

WalterBright wrote: post #142
steveklabnik wrote: post #138

Earlier quoted context omitted.

It’s a pointer to the environment, and a pointer to the function. So yes, not a stack frame pointer. The environment is a struct containing what is captured; so for example, it would contain an &T if your closure captures a T by reference. You don’t need to walk a set of stack pointers to find it, just follow the reference directly there.

That's distinctly different from D's, which has a pointer to the enclosing stack frame. If it is the enclosing function, it's just a single pointer to it. The "walking" comes from if you're accessing the enclosing function's enclosing function's frame.

Makes perfect sense, thanks. I’m now wondering about the trade offs of these two approaches...

Re: How an Engineering Company Chose to Migrate to D

#146

Post by scj »

blub wrote: post #135
scj wrote: post #118

Earlier quoted context omitted.

Hello, I assume by your username that you're the author! Transpiling is normally a little risky. Transpiling with a custom transpiler over ~500KLOC is downright terrifying. I'd be concerned that the cure is worse than the disease. I understand the allure of this solution. Bringing 30ish years of code into the modern era with a single piece of code sounds like a huge win. But you owe it to your employer (who seems rea…

Python has two big issues: performance and dynamic typing. The solution of using a HLL and dropping down to C for performance strikes me as overly optimistic: the only language where one can legitimately claim that it's pleasant to use C for extra performance is Objective-C. Anything else will be different degrees of painful. I didn't get the solution of using a dynamic lib and calling/extending that from Python. One…

I think there is an understanding that the whole situation is less than ideal. I'm proposing a low risk method to transition from the current situation to a healthy one over the long term.

Having binary compatibility with the old version would be a great safety net while transitioning to another language. The main weakness of the author's plan, as the article explains it, is that they will be dealing with a lot of newly generated code at once (as well as an unknown number of unknowns). The plan would be fine if it was only ~10kloc, but ~500kloc is a very different beast!

Come to think about it... It would be wise to have a "Plan B" still written in D, but linked to the binary rather than transpiled. That way if anything goes wrong after deployment, users can temporarily use that rather than revert to Extended Pascal.

There probably isn't an easy solution for this problem. But maybe the author has found a silver bullet.

I brought up Python because it sounds like SARC is adjacent to scientific computing, and it is likely they'd be able to pick up physics/math/engineering majors that are already familiar with Python. Plus, I bet they'd be able to use some really good Python libraries (possibly replacing some of that 500kloc custom code with open source libraries).

The article makes it clear that naval architects (who are not expected to learn C++) are programming, so I doubt high performance computing is required in 100% of the code (at least I hope not). If there are genuine performance issues, tools alone won't save you, you need to hire programmers that know how to optimize (and they'll be fine writing C/C++ libraries with interfaces to Python).

I strongly suspect the justification that interpreted languages don't meet performance requirements is more ideological than empirical.

Besides, it's likely the existing binary will run faster than its transpiled descendant!

Re: How an Engineering Company Chose to Migrate to D

#147

Post by david-cako »

macintux wrote: post #41
david-cako wrote: post #25

Earlier quoted context omitted.

I agree, but that costs money for the company and time for the developer. 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 c…

I'm skeptical about extrapolating too much from a JavaScript example. That ecosystem looks nothing like the rest of the software development world. Erlang has been around in a niche role for >30 years and still going strong, even stronger now that Elixir has reinvigorated interest in the platform.

My only point in that you should be as careful about creating problems building a team and adding ramp-up time to your product when you attempt to optimize. It's a decision that doesn't go away without lots of heartburn and having employees lose morale rewriting their own work.

Re: How an Engineering Company Chose to Migrate to D

#149

Post by pjmlp »

protocode wrote: post #134
acehreli wrote: post #126

Earlier quoted context omitted.

You never said "C" but perhaps you think there is "a reason" why C still exists too. The only reason ineffective tools like C exist is because there are people at the other extreme from those kids: Not take any risk but stick with tried and wrong tools.

C still has it's place. It's not glamorous, but it works. COBOL has no decent replacements. Yet. Some have tried. Almost all have failed. Old does not mean useless. If it works, then it's not wrong.

On UNIX clones and embedded developers that won't take anything else even at point gun.

.NET, Java are good COBOL replacements.

http://www.fujitsu.com/global/products/software/developer-to...

https://www.microfocus.com/products/visual-cobol/

Re: How an Engineering Company Chose to Migrate to D

#150

Post by pjmlp »

scj wrote: post #146
blub wrote: post #135

Earlier quoted context omitted.

Python has two big issues: performance and dynamic typing. The solution of using a HLL and dropping down to C for performance strikes me as overly optimistic: the only language where one can legitimately claim that it's pleasant to use C for extra performance is Objective-C. Anything else will be different degrees of painful. I didn't get the solution of using a dynamic lib and calling/extending that from Python. One…

I think there is an understanding that the whole situation is less than ideal. I'm proposing a low risk method to transition from the current situation to a healthy one over the long term. Having binary compatibility with the old version would be a great safety net while transitioning to another language. The main weakness of the author's plan, as the article explains it, is that they will be dealing with a lot of ne…

> I strongly suspect the justification that interpreted languages don't meet performance requirements is more ideological than empirical.

Nope, it is based on production code life experience and seeing everything crumble with high CPU usage for little work being delivered.

Any programming language without a JIT or AOT as part of their default toolchain is not worth using for anything besides scripting.

> Besides, it's likely the existing binary will run faster than its transpiled descendant!

Given how old Extended Pascal compilers are and that D has three backends, two of them based on GCC and LLVM respectively, I pretty much doubt it.

Post reply on HN