How an Engineering Company Chose to Migrate to D

https://dlang.org/blog/2018/06/20/how-an-engineering-company-chose-to-migrate-to-d/

by pjmlp • 8 years ago

210 156 8 years ago

liveoneggs• 8 years ago

very impressive and ambitious project

nilsocket• 8 years ago

Go 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.

deckarep• 8 years ago

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.

NegativeLatency• 8 years ago

Not directly related, but maybe the lack of genetics in go was a dealbreaker?

Also I inagine the qt bindings are better in D.

seren• 8 years ago

Maybe 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.

smt88• 8 years ago

I think "a bit optimistic" doesn't go far enough. Even some excellent transpilers need manual intervention, and most transpilers I've used have weird edge cases that you can only catch through thorough unit testing.

It sounds like the author has never transpiled a large code base into D before.

Skunkleton2• 8 years ago

For real. It is hard enough to port a project between compilers for the _same_ language, let alone transpiling to a different language.

trishume• 8 years ago

There is precedent for this, even within D. The DMD compiler was originally written in C, and someone went to the effort to write a C to D transpiler, worked on it until it was flawless, then ran it overnight and did the transition all at once: https://github.com/dlang/dmd/pull/4923

I think the Go compiler did something similar.

It certainly requires iteration of continuously attempting the translation until it works, and fixing bugs either in the transpiler or in the original codebase. But once everything seems to be in order, you can do the transition all at once.

WalterBright10• 8 years ago

Daniel Murphy is the one who wrote the translator.

atombender• 8 years ago

The original c2go Go transpiler used to transform the original C compiler to Go wasn't able to produce identically-behaving code, last I heard. It required manual editing. It's no longer maintained, but the fork [1] is much more ambitious, and aims to produce compilable, working programs.

[1] https://github.com/elliotchance/c2go

Xophmeister• 8 years ago

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 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.)

Cyph0n• 8 years ago

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.

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.

_veelo6• 8 years ago

Confirmed.

philjohn• 8 years ago

The biggest problem is they have engineers who have turned their hands to programming, one would expect, without the formal training and so have latched onto various antipatterns without knowing any better because Pascal allowed them to get away with it - painting themselves into a corner.

He mentioned an awful lot of code that would have to be refactored, and it could be that they are just too far down the rabbit hole to get themselves out.

fsloth• 8 years ago

I have a hunch the majority of domain specific engineering products are at least initially implemented by engineers of the domain and not software engineers.

walshemj4• 8 years ago

Very strange in a hardcore technical programming context, I would have thought they would have used Fortran which is still being actively developed.

I have never seen a reasoned argument why C++ vs Fortran is better for technical programming.

scj4• 8 years ago

In this case, I'd look into compiling the existing code into .dll/.so files, and just linking between Extended Pascal and ${NEW_LANGUAGE}. Then, convert the code to ${NEW_LANGUAGE} as needed, if needed.

That solution is probably the lowest cost / safest course... Assuming the Extended Pascal compiler they have supports it.

But I suspect choosing D was a fait accompli.

noir_lord• 8 years ago

Given they started in the 80's Pascal probably has fewer corners to paint oneself into then many languages then (and now probably).

52-6F-62• 8 years ago

To be fair, I work with a large number of formally trained engineers who commit far worse in terms of anti-pattern and data hygiene infractions on the regular and I’ve had the fortune of refactoring their messes.

I don’t think it’s solely dependent on having afforded formal training.

Knowing enough to know that you might not know and just might need to measure or look something up and caring enough to do so is more of the core of it.

burntsushi• 8 years ago

(Also, don't Rust and Go have closures? Surely that would satisfy this requirement.)

Indeed they do. It's completely unclear why they don't satisfy the OP's requirement.

_veelo6• 8 years ago

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_...

robocat• 8 years ago

From: https://www.reddit.com/r/programming/comments/8si75b/comment...

"In Rust, only lambdas (unnamed functions) can be closures".

The OP's post seems to show they didn't spend much time understanding whether Go closures could serve their need. Although from my own superficial understanding, D is "closer" to Pascal than Go.

pjmlp7• 8 years ago

Well Microsoft deemed they are still relevant enough to add them to C# 7.

Volt• 8 years ago

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.

Now you understand how all of these "How we chose this language" writeups work.

ssdd• 8 years ago

Yeah, almost all the time its the inclination of an individual towards a new language that becomes the driving factor of migration rather than the actual shortcoming of current language.

closeparen2• 8 years ago

Framing closures as a “requirement” is pretty strange. 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.

setr• 8 years ago

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 completeness.

WalterBright10• 8 years ago

A language with only goto and call statements can express any program, too. It's not unreasonable to require higher level programming constructs, because such make programming faster and less prone to error.

zombinedev• 8 years ago

If you have a half million codebase that you need to migrate, I would say that every heavily used Extended Pascal feature is required to be easily translatable. If it's simply possible but the translation is not direct or easy, then the maintainers may be better off staying with Ext Pascal than maintaing a half million uglified code base.

lambda• 8 years ago

Yeah, it looks like the author started playing around with D and writing a Pascal to D compiler for the migration, then did the evaluation with a "requirements" list that seems fairly heavily weighted towards D and their approach to translation by doing a simple recursive walk of the Pascal parse tree and outputting equivalent D, then decided to go with what they had already started working on.

Rust does support nested functions that don't close over their environment, and has a separate syntax for closures which do, and closures can either move or borrow their captured variables. This makes it a bit harder to write a translator that produces good, idiomatic results; you could always use a closure that borrows the closed over variables, which I think matches the Pascal semantics, but that would mean the code would look a little odd for cases in which you had a nested function just to factor out some functionality and didn't need the closure.

  fn main() {
      let a = 10;
  
      fn function() {
          println!("Hi!");
          // println!("a is {}", a)
          // fails with:
          //   can't capture dynamic environment in a fn item
          //   use the `|| { ... }` closure form instead
      }
    
      let borrow_closure = || println!("a is: {}", a);
      let move_closure = move || println!("a is still: {}", a);
    
      function();
      borrow_closure();
      move_closure();
  }

WalterBright10• 8 years ago

D nested functions are defined exactly like regular functions, including all attributes, parameter types, etc. There's nothing new to learn.

My experience as a language designer is that syntax matters, and leveraging the users' existing knowledge is worthwhile.

pmarin• 8 years ago

The need for nested functions bugged me as well. That seems like an odd deal-breaker and hints at code smell

Nested functions were a very common pattern on languages like Pascal, Modula or oberon. They are equivalent to code blocks inside a function in C.

_veelo6• 8 years ago

Indeed, it serves encapsulation.

WalterBright10• 8 years ago

The equivalent in C is code blocks connected with gotos. In my conversions of C code to D, I'm able to replace these gotos with nested functions, which makes the code significantly easier to read.

mratsim2• 8 years ago

Given the Pascal history and even consideration of Ada, with the focus on expressiveness and ergonomics I'm surprised that Nim didn't make the shortlist. Nim even has an official Pascal-->Nim converter (called pas2nim) as the very early versions of Nim before bootstrapping were in Delphi.

kamyarg• 8 years ago

... and went bankrupt because of not being able to finding Engineers.

detaro• 8 years ago

Developers can learn new languages though if a company lets them.

(Edited to be less glib. bad habit)

oblio3• 8 years ago

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.

david-cako2• 8 years ago

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 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.

macintux3• 8 years ago

...which is why we’re all still programming COBOL, Fortran, and LISP.

protocode4• 8 years ago

Nothing wrong with the languages you mentioned; they do what they do best. COBOL and Fortran are both fantastic and nothing yet truly replaces them. COBOL is accurate out to 38 digits, which is amazing for such an "old" language. Banks still like their COBOL and it just works. No stupid "libraries and/or frameworks of the month" to worry about, it compiles cleanly and every time, and it's easy to write and maintain. Modern doesn't always mean best. I still write tons of stuff in sh. If it's under 100 lines, it's shell, awk, or similar. COBOL and Fortran still have tons of life left in them. Every time someone undertakes a massive project to replace COBOL in the financial sector (usually driven by a latte-sipping hipster and his recently graduated ilk), it goes pear shaped. We still use hammers. They work.

cpburns2009• 8 years ago

Ideally, the company switching to D wouldn't affect their current or future engineers at all unless some of the engineers are also programmers.

walshemj4• 8 years ago

Just tell your new hires here is a book on the language go learn it - which is what I was told at my first Job (world leading RnD).

oh-kumudo2• 8 years ago

I am usually not against learning new stuff. But I would also like my learning from current work generalize to my future career. From a pragmatic perspective, learning D is probably going to have less ROI.

Either the company focus solely on finding enthusiasts or they pay the premium to overcome this.

acehreli5• 8 years ago

Patently false and disservice to software engineering.

There are many companies (e.g. Weka.IO, Sociomantic, etc.) that hire C++ developers and have them happily write D code. I did work at Weka.IO for a while and never met a single D programmer that was unhappy.

Ali Çehreli

galadran• 8 years ago

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

hmottestad• 8 years ago

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

oconnor6634• 8 years ago

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...

steveklabnik3• 8 years ago

Write access works. https://play.rust-lang.org/?gist=573c941b91657bb0dbac80c33d0...

Once "non-lexical lifetimes" lands, the inner scope won't be necessary. That may have tripped the OP up.

oconnor6634• 8 years ago

Go also certainly supports this. Here's a playground example: https://play.golang.org/p/_BLguocGBRn

codemac• 8 years ago

Does Go take a copy or a reference?

junke• 8 years ago

The only difference I see is if you need recursive local functions, which is harder (but not impossible) to do with anonymous closures.

WalterBright10• 8 years ago

Recursive nested functions in D just work - the hidden parameter to the enclosing frame forms what's called a "static link". A "dynamic link" would be the usual pointer to the previous stack frame (not the enclosing stack frame).

raphlinus2• 8 years ago

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...

oconnor6634• 8 years ago

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 it doesn't outlive any of the references it's closing over.

ben0x539• 8 years ago

The interaction between borrow-checking and closures restricts what else you can do while you have a closure in scope that closes over some variables, so (like many rust features) they aren't a drop-in replacement for their counterpart in other langs.

WalterBright10• 8 years ago

D nested functions don't 'capture' variables from their enclosing scope. They can access them just like other code in the enclosing function.

This is achieved by adding a hidden parameter that is a pointer to the enclosing function's stack frame. This forms a threaded list so variables in nested enclosing functions can be accessed by walking that list.

This is the same way Pascal does it.

It also means that taking the address of a nested function produces a pair - a pointer to the function, and this hidden parameter to the enclosing stack frame.

Rusky• 8 years ago

That's usually what "capture" means when talking about closures.

JdeBP2• 8 years ago

It's the same way that MetaWare implemented nested functions in its C/C++ compiler in the 1980s and 1990s, too. On top of that, MetaWare built iterators and an iterator-driven for mechanism. The yield() in an iterator was actually a nested function callback from the iterator to the body of the invoking for statement, which was turned into a nested function under the covers.

* http://jdebp.info./FGA/metaware-iterator-driven-for.html

In theory, the extra frame pointer mechanisms of the ENTER and LEAVE instructions in the Intel ISA were there for supporting this kind of nested function. MetaWare High C/C++ did not use them, preferring to use a variant calling convention where (if I recall correctly) ECX contained the extra hidden parameter.

blackrock• 8 years ago

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?

coherentpony• 8 years ago

But, how do you systematically unit test nested functions?

You expose it.

If you want to test a local nested function, you test the enclosing function.

maxxxxx• 8 years ago

"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.

EpicEng2• 8 years ago

Why would you need to? If you unit test the top level function then you're implicitly testing anything it does, e.g., use of the local function.

CyberShadow• 8 years ago

But, how do you systematically unit test nested functions?

Why, with nested unittests, of course! Just put them in a nested type first:

  void main()
  {
      static int nested(int x)
      {
          return x * 2;
      }

      struct Test
      {
          unittest
          {
              assert(nested(2) == 4);
          }
      }
  }

Well, OK, that's more of a hack than a feature, and you obviously can't test non-static nested functions (as there'd be no way to give values to the outer function's frame variables). But you asked :)

arunc3• 8 years ago

it will possibly take a year, and probably longer, to migrate to D

The article title is misleading. They still have not migrated.

EpicEng2• 8 years ago

How an Engineering Company Chose to Migrate to D

I mean, they have chosen to migrate. That doesn't imply they're done with the implementation.

seanhunter• 8 years ago

This article seems to ignore two of the most important reasons to choose one language over another. Specifically:

1)Expressiveness in the given problem domain. Some languages are really great in particular niches.

2)Availability of devs. The ability to hire and retain a really great team makes or breaks projects, and while a smart, motivated dev can learn any language, it's definitely a factor in their choice to work or not work with you. If you're in a niche language it will greatly affect the ability of people to use external resources (stackoverflow etc) if they hit blockers and some people will be reluctant to railroad their career into a tech that doesn't appear to be going to the mainstream. On the flipside, if you're lucky you may be able to get really passionate devotees of the language to work for you just to use the language where they might not have done it otherwise.

kungtotte• 8 years ago

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.

Keyframe2• 8 years ago

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 things for weeks which I could've got in minutes with more popular language. Now that I'm older and hopefully wiser, I just go for my standard c toolbelt or, more often, python and be done with whatever I wanted to do without 'the hunt' (often for unmaintened things or things out of my knowledge scope - so I can't even re-implement).

With all that said... Lisp' siren call is still out there, and experience tells me it will be the same. (As it was once before)

walshemj4• 8 years ago

Exactly that's why for CFD Fortran still has so many advantages.

rhacker• 8 years ago

This is definitely key - one startup I worked for was messing around with live voice capture and processing, voice recognition, etc.. by and large the libraries we had access to that could help do tiny manipulations, cutting, processing of the waveform data was primarily C. We wrote most of our code in C++ because we could directly call C functions and use header files directly.

This was 15 years ago, but I honestly don't know what language I would use today. It's funny but sometimes binary data handling isn't a particular language's strong suit simply because they don't have the primitives to handle it, or if they do, the APIs to handle them are awkward or unnecessarily verbose. It's kinda neat that in C/C++ you can take a 1MB byte buffer and pass it to a function starting at 30% in. In other languages its like you have to pass in the whole thing and another parameter to tell it where to start. I get that's why C/C++ is in the situation it's in (security - but that's why I don't use C/C++ to handle web requests), but sometimes tasks need that.

acehreli5• 8 years ago

0) Tool satisfaction

motivated dev can learn any language

The key word is "motivated". That's why I'm an expert user of C++98 and D but I can't learn Go, Python, C++11, etc.

able to get really passionate devotees of the language

That.

mkirklions• 8 years ago

I can't learn Go, Python

I lol'd at this

jecxjo• 8 years ago

I sometimes think people use "availability of devs" to mean "cheap, expendable service". If you're working in an industry where you bank more on hitting the ground running more than retaining developers then this makes sense, and totally valid.

But I've found that lots of places seem to be focused on if you know X rather than being a well versed, developer who enjoys growth. And it feels more and more like the reason is because they don't expect anyone to stay there for more than a few years tops.

cpeterso• 8 years ago

I would have ported the application to Free Pascal 15 years ago when their Extended Pascal compiler vendor went out of business. That's a long time to wait! :)

I'm curious what manual translation and rewriting would be necessary when moving to Free Pascal compared to their Pascal2D transpiler and compatibility library.

AndrewSChapman3• 8 years ago

I would love to be able to use D in my day job. It's a fantastic language that is both powerful and fun to work with. It's great to see companies embracing it.

aydwi• 8 years ago

What is your day job?

AndrewSChapman3• 8 years ago

I work in a small team building APIs with PHP for the real estate industry. In my last job I did manage to use D for a "sequence mining" algorithm that looked for problematic behavioural patterns in web user behaviour. PHP would have been waaay too slow for the quantity of data that needed to be evaluated. That was honestly one of the most enjoyable things I've ever coded.

My hobby project languages or choice are currently D and Kotlin. I prefer the semantics and flexibility of D, but Kotlin has the backings of the tried and tested Java ecosystem, which is hard to beat when you just want to get down to it. Also web servers in Java are vastly superior at the moment. Vert.x is so very fast.

baybal2• 8 years ago

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

mhh__• 8 years ago

Go's lack of generics make it a strange choice to replace C++, philosophically rather than functionally.

earenndil3• 8 years ago

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.

mratsim2• 8 years ago

I don't understand the "D has generally better metaprogramming, however, rust has real macros" statement. Or do you mean like even though Rust allows you to work on AST, it's too clunky compared to D string mixins?

creatornator• 8 years ago

I think you've got the wrong idea on "self-hosted". That just means the compiler is written in the language itself. Rustc is written in rust, so it is self-hosted (even if it has an LLVM backend). And likewise, all three D implementations are written in D, despite having either baked-in code generation, a gcc backend, or an llvm backend. You can check the repos on github: all three of DMD, LDC, and GDC are written in D-lang, so they are self-hosted.

arunc3• 8 years ago

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...

FeepingCreature• 8 years ago

You can disable the default constructor on structs with @disable this(); Then the only proper way to initialize the struct is with its parameterized constructor.

pjmlp7• 8 years ago

I would add Ada and Swift as well.

nautilus12• 8 years ago

I wonder what stage companies people that have the freedom to do these types of explorations work at. I barely have time to work on core components of my system at a deep level. I usually have to leverage existing work and move on

oh-kumudo2• 8 years ago

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

abiox2• 8 years ago

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.

AndrewSChapman3• 8 years ago

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 :-)

dataking2• 8 years ago

Really cool to see companies willing to migrate to a more modern language. I'm part of a team working on C to Rust migration tools (partly inspired by the Corrode translator).

Shameless plug/pre-alpha demo: https://www.c2rust.com

Edit: missing word.

jasonszhao• 8 years ago

Your SSL certificate works in Chrome, but not in my Safari 11.1.1. SSL Shopper (not sure how reliable this is), also shows warnings.

https://www.sslshopper.com/ssl-checker.html

dataking2• 8 years ago

Thanks so much for letting me know; should be fixed now.

Edit: reflect resolved status of issue.

WalterBright10• 8 years ago

A recent article I wrote about converting C code to D:

https://dlang.org/blog/2018/06/11/dasbetterc-converting-make...

xyproto• 8 years ago

[Go lacks] nested functions with access to variables in their enclosing scope

Surely Go has this?

func main() { a := 1 func() { b := a g := func() { c := b fmt.Println("c is", c) a = 7 } g() }() fmt.Println("a is now", a) }

https://play.golang.org/p/zmWwCNm_PuU

Const-me• 8 years ago

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 general purpose ones. Among others, I’ve used XSLT, sed, awk, VBScript, VB.NET, R, power shell, AutoLISP, MATLAB.

Theoretically all modern programming languages are equivalent because Turing-complete. Practically, for a particular problem, it can be orders of magnitude difference in development time between them. The reasons include availability of specific libraries, integration with other code be it third-party or legacy, or specific runtime features.

arunc3• 8 years ago

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.

EvenThisAcronym• 8 years ago

There's a strictly adhered to rule across Reddit/HN that every D article must consist primarily of people asking why the author did not use Rust/Go instead.

dom96• 8 years ago

After this initial pruning, three languages remained on our shortlist: Free Pascal, Ada and D.

I'm really sad to see that the author didn't even consider the Nim programming language. They could have saved themselves a LOT of work, Nim's original compiler was written in Pascal and then translated to Nim using a `pas2nim` tool that is freely available on GitHub[1].

Out of Go, Rust and D, Nim is most similar to Pascal by a long shot. Did the author simply miss Nim completely or did they dismiss it for another reason? It seems to me like it would be absolutely perfect for their project.

1 - https://github.com/nim-lang/pas2nim

How an Engineering Company Chose to Migrate to D

Related Stories