
The perfect language and why Go still isn't it - snazz
https://www.snazz.xyz/programming/2019/07/31/perfect-language.html
======
ypcx
Well, Go seems to have enabled a new wave of software renaissance -
Kubernetes, Docker, you name it - Go seems to have filled the space that Java
was too fat for, JavaScript too light for, and C/C++ too difficult/fun-less to
use for (which is everything).

After 20 years of coding, and having just recently discovered LISP and learned
Clojure, I believe the perfect language will be a Clojure compiled to native
with the ease of Go (e.g. w/ similar import system).

One such direction seems to be Carp ([https://github.com/carp-
lang/Carp](https://github.com/carp-lang/Carp)), but I haven't tried it yet.

~~~
coldtea
> _Well, Go seems to have enabled a new wave of software renaissance -
> Kubernetes, Docker, you name it_

Let's name it. I wouldn't call either of these a "software renaissance".
Docker is a wrapper on top of Linux kernel containers, and Kubernetes is a
10000 pound gorilla on top (and port of a C++ app, some say even through a
Java rewrite/transpile to Go).

Go was just at the peak of being fashionable at the time (and had some basic
features not semantics/syntax related like easy static compilation and cross
platform-ness) so got adopted by these projects, the same way many new
projects now use Rust.

~~~
twic
Docker is a bad design. It is _monstrously_ overcomplicated for what it does.
In historico-aesthetic analogies, it's baroque, not renaissance.

~~~
lkrubner
And what does it actually give that is new? What does Docker give that you
can't get with a normal VM, with Terraform to spin up however many instances
that you need? Put an app on an AMI, save it, if you need one instance, or a
1,000 instances, spin them up with Terraform. You get to stick with normal
operating systems, such as Linux and Windows. You don't have to learn a bunch
of new technologies.

[http://www.smashcompany.com/technology/docker-is-a-
dangerous...](http://www.smashcompany.com/technology/docker-is-a-dangerous-
gamble-which-we-will-regret)

~~~
lossolo
> What does Docker give that you can't get with a normal VM

There is a difference between Linux container (Docker underhood) and full
blown Virtual Machine. In case of docker you are not running new operating
system, you are just running new processes in different namespace but still
using the same kernel. Linux containers are lightweight, you can start them as
easy and fast as other processes, without overhead. VM (in most cases) is
separate operating system running, which means startup time is different, you
have overhead (CPU usage for keeping OS running and all its services,
additional RAM usage, additional disk space usage etc) of whole operating
system + virtualization overhead (in a lot of cases but can be minimzed).

~~~
lkrubner
Yes, I know, but what does that give me? When I'm setting up the
infrastructure for my company, what can I do with Docker that I can't do more
easily with a standard VM and Terraform? In terms of security, isolation,
orchestration of services, managing concurrency, I get everything I need with
ordinary VMs and Terraform. I don't see what Docker gives me.

------
alkonaut
Every language has flaws. Some of the best languages are those that take
existing languages and just throw out some of the bad legacy mistakes, making
what’s often a slightly different but pretty much objectively “better”
language.

For example: Kotlin is a better Java in almost every way.

The problem with almost all such languages is that they aren’t different
enough from their “parent” languages, meaning they struggle to gain traction.
Both D and Kotlin are here.

~~~
pdpi
I think Kotlin has also leapfrogged D on this — Google blessing it for Android
use and an Android community clearly hoping for something better than an
aeons-old version of Java goes a very long way.

The Android success story might just be what the language needs to establish
itself enough that it’ll become a backend staple too

~~~
pjmlp
I think Kotlin's future is tied to Android's.

Outside Android there are better options.

On the JVM, just like any other platform, is safer to bet on the systems
language of the platform than guest languages with extra debugging layers,
tooling and their own wrappers for idiomatic code.

Then Kotlin is trying to stretch too much, meaning that any portable Kotlin
code cannot depend on any platform or needs multiple implementations.

Finally Kotlin/Native has special semantics for handling data structures, as
it tries to be Swift like, so special care is needed when the code is supposed
to be used from Kotlin/Native as well.

~~~
ptx
> Finally Kotlin/Native has special semantics for handling data structures, as
> it tries to be Swift like

If you mean Swift's issue with having to use weak references to prevent
cycles, Kotlin/Native doesn't do that – they have a cycle collector, so it
should behave the same as Kotlin/JVM.

It does have a different threading model though, where you can't share mutable
structures between threads. Very recently they've introduced a "relaxed" mode
that does allow it, but it's extremely experimental and sounds like it would
be slow (since it can't defer updating reference counts).

(Also, what are you referring to with "extra debugging layers, tooling and
their own wrappers" for Kotlin on the JVM? I can use IntelliJ + Maven + Spring
with either Java or Kotlin. I don't see any extra layers.)

~~~
pjmlp
Yep, I mean the semantic model for data structures.

Try to call idiomatic Kotlin code from Java and see how it looks like.
Specially when co-routines and similar higher level constructs get added, or
having to deal with compatibility between Java streams and Kotlin sequences,
which don't build on top of Java ones.

When Loom arrives, it will be a similar story, Java proper fibers and Kotlin
co-routines and how they might interoperate.

Nothing unique to Kotlin per se, all guest languages happen to have similar
bumps. Calling Scala or Clojure from Java leads to similar lists.

Then one is required to buy into JetBrains tooling for Kotlin, and get an
additional license for Clion as means to have a graphical debugger for
Kotlin/Native.

There is an Eclipse plug-in, which is kind of 2nd tier, and none at all for
Netbeans.

With Java it is just ready set go, no matter which IDE, with just one IDE for
Java and native, alongside mixed mode debugging (a feature JetBrains doesn't
see a value supporting) and not all Java shops are into InteliJ idolatry.

------
degraafc
Go is actually pretty close to the perfect language to me -- for "general
purpose" computing, at least. Sure, it's plain and somewhat boring to write
but it doesn't make me that much less productive. Error handling and generics
are the only other features that I want, so I'm really looking forward to Go
2, if that ever comes around. I would be happy to see Go declared "feature-
complete" at that point, similar to Elixir [1].

But even then, if I want to have fun and feel like I'm learning new things
while I code, I'll always use something else that's more interesting.

[1]: [https://elixir-
lang.org/blog/2019/06/24/elixir-v1-9-0-releas...](https://elixir-
lang.org/blog/2019/06/24/elixir-v1-9-0-released/)

------
slx26
Go and Rust are the latest languages I started to use. Neither is perfect,
both are awesome, but more importantly, both are a step forward, both get a
lot of things very right, and for the rest, most are at least acceptable. When
I code, most of my frustrating moments come from underlying problems with
cross compatibility, access to hardware, graphics, encodings, etc, which are
rarely problems caused by languages themselves.

We are pretty new at this, we are still trying to figure out a lot of things.
We are still experimenting a lot with many features. But step by step, new
language after new language, we keep improving.

Trying to be realist tends to be a painful exercise, but in the case of
programming languages, I think the situation is looking pretty good. There
might be a billion paths left to explore, but at least the ones we are
exploring are bringing something useful to the table. I hope we soon start
writing articles titled "the perfect languages and the exciting ways we are
getting closer to them". The article was pretty good, by the way.

~~~
zinclozenge
Go has some great 'under the hood' features, ie ones provided by its runtime,
but man the language syntax makes it really annoying to take advantage of
them. The sweet spot for me would be something between Go and Rust, ie a
language with generics, algebraic data types, pattern matching, garbage
collection, good concurrency primitives with a good work stealing scheduler.

So I'm basically asking for OCaml with multithreading.

~~~
nathcd
In case you haven't heard of it, you should check out Pony
([https://www.ponylang.io/](https://www.ponylang.io/)). It's definitely got
its own flair, but characteristically it's a lot like what you describe.

------
namelosw
Wait... We must having different definition of perfect. I would say Go is a
very good language, and probably be one of the best in terms of simple and
practical design, fast execution, fast compilation etc.

The perfection, however, is not something Go never meant to be. The perfect
language possibly support fully dependent type like Idris while maintains zero
abstraction cost like Rust, having precise syntax rule like Lisp, and a
powerful runtime like Erlang, and the list goes on.

The success of Go lies in it's trade-offs, the designers are opinionated,
knowing well what they want and what they don't, and executes things well in
the implementation.

~~~
networkimprov
Zig might become the perfect language, assuming OOP is not must-have :-)

[https://ziglang.org/](https://ziglang.org/)

~~~
lazyjones
But it has pointless semicolons. No, thanks. ;-)

~~~
apta
golang puts semicolons behind the scenes anyway, resulting in bizarre
behaviors like not being able to write braces that follow "if" or "for" on
separate lines.

~~~
lazyjones
It's not "bizarre", just a tradeoff explained here:
[https://golang.org/doc/faq#semicolons](https://golang.org/doc/faq#semicolons)

If they thought it mattered much, they'd change it... But since the code
should be formatted correctly always, it's not necessary.

------
mijoharas
Every time I've tried to write some go, I've always started reaching for some
things that aren't there (essentially generics). I'm looking forward to go 2.0
and hope the inclusion of generics will make it more pleasant to write.

Also, while it's said comically often in HN comments, Rust (and particularly
the iterator api) is very pleasing to write. I'd say it sits in quite a sweet
spot language-wise.

Context, I'm a C++ programmer who had been writing in dynamic languages for
the last couple of years.

~~~
asdvxgxasjab
Curious about your use cases for generics. I write a lot of Go and don't often
find myself missing generics. I also used to write a good deal of C++ and
didn't find myself often needing templates either.

~~~
thanatos_dem
How often do you find yourself writing or using `interface{}`? It’s littered
all over the go code I’ve seen, including the standard library.

`interface{}` is the equivalent to using `Object` in java land. It completely
punts on any sort of type safety, relying on the developer to handle messy
edge cases correctly. I think one of the only reasons that it hasn’t been as
severe a problem in go as java is thanks to that explicit error checking that
go makes developers do (and that gets so much hate online), forcing developers
to consider the case that the type isn’t what they assume.

But genetics provide a useful way to safely make those assumptions, and cut
down on the boilerplate around them.

~~~
majewsky
> It’s littered all over the go code I’ve seen, including the standard
> library.

From my experience, interface{} is incredibly uncommon in application code. In
_most_ instances where the standard library uses it, it's usually justified
because the function in question really accepts literally any type of
argument, e.g. json.Marshal() or reflect.TypeOf(). The only counterexample I
can think of are sort.Sort() and sort.Slice().

Given all the implications of adding generics to the language, I think Go
would be better off just adding the common higher-order list/map manipulation
functions to the builtins, i.e. the likes of map(), filter(), maybe reduce().

------
ccday
Go isn’t the perfect language because it doesn’t intend to be. Likely, as this
article seems to hint at, there’s no such thing and there never will be. Go
has a well defined set of design goals (including simple and pragmatic) that
it has achieved.

~~~
littlestymaar
> Go has a well defined set of design goals (including simple and pragmatic)
> that it has achieved.

If your look how much changes are proposed as part of the Go2 work, I'm not
sure the Go developers agree with you.

~~~
majewsky
Yet the concrete proposals keep getting shot down or reworked. If anything,
this makes me _more_ sure that the Go developers care about their core design
goals. They are listening to community feedback, but they don't allow a vocal
minority to bury the original vision.

------
abvr
Let me break it to you, there _is_ no perfect language, just the ones most
general purpose enough to cover most common problems and most suited for your
applications. Each language has it own use and one doesn't trump another in
terms of functionality or usage, they only compete when they lie in the same
paradigm and this is where most language oriented comparisons are drawn
whether be it time of execution or performance. This is also why there are
more than one language within the same paradigm, as each one tends to have
it's own intricacies and features that was solely developed for the purpose of
improving upon it's predecessor. So there you are, stuck with more than one
language to suit your needs and hence the untenable need for a perfect
language.

Also, trying to bend a certain language to adopt features and functionality
that are unwarranted for it's use cases is another reason for the criticism
some languages draw upon from the community, therefore it's best for the
language to stick to what it does best and stop it at that instead of trying
to fit in to uses which it was never intended for when it was first developed.
But the language itself is agreeable to evolve through time, but to constrain
itself to it's actual purpose would be better for both the language and it's
users.

------
pjmlp
Languages are software products like everything else, so they either improve
to cater for their "customers" and survive against competition, or they wither
and die into some kind of maintenance corner.

Even languages that supposedly no one uses like Fortran and Cobol, get their
standards revisited every couple of years.

One might not want to re-write that surviving Cobol program into a reactive
text UI with a couple of FactoryFactory classes, but it is surely possible as
per latest language features.

------
shmerl
Language can't be small, if it's universal enough. Otherwise you end up with
trade-offs for its size, which limit scenarios where that language can be
used.

So there is no "perfect" language. All languages have some trade-offs. If you
want small - you pay for it.

~~~
chewxy
> Language can't be small, if it's universal enough

t, u := x | λx.t | (t u)

Small language (three production rules), definitely universal.

Of course the semantics is a lot more complicated than most people expect. But
it IS syntactically very simple

~~~
shmerl
Theoretical cases that are unusable in practice aren't interesting in the
above context. We are talking about practical languages. It's not about Turing
completeness.

~~~
chewxy
s := a | (s s)

common lisp syntax. Even simpler, but that shifts much of abstraction
capabilities to the operational semantics.

------
themango
There's never going to be a perfect language -- stick with what gets the work
done for the situation at hand.

Also make some popcorn and enjoy the Twitter flame wars while you're at it.

------
open-source-ux
It's a futile quest to find the perfect programming language. Any language
that gains popularity will face a vocal demand for new features at some point.
But it's not just about adding new concepts. Programmers also want new
shortcuts for existing features to save them a few keystrokes. That then
entails issuing recommendations on when to use such shortcuts to keep code
consistent.

There are plenty of small languages, but they lack popularity or rich
libraries. The only language I can think of that remains in widespread use and
is fairly small in language size is C.

I'm strongly in the camp that small languages are preferable to large ones and
wish language designers would follow this principle more closely. But small
does not necessarily mean more readable. And language syntax design remains a
neglected aspect of programming language design.

~~~
pjmlp
Even C is full of features if you compare C11 with K&R C, and C20 is already
ongoing.

And if we consider the amount of compiler specific C extensions, across all C
implementations, it gets even bigger.

~~~
jart
[http://www.lysator.liu.se/c/ANSI-C-
grammar-y.html](http://www.lysator.liu.se/c/ANSI-C-grammar-y.html) ← 1980's C
(429 lines)

[http://www.quut.com/c/ANSI-C-grammar-y-2011.html](http://www.quut.com/c/ANSI-
C-grammar-y-2011.html) ← 2010's C (536 lines)

~~~
pjmlp
What is that supposed to say?

A language grammar is only a tiny part of what makes a programming language.

Compare ISO C pages and C compiler manuals instead.

------
analognoise
This already exists, but it isn't trendy.

It's FreePascal. Nobody believes me, but we have perfection already. No crap
you don't need. No crazy corner cases. No C++ templated metaprogramming lambda
auto pointer garbage. No "I can't write a linked list without a Grimoire"
Rust.

It's great. You get a ton done, and simply ignore the language wars. No VM
trash (Java). No web trash (JavaScript/"Webasm"). No crap.

Try all the others, and try FreePascal. It's old enough that people aren't
bolting on stupid shit. The community is awesome. Everybody just gets shit
done. There's a lot of art if you go looking, but none of it requires a
kilopage book to describe.

~~~
pjmlp
As much as I like Pascal, and I am a big fan since Turbo Pascal since version
4 for MS-DOS, using all of them until about Delphi 3, lack of some kind of
automatic memory management is a killer for anyone that cares about code
security.

Delphi only supports it for COM and Objective-c/Swift interoperability,
everything else is as manual as TP for MS-DOS, and I bet FP hasn't improved in
that regard.

~~~
_ph_
Ah, a young lad :) I started tinkering with Turbo Pascal 3 and even have some
experience with Pascal on the Apple II. (Not because I am THAT old, but that
were the only computers my school had at the end of the 80ies)

The successors of Pascal are also highly interesting. I used Modula-2 quite a
lot, but never got deep into Oberon. I do think one big advantage of Go is,
that it so strongly draws on the Wirth languages that it almost can be
considered a modern successor.

And I fully agree, one shouldn't use a language these days for general
programming without some kind of automatic memory management. Which is the
other aspect which drew me towards Go, a nice nativley compiled language with
a GC.

~~~
pjmlp
Yeah, quite young indeed. :)

I was initially also drawn into Go, mainly due to its Oberon-2 influence as
well. Even did a couple of contribution attempts during pre-v1 days , but they
weren't that good anyway.

However back in the Oberon days, what I liked was the evolution that followed
suit, Oberon-2, Component Pascal, Active Oberon and finally Zonnon.

As such, I never appreciated the minimalism discussions around Go and not
having modern language features. For that we already have Wirth cutting down
Oberon features in every Oberon-07 language specification document revision.

Still, I do look forward for some Go 2.0 roadmap items to actually land in Go,
and advocate for its use in applications that would be otherwise written in C,
if Go wasn't a thing.

And I also collect examples of actual systems work done in Go, regardless of
it not being suitable in the opinions of anti-GC crowd.

~~~
_ph_
Honestly, I am quite happy with the role of Go as a better C. A lot of
applications still get written in C because C++ isn't making things better.
And Go has a lot of higher level constructs than C, so it reaches into much
further domains than C. Structs with methods and struct inheritance as well as
interfaces give a surprising amount of power. Also, having first class
functions and closures gives a ton of power C (and even C++) lack. Add to that
the great GC, and there are surprisingly few tasks I consider Go unfit for.

I am certainly watching the work on Go 2.0, it is certainly worth to continue
working on enhancing the language, but I am very happy how carefully it is
done as adding too much complexity to the language would be detrimental. There
are only a very few things I miss generics for and usually they can be worked
around.

I might have to add the disclaimer, that my paying job is mainly about
programming in Lisp, so for me there is a high-level alternative to Go, but
this also shows me how Go is a great solution for a lot of problems.

------
AdeptusAquinas
F# hits all his 'perfect language' points for me. It feels like a more
concise, opinionated and beautiful refinement of C#.

~~~
6thaccount2
I really like F#, but it has a few major pain points that hinder adoption:

The first is that once a user reads over the various functional things like
let statements, record types, union types...etc, you still don't really know
how to code in F# unless you already have a .NET and in particular C#
background. Nearly all the documentation and books (I have 3 of them) assume
you're a C# dev making the switch. This is similar to learning
Clojure/Kotlin/Scala on the JVM without knowing any Java. Everytime I post
this someone tells me that is untrue, so I give it another shot and an
dissapointed. With Python, there are dozens of books written for beginners
that show you the building blocks (lists, control flow, dictionaries, tuples,
functions, classes, file IO...etc) and how to use the blocks to build useful
programs. With F# you get three sentences in and then hear how this is just
like this thing in C# that I also know nothing about.

Microsoft also seems to not be very dedicated to providing F# tooling support.

On the plus side, I've found the community to be super smart and helpful and
the language itself is very beautiful from an aesthetics point of view to me
somehow (just looking at a bunch of code ). In comparison to C#, there is sooo
much less noise (); everywhere.

Go is a pretty simple language that compiles to static binaries. F# ain't that
as there is all the bloat and baggage of .NET. Even with .NET core, that is
more confusion for me.

~~~
AdeptusAquinas
You are not wrong. In fact I would argue it would be very hard to learn F#
without knowing C# even if resources did not assume you did, since one of F#'s
major strengths is the ability to use the entire .NET ecosystem just like
Clojure as you said, and the .NET ecosystem is written for C# semantics
(usable from F# but generally with some slight syntax switching).

On the tooling front, Microsoft include it as a prime language with C# and
VB.NET in dotnet core, and ship F# tools with their latest IDEs, which I
appreciate and is almost more than I would expect, since their flagship is C#.
It would be nice if it was better, but that would require it to be a lot more
popular which is fair enough.

Static binaries are something that would be real nice. I've done it with F#
using CoreRT, but its certainly not as simple as Go.

~~~
pjmlp
Not really prime still, not even on .NET Core, there are several VS tools that
only work with C# and VB.NET.

CLR is multiple language runtime and actually the only language that has full
control over all possible bytecodes is C++/CLI, not C#.

CoreRT is on its way out, going to be replaced by Crossgen.

They did a talk on AOT compilation at Java Language Summit last week.

------
thegabez
The perfect language is the one humans won't have to write.

------
tus88
Go isn't even close. It has an interesting runtime though.

------
cygned
One of Go’s strength is the opinionated nature that makes it easy for me as a
developer to read and understand other’s code. It’s trivial to jump into the
implementation of the standard API to see how things work.

~~~
hodgesrm
Simple things like gofmt have helped enormously. Leaving out exceptions and
templates have made the code harder to write (for me at least) but easier to
read. It's the code equivalent of "schema on write."

------
patientplatypus
The frustrating thing about Go for me is that it lacks generics but is
strictly typed, which encourages the passing of empty interfaces which can
cause problems at runtime. You have to be very careful about storing all your
data properly in structs or you face a big foot gun.

Which, like, fair enough. It's not perfect. But it's still really really good.
I mean, people still use Java...

~~~
cpuguy83
The alternative approach here would be to gernerate code for things that need
genetics rather than using empty interface. Of course as with all things there
are trade-offs... as there will be if/when generics are introduced.

------
rb808
I really like Go (and Rust) and would like a job as its main language. However
I don't have enough experience with the language, anyone know the job market
and recommend a path or should I give up? I don't have time to spend a few
hours/wk just to learn enough to get experience.

~~~
Retric
Usually, people start building demo’s or other side projects at their main job
using whatever new tech they want to pad to their resume. This is bad for the
company and your coworkers, but for people jumping ship every 2-3 years
leaving a mess has few downsides.

A more ethical approach is to simply learn at work during downtime over
browsing the web. It even looks like work, so few people complain.

~~~
geofft
Building demos to pad your resume is bad for the company, but building demos
to achieve unmet business needs is good for the company, and usually there are
plenty of those lying around.

~~~
0x445442
What I've noticed is in a lot of big enterprise shops that are playing "Agile"
there is a big gap in support/tooling software; that is, software that makes
developers more productive by automating repetitive tasks. Since this type of
software doesn't exist to management because it won't fit nicely onto a Jira
board or it can't be bent to fit a specific OKR, it's the perfect type of
software to explore other languages.

~~~
geofft
Yes! It's also software that matters very little if you can't get a good
support story for it - it's not customer facing and there are no SLAs, so
worst case, everyone's automation fails but they can still get their job done.
If you want to build a CLI for handling code reviews or an automated bisection
tool using OCaml on a Raspberry Pi or whatever, that's way more acceptable
than building customer-facing software (either services or shipped software)
using OCaml on a Raspberry Pi.

Also, writing this type type of software makes you an _actual_ 10x engineer
(by making 10 other engineers more productive).

------
Wowfunhappy
I feel like a variation of these steps could describe a lot of software in
general, across industries.

------
zidoo
There is no such thing as perfect. Good is good enough. Go is good for a lot
of things.

------
holografix
I think Go could be fundamentally improved if it somehow offered a REPL.

~~~
H8crilA
So you're at step 3?

~~~
Dylan16807
From the article? Not at all. It doesn't matter if it's easy or difficult,
because it only needs to be coded once. And it's not a request to change the
language at all, just the tooling.

~~~
marcus_holmes
I don't really understand how a REPL would help with coding Go. I think I use
tests to do what I think people use REPLs for, and I don't get why I'd change
that to a REPL if I could - having those tests permanent is a good thing.

What would a REPL bring to the party?

~~~
casion
A REPL allows you to work in real-time with the system as it's written.

It's nothing like unit testing. It's like running around in the system able to
poke-prod things as you go.

Particularly important is that it doesn't mean working in a console. Most
REPL-based dev is done in the source code file itself, and you send code from
the document to the REPL process. Code is written in a file as usual, and you
utilize the REPL to massage the system as you want.

Though it's Clojure-based, you might want to watch this talk:
[https://vimeo.com/223309989](https://vimeo.com/223309989)

~~~
marcus_holmes
yeah that would be interesting to try out, thanks for the link :)

I meant that I use tests as a way of poke-prodding things - because Go
compiles so fast, and you can run individual tests, it's easy to tool around
in test code setting up specific state in code and seeing what happens.

------
signa11

        When someone says "I want a programming language 
        in which I need only say what I wish done," 
        give him a lollipop. 
    
           - alan-j-perlis

~~~
coldtea
Nobody says that in the post or in this thread though...

------
calebclark
There will never be a perfect language until there is a perfect programmer.

------
dis-sys
Go never intended to be perfect, it made no claim to be perfect. When people
still write long articles explaining why Go is not perfect, for me, it is
pretty strong indication that Go is actually pretty close to be perfect.

~~~
Dylan16807
You know people write long articles explaining why PHP is not perfect, right?

~~~
eternalban
"It's the economy, stupid", said a former US President.

It's the economic attributes of a language that contribute to its market
share. Go is a very good language from an economic point of view. (Java was
also a remarkably good language, from an economic point of view.)

As to the your specific point, I suggest a sufficiently large slice of
software workers will include the sub-set that write long articles defending
their theoretically so-so but economically superior languages: Those blog
posts are a feature, not a bug, of economically viable programming languages.

The bottom line is no one has proven that "the bottom line" is positively
affected by use of sophisticated languages. The killer app of ho-hum languages
is their _demonstrated_ economic value.

~~~
Dylan16807
PHP has a couple attributes that make it easy to start using and deploy, and a
massive pile of network effects.

Those attributes have nothing to do with why it's a garbage fire, and
'sophistication' also has nothing to do with it. You could redo PHP to be
equally sophisticated, and still have the things that make it popular, but
also be a hundred times more consistent and less buggy. Heck, fixing refs and
inconsistent syntax could make it _less_ sophisticated.

At least they've been fixing some of it...

