The reference D compiler is now open source • Hacker News Board

Re: The reference D compiler is now open source

#251

Post by pekk » Sat, Apr 08, 2017, 7:09 AM UTC

coding123 wrote: post #179

iamNumber4 wrote: post #105

Good news indeed. Switched to D 4 years ago, and have never looked back. I wager that you can sit down a C++/Java/C# veteran, and say write some D code. Here's the manual, have fun. They will with in a few hours be comfortable with the language, and be fairly competent D programmer. Very little FUD surrounding the switching to yet another language with D. D's only issue is that it does not have general adoption, whic…

I think a lot of languages that get popular have to have a thing. Like a thing they do well, and hopefully change the world a little... Python had math and has lots more maths now. R also has math and started to kill Python, but now Python has Tensorflow and PyTorch. Scala has Spark. Java has Tomcat, and everything that followed, which is probably 20% of the world's mass by volume. Go has Docker Ruby has/had a railro…

R is old. R always had math. That's not new. Python always had a lot of other things. Strange depiction.

Re: The reference D compiler is now open source

#252

Post by milesrout » Sat, Apr 08, 2017, 7:27 AM UTC

jacques_chirac wrote: post #10

omginternets wrote: post #4

Earlier quoted context omitted.

Why is this a good thing? I'm not familiar with the Boost license.

It is the least encumbering, very permissive and very well regarded in both oss and corporate circles. Really a good choice to stick with it.

That doesn't make it good. That makes it bad. It doesn't protect the rights of users. It's really important that developer tools are GPL, as that prevents vendor lock-in and EEE tactics.

Re: The reference D compiler is now open source

#253

Post by lomnakkus » Sat, Apr 08, 2017, 7:27 AM UTC

milesrout wrote: post #220

lomnakkus wrote: post #122

Earlier quoted context omitted.

I'm not sure that "it's going to stay", as you say, but at the very least it's been hugely influential on C++ (if constexpr, anyone?) and even for just that it is and has been valuable for everyone working in C++ land.

If constexpr is not inspired by static if. In fact, proposals of static if and things like it were explicitly rejected by the committee.

AFAICT, yes it was. Obviously, it wasn't accepted as-is, but it was certainly motivated (i.e. "inspired") by the success of "static if" in D.

Re: The reference D compiler is now open source

#254

Post by xtreak_1 » Sat, Apr 08, 2017, 9:02 AM UTC

Thanks a lot! I am also consistently amazed at the performance of the forum like any other day even though the story is on top of HN.

Re: The reference D compiler is now open source

#255

Post by ChickeNES » Sat, Apr 08, 2017, 9:13 AM UTC

milesrout wrote: post #252

jacques_chirac wrote: post #10

Earlier quoted context omitted.

It is the least encumbering, very permissive and very well regarded in both oss and corporate circles. Really a good choice to stick with it.

That doesn't make it good. That makes it bad. It doesn't protect the rights of users. It's really important that developer tools are GPL, as that prevents vendor lock-in and EEE tactics.

How is preventing me from making a closed sourced derivative of dmd in any way protecting my rights as a a user of the source?

Re: The reference D compiler is now open source

#256

Post by noway421 » Sat, Apr 08, 2017, 10:48 AM UTC

It's really surprising that to this day, there are languages in use which have its reference implementation closed source. All the possible optimizations and collaboration possible when it's open is invaluable.

Re: The reference D compiler is now open source

#257

Post by FabHK » Sat, Apr 08, 2017, 10:49 AM UTC

throwaway7645 wrote: post #229

jacquesm wrote: post #187

Earlier quoted context omitted.

FORTRAN users beg to differ. The horse they backed will be here until the lights go out because it probably is used to power the lights at some level.

Yes it most certainly is. All the power system applications written in the 60's and 70's were done so in Fortran as they had to be fast and run numerical analysis on massive matrices. However, a lot of it is being rewritten in more modern languages like C++ or C depending on the application.

> numerical analysis on massive matrices. However, a lot of it is being rewritten

In Julia, too.

Re: The reference D compiler is now open source

#258

Post by throwaway7645 » Sat, Apr 08, 2017, 11:24 AM UTC

FabHK wrote: post #257

throwaway7645 wrote: post #229

Earlier quoted context omitted.

Yes it most certainly is. All the power system applications written in the 60's and 70's were done so in Fortran as they had to be fast and run numerical analysis on massive matrices. However, a lot of it is being rewritten in more modern languages like C++ or C depending on the application.

> numerical analysis on massive matrices. However, a lot of it is being rewritten In Julia, too.

Probably some, but in the industry I'm referring to, nobody is going to let you write a critical system in some new relatively unknown language. Options are Fortran, C, C++, or Java. Julia is cool, but still really new in the cosmic scale.

Re: The reference D compiler is now open source

#259

Post by throwaway7645 » Sat, Apr 08, 2017, 11:30 AM UTC

ChickeNES wrote: post #255

milesrout wrote: post #252

Earlier quoted context omitted.

That doesn't make it good. That makes it bad. It doesn't protect the rights of users. It's really important that developer tools are GPL, as that prevents vendor lock-in and EEE tactics.

How is preventing me from making a closed sourced derivative of dmd in any way protecting my rights as a a user of the source?

A two-edged sword in my opinion. GPL always protects the end-user so they can get the source, but it infringes on the creator trying to make closed source software. So as a user I like GPL, but when programming I tend to mostly avoid it. Mine mine mine! :)

Re: The reference D compiler is now open source

#260

Post by hydromet » Sat, Apr 08, 2017, 11:36 AM UTC

saosebastiao wrote: post #30

qznc wrote: post #28

Earlier quoted context omitted.

There is no quantitative metric for safety and easyness. If you can afford a garbage collector, D easily wins over Rust. If you really need the safe manual memory management, Rust wins. In between is still a large grey area.

There are plenty of reasons why Rust could win outside of requiring safe manual memory management. It is an expression based language with ad-hoc polymorphism, algebraic data types, hygienic macros, first class functions, and race-free concurrency. I don't use rust because I don't need manual memory management and I require subtype polymorphism for a lot of things, but I choose Scala over D.

I recently (past few years) invested in learning Clojure, enough to get some practical things deployed, but I am far from being a Clojure advanced developer. I wanted to learn a Lisp dialect and am glad I chose Clojure. Rich Hickey is a guru. I don't have any gripes with Clojure but I'm not too deeply invested. Several years ago I was also enamored with Julia, which I was investigating for CPU intensive programs, but never had the time to commit and I was concerned about Julia being too youthful and possibly not getting enough traction. Should I learn D for CPU intensive programs? Also, with Clojure I can make use of the many Java libraries for I/O due to Clojure's good Java interop. Does D have the analogous benefit of tried and tested I/O libraries? Thanks for any suggestions, D has my intrigued.