I've been working with Delphi for the last 18 months; previously Java and .Net many years before that, but Delphi in the distant, distant past.

In my opinion, Delphi needs to just die, and the people/companies that have code bases built on it need to rewrite. There are lots of choices for software development these days, I don't think Delphi stands out for any particular use case in the modern world. But hey, maybe I'm just bitter after RAD Studio crashed on me one too many times...

Compared to VC++, it was easier to learn, read, write, make reliable apps, and extend. I could teach anyone a Wirth language. The Go community is learning the benefits of Pascal-style design. People wanting a new Delphi should probably use Go. Just because Delphi stagnated and died off.

Anyone wanting Pascal/Delphi today should use Lazaurus IDE w/ Free Pascal Compiler. Compatible with Delphi where it mattered, aiming for better in other areas, open-source, and cross-platform. Best use case is a C or C++ replacement that's safer, easy to read, and supports computers with little resources. Go's not there yet on runtime side.

> People wanting a new Delphi should probably use Go. Just because Delphi stagnated and died off.

Or, for that matter, Nim, which also has a huge amount of Pascal heritage.

Go is a hybrid of Oberon and C (with semantics leaning more towards Oberon and syntax more towards C, but they're both mixed in), and Nim is Modula-3 semantics married to Python syntax (with the best parts of a bunch of other languages thrown in). Both Oberon and Modula-3 are descended from Modula-2, which in turn is descended from Pascal.

Personally, I'm more in the Nim camp, partially because I prefer Modula-3 to Oberon, partially because I prefer Nim's Pythonesque syntax to Go's C/Oberon mashup syntax, and partially because Nim's metaprogramming features are truly beautiful.

Modula-3 semantics married to Python syntax. Now that sounds potentially great. :) Even more so since I've recommended each language. Modula-3 was the second time (since Turbo Pascal) that industry types took Wirth's design ideas, ran with them, and produced an industrial implementation that kicked ass. Was used in SPIN OS w/ type-safe linking where OS and linked code leveraged type system for protection. Python syntax's benefits are well known.

I was a bit concerned about the maturity, compiler complexity, available libraries, and so on about Nim. I figured it might be in alpha quality or something given it's so new. So, I was hesitant to try it. I might give it a go sometime soon reading comments like yours.

Btw, do you have experience with its macro system? Any take-it-to-next-level language needs at least good macros and preferably great ones. Top contenders of my recent research are Racket, Julia, and Red. If Nim is more like Modula3/Python & has good macros, then it might be a credible contender due to mainstream programmers being able to pick it up more easily than really weird languages.

> which in turn is descended from Python.

I think you meant Pascal?

Yes, I did. I'll edit it.

(...and edited)

Go might have a few Oberon influences, and it was what made me look at it in first place.

However, even Turbo Pascal was more expressive than Go in terms of language features (not taking the GC into account). Delphi even more so, specially if one takes into consideration the VCL and IDE.

But, it would be nice to see someone come up with a System 3 Gadgets library for Go, or an environment like BlackBox Component Builder.

I totally agree. Blackbox is particularly kicking butt in Russia. I recommended Go because it's mainstreamed with all benefits that entails for developers and employers.

Most people writing Delphi code in 2015 do it to maintain legacy Windows desktop applications. I don't think you can do that with Go. The most logical replacement would still be C# (or another language running on .net) with WinRT (or more likely WPF: I mean if you are still using Delphi you are probably not using Windows 8/10...).

Funny you say that cuz I picked it for future proofing. I specifically wanted it to be the legacy language instead of C++ in case the talent was short many years down the line. That proved out haha. ;)

Yeah, Delphi needs to die. I used it for a long time, and it was an excellent product for developing Windows applications when compared to the main alternatives, i.e. Visual C++ with MFC (the horror!) or VB6.

It was fast, efficient, easy to use, with a great community, good tooling and the picky type system tended to find a lot of potential bugs at compile time (once you got used to it).

Now there are a lot of alternatives and to be honest, I can't really think of a reason you'd choose it any more - even if you /did/ want to create Windows native apps.

How about: Using win32 means your application works without any problem and any third-party dlls or weird installs on anything from win2k to windows10 and winRT (any non-arm version). Making a single .exe that works across all of them isn't very hard. Making one that also works on linux and even android and ios is possible, but isn't nearly as seemless. Needless to say, you won't achieve this with either webapps, C#, java, or any of the other languages.

It's incredibly fast. You know how Go and C++ start with tiny applications ? The app starts up 0.2 seconds after you've finished typing the command. Delphi does that for 150000 lines applications. Your executables are decently sized (2-5 megabytes for large apps, kilobytes for small games and the like. Especially Go and C++ have problems with executable size. Go's hello world is still > 2 megabytes, and large go apps have huge binary sizes (dozens of megabytes), despite not containing spectacular amounts of code. Large C++ binaries, statically linked, are dozens to hundreds of megabytes (and God help you if you turn on debug info. I've known compiling a webserver + database app in C++ that actually failed to compile due to the single binary filling up the disk that had ~18 Gigabytes of free space (the binary, once compiled was 1.8 gigabytes, the rest was intermediate files)).

The number of add-ons, controls, database connectivity, install software, ... available for Delphi defies belief and they're extremely high quality.

It's extremely unlikely to change in backwards incompatible ways. Your code will keep working, and will keep looking and working the way it does now (compared to java or shudder the web, it's heaven)

Of course, there are downsides : manual memory allocation is a bit inconvenient (but very fast), HTTP/JSON communication is tricky. Nobody trusts .exe files anymore (for good reason, of course, but ...). It's unlikely to impress when judged on the last buzzwords.

Don't forget the first pivot: Inprise.

Borland decided that the new shiny thing was "enterprise client/server middleware" — whatever that was. The new Inprise products were oriented towards building distributed client/server database apps using DCOM and the all-too-obviously-dead-on-arrival CORBA.

This was right around the time the web took off, but before the inane "enterprise Java application server" market exploded. Borland had a hard time competing with Java, and they started to neglect the stuff that had made Delphi such a powerful proposition in the first place.