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

121–130 of 170 posts

Re: How an Engineering Company Chose to Migrate to D

#121

Post by eptcyka »

oconnor663 wrote: post #19
hmottestad wrote: post #12

Earlier quoted context omitted.

Maybe "access to variables" means write access. I know that in Java variables referenced by a lambda need to be final.

Here's a tweak to the Go example above that demonstrates writing: https://play.golang.org/p/H9vCt93Qz2B Here's a Rust version that does the same (without heap allocation!): https://play.rust-lang.org/?gist=bb5406062970b62088d58fb8a9f...

In Rust's case, this becomes far less practical as soon as the closure's return type does not implement the Copy trait.

Re: How an Engineering Company Chose to Migrate to D

#122

Post by abiox »

oblio wrote: post #21
detaro wrote: post #11

Earlier quoted context omitted.

Developers can learn new languages though if a company lets them. (Edited to be less glib. bad habit)

A friend (C# dev) just refused a job from a company in the Netherlands, for a D dev position. I don't know if it's the same company. It's not that they're not capable, but some will not want to risk several years of their career to learn it.

honestly, if i were hiring and heard this of an applicant (and didn't have reason to believe it was something else like salary), i would feel that we dodged a bullet.

(that may not be entirely fair, i guess i just tend to be skeptical of people who get hung up on languages.)

Re: How an Engineering Company Chose to Migrate to D

#123

Post by earenndil »

Keyframe wrote: post #55
kungtotte wrote: post #49

Earlier quoted context omitted.

3) Tooling, ecosystem, and library availablity. Picking language X over Y is unwise if it means spending a bunch of time writing the libraries you need, even if it's ultimately more expressive.

This, turns out, is ultimately the most important thing amongst most important things. I've invested quite a lot of effort and time in D, back when D1 was around and D2 was a newsgroup post. D1 was everything I wanted out of better C, while d2 looked like it ought to be a better c++. Two years into heavy D programming, d2 vs d1+tango vs phobos aside, most of my time was spent in hunting for things or re-inventing thi…

With the existence of d++[1], you can essentially use any existing c or c++ library by simply including its header file.

1: https://github.com/atilaneves/dpp

Re: How an Engineering Company Chose to Migrate to D

#124

Post by earenndil »

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

I wouldn't say go is at all a better c++. It has very different stated goals and a different philosophy. As for d and rust, they improve on c++ in very different ways, just because they're both improvements on c++ doesn't mean they're the same. For example:

* D has generally better metaprogramming, however, rust has real macros

* D has a garbage collector and defaults to code being memory-unsafe. Rust uses ownership semantics and defaults to safe code.

* Rust has only an llvm-based compiler (although possibly moving to a self-hosted one soon?). D has a self-hosted, gcc-based, and llvm-based compiler.

Re: How an Engineering Company Chose to Migrate to D

#125

Post by Keyframe »

earenndil wrote: post #123
Keyframe wrote: post #55

Earlier quoted context omitted.

This, turns out, is ultimately the most important thing amongst most important things. I've invested quite a lot of effort and time in D, back when D1 was around and D2 was a newsgroup post. D1 was everything I wanted out of better C, while d2 looked like it ought to be a better c++. Two years into heavy D programming, d2 vs d1+tango vs phobos aside, most of my time was spent in hunting for things or re-inventing thi…

With the existence of d++[1], you can essentially use any existing c or c++ library by simply including its header file. 1: https://github.com/atilaneves/dpp

While interesting, glancing through readme/limitations just furthers my (view)point based on experience.

Since then, I do by and large dive into new languages but don't use them. What I do is bring back home some of the practices which I think are of benefit to me.

Re: How an Engineering Company Chose to Migrate to D

#126

Post by acehreli »

protocode wrote: post #101
coldtea wrote: post #75

Earlier quoted context omitted.

Actual or imaginary would be a better wording...

I see mostly imaginary. As a back end systems guy for over 20 years, I deal with guys all the time wanting to introduce new tools into the mix that add zero value. There is a reason why *nix tools are still around. There is nothing that Python can do better than awk for grabbing data columns and piping them into some other tool. There is a reason why COBOL still exists, for example, what with its ability to ensure ac…

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.

Re: How an Engineering Company Chose to Migrate to D

#127

Post by lomnakkus »

closeparen wrote: post #73
setr wrote: post #63

Earlier quoted context omitted.

>Depending on the context they can be an ergonomic nice-to-have, but it’s not like you can’t express a program without them. When talking about turing complete languages, everything is an ergonomic nice-to-have. All language features aspire to be so nice to have, that you come back around and call it a necessity. But you can still express a program without them, unless you strip out so much as to lose turing complete…

Right, which is why "requirement" is a silly framing that ascribes a sort of objective engineering necessity embedded in the problem to what is actually an subjective aesthetic choice between solutions. (I'm generally pretty skeptical of the whole "write down your requirements with no awareness of available solutions and then choose a solution that meets them" approach to decision-making).

Why do you find it strange? To me, "requirement" signals that there's some sort of pain threshold for writing/maintaining code that the writer isn't willing to go above. Is there anything weird in that?

> (I'm generally pretty skeptical of the whole "write down your requirements with no awareness of available solutions and then choose a solution that meets them" approach to decision-making).

I also don't understand this. If there's a solution that meets all of the requirements what does it matter what there are other solutions? I mean, yeah, you be doing a local vs. global optimization, but as long it meets the requirements it's probably not a big deal. (The only exception is if the requirements are so broad as to be meaningless, but as long as they're reasonably specific, I don't see the problem.)

Re: How an Engineering Company Chose to Migrate to D

#128

Post by oconnor663 »

eptcyka wrote: post #121
oconnor663 wrote: post #19

Earlier quoted context omitted.

Here's a tweak to the Go example above that demonstrates writing: https://play.golang.org/p/H9vCt93Qz2B Here's a Rust version that does the same (without heap allocation!): https://play.rust-lang.org/?gist=bb5406062970b62088d58fb8a9f...

In Rust's case, this becomes far less practical as soon as the closure's return type does not implement the Copy trait.

Here's an example that does something similar with Vec's: https://play.rust-lang.org/?gist=7a4ed9098a53831195c5189ba9c...

I think the real nastiness happens if you want to have more than one closure over the same variables, when those variables aren't Copy. Because then when you try to `move` them in, the compiler yells at you. At that point you have to resort to putting them in an `Arc` or something like that. But that's par for the course with Rust: the compiler is preventing you from creating multiple mutable references to the same object.

Re: How an Engineering Company Chose to Migrate to D

#129

Post by oblio »

abiox wrote: post #122
oblio wrote: post #21

Earlier quoted context omitted.

A friend (C# dev) just refused a job from a company in the Netherlands, for a D dev position. I don't know if it's the same company. It's not that they're not capable, but some will not want to risk several years of their career to learn it.

honestly, if i were hiring and heard this of an applicant (and didn't have reason to believe it was something else like salary), i would feel that we dodged a bullet. (that may not be entirely fair, i guess i just tend to be skeptical of people who get hung up on languages.)

I don’t agree with you. Provided you’d persuade him that the company and tech are worth it, I think he’d be a good addition to most companies.

It’s a legit concern.

Re: How an Engineering Company Chose to Migrate to D

#130

Post by comex »

kibwen wrote: post #110
_veelo wrote: post #98

Earlier quoted context omitted.

To be frank: I have never used Rust nor Go. Nevertheless, I am quite sure closures and goroutines would complicate the translation due to different syntax from ordinary functions. The same argument is being discussed at reddit https://www.reddit.com/r/programming/comments/8si75b/how_an_...

> I am quite sure closures and goroutines would complicate the translation due to different syntax from ordinary functions. It's unclear where the root of that confidence lies. The translation is just as mechanical in either language as it would be otherwise: see an inner function, replace it with the one thing that can capture variables. Speaking for Rust, it would actually be even easier to do the translation using…

I can see at least two issues. I'm sure you're aware of these, but:

- Rust closures don't really support recursion, at least without serious hacks.

- Rust closures borrow the variables they reference as soon as the closure is created; you can never write to those variables again as long as the closure is alive, and if the closure mutates the variable (resulting in a mutable borrow), you can't read from them either, outside the closure itself.

The latter isn't as a big a deal for some other use cases for closures, but if you want to use them to emulate nested functions, you're probably creating the closure at the beginning of the outer function and keeping it in scope for the whole function; this means that what you can do with mutable variables is severely limited.

Both issues could be worked around if the mechanical translator liberally sprinkled the code with Cell/RefCell – which would also be necessary to deal with pointers in the source language. But the result would be highly unidiomatic and verbose Rust code.

(In any case, I'm not sure I'd have recommended Rust to OP as they claim to put a high priority on fast compile times, but that's a separate issue.)

Post reply on HN