I ask as an old SML guy, I like the math theory, I like the promise of better, more accurate and reliable software, I think you can do some beautiful things with algebraic types but I've been dumbfounded by the lack of great examples out there. Ada suffered/suffers the same fate, it has this "academic" pedigree for robustness but not many examples that you can get your hands on. so much expressiveness that doesn't seem to result in much expression.

I'm tempted to compare it to PHP, which exploded in popularity despite (unarguably, IMHO) better languages existing all around it at the time. Go doesn't seem like a bad language in the way that PHP was a bad language for its first 4~5 major versions, but it does find itself surrounded by many more powerful/expressive languages, and is seemingly getting much faster adoption.

I've been learning Go myself, and while I miss some of the features of my normal primary languages (Perl, lately, but also Ruby and Python), I like that I can read other people's Go code without having to look anything up, even though Go is very new to me and I have years experience reading/writing Perl/Ruby/Python. Of course, Perl/Python/Ruby aren't a major paradigm shift away from Go as Haskell is...but, it's still a question of whether it's better to write ten simplistic LOC or two maybe opaque LOC. I tend to prefer concision over verbosity (and thus hate reading Java; I get lost in the trees before I can find the forest).

Maybe Go is a sweet spot for a lot of developers. Rob Pike did a talk called Simplicity is Complicated, about this very subject...I found it a pretty convincing argument. https://www.youtube.com/watch?v=rFejpH_tAHM

1) Our industry is obsessed with new and shiny.

2) There are a lot of developers and companies who don't have the time to invest in a new paradigm or language.

3) By learning/using golang these developers and companies can look "hip" and forward thinking with minimal effort.

With a Java background and a 10 hour investment in golang you can write decent software.

With a 10 hour investment in Haskell you can't do anything.

While you might think it's worth spending 100+ hours learning Haskell, I don't (at the moment) have any reason to Haskell as a better time investment than anything else on that list.. why should I give it more than 10 hours?

So while I'd love to write big chunks of Haskell, if its just me doing it, that code will be nuked and rewritten unless I also undertake a project of education. So accessibility is key. Go/python/js seem to win in that regard, and likewise in access to libraries.

So unless as an organisation there is motivation to step up skilling, e.g. because there is a lot of money at stake if something breaks (e.g. trading software), or because there is a community of practice (compilers) its hard to see Haskell gaining much ground.

Likewise all those other languages has their niche, and it is hard to seem them displacing each other.

This happens in hiring practices, in programming languages, in infrastructure tech, in data tech, etc.

It's extremely rare to encounter a data scale problem that actually requires a Hadoop-ish deployment, but they're all over the place. It's extremely rare to encounter an ops infrastructure that requires a scale and complexity where Kubernetes-ish tools make sense, but they're all over the place.

I admittedly don't fully understand the point of Go (as in existentially). I have used it, and will assuredly have to keep using it based on its increasing popularity. But it's not as good as Erlang for reliability or supporting production tools (services use cases). It's not as good as Rust or Haskell for implementation assurance (safety/security use cases). It's not as good for numerical processing as Julia or Fortran (scientific/performance use cases).

It feels a lot like the next generation of Java to me.

In that it's some shape of "good enough". And when "good enough" is combined with the cachet of aligning oneself with Google's ecosystem, it's basically unstoppable.

It's a pretty close to pure expression of a few language designer's vision, with very little in the way of corporate influence (that I can discern). And, I think that's the point of Go; it's the language its designers wanted for the tasks they wanted to work on (web scale services). It just happens that a lot of people want/need to work on the same sort of thing.

I agree that most people embracing massive scale are doing so way too early and probably aint gonna need it. But, that doesn't mean Go isn't a useful tool, anyway. I've watched a few videos, and read a few tutorials, and the brevity of Go for things like network servers is breathtaking. The cleverness of interfaces is...well, it really has to be seen to be understood. It's not OO, it's not functional. It's...something else. Contrary to the impression that maybe I've given in other comments, Go does have some features that aren't commonly seen elsewhere (or, if they are, they're bolted on). It has some fancy features, but only a few, and only in specific areas.

It seems like a very well thought out language, to me. Which might have been true of Java in its very early days...I'm not sure. I've never really been a Java developer, though I've read some Java code now and then.

So, Go might be merely "good enough" on some fronts, but I think it's great on a few specific fronts. And, it does it without requiring total buy-in on a new paradigm, which is probably its killer feature. It looks a little like Python or whatever in syntax, but acts a little like Erlang on a few specific details. Pretty good combination, and the community seems to agree.

[0] https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

Well, Google doesn't put as much money into Go either (as MS and Sun put into Java and C#). Sun and C# had much bigger teams, much bigger budgets, and tons of marketing money spent on them, including actual ads everywhere. Just the team writing the C# documentation was probably bigger than the whole Google Go team.

But that's relative:

Unlike most OSS/community driven languages (e.g. Nim or Julia), Go has a big enough team that's paid to work on Go. That makes a difference.

Also found it crashed a lot, which I would have hoped would be one of the things Haskell would solve (the problems revolved it having to integrate into C code for linking to X, but that's part of living in the real world).

You can create your own document templates, and tweak the resulting output in a million ways. At my job, I have to create a lot of documentation, often in PDF or docx, and Pandoc has become an integral part of my workflow. I can create documents within the comfortable environment of Emacs, and use Pandoc to produce output in any old format that $pointy_haired_boss may desire.

Complex transformations of data structures are part of the compilation activity too, but they're more difficult to spot in the wild of applications.

I think the number of useful tools is pretty closely correlated to popularity, and obviously Haskell has a relatively small user base. It's not like Haskell gives you super-powers and makes you 10x more productive; it mostly lets you write better software, not necessarily more software. I do feel more productive with Haskell, but it's on the order of 50-100% (depending on the task), not enough to let Haskellers match the open-source output of a very popular language like C.

Oh, and i've seen someone on HN saying it's used in something like the upcoming Kosovo land property tax system or something like that but i am not directly aware of that.

On the practical side, I love having types that let me refactor so mercilessly, along with a very mature compiler with a decent suite of warnings.

Perhaps the type of problems Haskell is apt to solve (those requiring strict correctness, etc.) are not typically open source software projects.

Rust, I'd argue, is the correct choice for many OSS projects. In fact, for security-focused projects, it should be the only choice. C-like performance without C-like vulnerabilities? It makes no sense to choose C or C++ any more.

https://wiki.haskell.org/Research_papers/Functional_pearls

The great thing about Haskell and other functional programming languages is that the functional style forces the program to be created in a form that is modular and elegant. Programs become modular and composable and re-composable in the functional world because the programmer has No Choice but to build his programs in an elegant way. It's hard to explain this to a typical programmer who hasn't dived deep into functional programming but code reuse, modularity and elegance are significantly higher in functional programming languages than in procedural.

This elegance, beauty and forced organization comes at a high cost though. And the cost is thinking in a way that is outside the normal paradigm of what humans are use to. I know a lot of haskellers think that humans can be taught to think in both ways equally, I disagree with them and believe that it is far Easier for a human to think about an algorithm procedurally than it is for him to think about it functionally.

If you have several tasks to execute, what is your first thought on how to plan out those tasks? A task list (aka list of functions) or a series of composed tasks placed in a single sentence (aka expression)? The answer is obvious: humans think about the list first because procedural programming comes more naturally.

This I believe is the main reason why Haskell or lisps haven't taken over the programming world. Functional programming is just HARDER. It takes me 10 times longer to hack out a simple program in haskell than it does in python because haskell doesn't allow you to 'hack' together a program. In haskell the application has to be an elegant diamond or the thing won't even compile! Python allows me to hack something together quickly which is both a good and a bad thing because as we all know hacking together software is quick but easily leads to unmaintainable software.

Nonsense - You only have to make things as hard/elegant as you want them to be (and fore sure, some people do play that game for better/worse).

But, Haskell will happily allow you throw everything in to IO; you can side-step creating a perfect model and just hack together a list of imperative IO statements.

(unless you're referring to the difference between a dynlang and a static lang; that's a difference of another category altogether)

It's actually super pleasant!

It's even possible to opt out of static type checking if you want.

GHCi also provides a REPL that makes exploratory programming easy.

However, neither should prevent the other. (i.e. "you can do X" should not be confused with "always do X"). Haskell allows you to choose.

Indeed, proper domain modeling is preferred.. but it's nice to have to ability to make that choice yourself based on your own constraints.

Additionally, Haskell makes it very easy/pleasant to refactor from the former to the latter. (On that note, imho the best models (in business) are arrived at iteratively rather than big-design-up-front)

That is not what is usually meant by "expressiveness" of a language. You seem to be talking about types of languages (as in the Chomsky hierarchy), by implying that there are problems you can solve in assembler but not in Haskell. That is not the case, as both are Turing-complete (Type-0).

In contrast, "expressiveness" usually refers to the "ease" (one may substitute conciseness in most cases) with which higher level concepts (abstractions) are expressible in the language, and here Haskell clearly wins against assembler, and many other popular languages.

No it's not. The Haskell compiler is free to use whatever assembly instructions that it sees fit to compile the Haskell program.

Maybe you mean that effectively, the set of assembly programs (i.e. sequences of assembly instructions) which existing Haskell compilers happen to produce is limited. This is true. But it is also true that you can find an equivalent Haskell program for every possible assembly program, where equivalent means they exhibit the same behavior with respect to inputs and outputs. This is because both are Turing equivalent.

Now, it's also true that the way two equivalent programs get to their results may differ. For example, the assembly program might be faster. However, these are non-functional properties of the programs. And you were talking explicitly about functionality, so this point doesn't count towards your argument.

But this is the basic idea I was trying to convey: that you lose "expressiveness" as you get higher and higher in levels of abstraction.

```asm section .data str: db 'Hello world!', 0Ah str_len: equ $ - str

section .text global _start

_start: mov eax, 4 mov ebx, 1 mov ecx, str mov edx, str_len int 80h mov eax, 1 mov ebx, 0 int 80h ```

In Haskell I don't have to consider any processor.

```hs main = putStr "Hello World" ```

expressiveness is about how much code you need for a certain behavior. It's not about how many (possible fucked up) source files my compiler accepts.

A typical task list has tons of side effects, which is not the case with your "pipe lines."

> If you have several tasks to execute, what is your first thought on how to plan out those tasks? A task list (aka list of functions) or a series of composed tasks placed in a single sentence (aka expression)? The answer is obvious: humans think about the list first because procedural programming comes more naturally. This I believe is the main reason why Haskell or lisps haven't taken over the programming world.

As to whether programming with expressions is fundamentally harder, I'm not so sure. Since Fortran, most languages have supported arithmetic expressions over primitive numeric types, since they are certainly not easier with an imperative approach (MOV, MOV, ADD, PUSH). Haskell allows one to easily take this further using arbitrary objects and algebras, for example, expressions with drawing primitives, parsing grammars, financial contracts etc. With a small amount of syntactic sugar, you can even make expressions that look exactly like imperative programming (Haskell's do notation).

There is nothing preventing using these "task lists" (e.g. lists/steps/procedures) in Haskell. In fact, "do notation", a core language feature every beginner learns, features it.

Functional programming in essence does not allow procedures, but with special incredibly complex abstractions you can simulate procedures. If you program using said abstractions I would argue that it makes functional programming even Harder to understand.

I still don't understand what the problem is with them.

It's just a box with some "stuff" in, a function that makes a new box with a thing inside, and a function that takes a box and a value and gives you a new box with some different stuff inside.

The hardest part for me was accepting that I can't look inside the box and don't actually need to.

I do get that there are a lot of people who'll look at monads and want to know why the heck they should bother when any "decent" or "reasonable" language just lets all their functions crap all over the filesystem whenever they like.

But I don't think do notation is what trips up beginners (not sure if this discussion is about beginners per se). It is explained by simple mechanical plug-and-chug transformations that I think beginners understand, but am willing to hear if there is evidence otherwise.. I just think it's the other things that will eventually trip them up (I was only responding to specific claims made earlier). Also, on the point of resting on abstractions being a problem, I don't find compelling, because I'm also sure that Python beginners don't understand what "class MyStuff(object):" is really doing, but if the abstraction isn't leaky try don't need to know right away, and they can delve later.

I've found that "powerful" languages allow me to do clever things(TM) and I hate clever things(TM) retroactively when I come back to them.

This gets even worse when you have multiple people on the team doing clever things(TM).

They also allow you to do sensible things(TM) like use the one and single, battle tested, standard library's generic sort, btree, etc implementation, instead of having to roll (and then read) 1000s of your own over the span of a year...

And it's a false dichotomy that you can't have the sensible things(TM) without the too-clever-for-their-own-good-things (TM) you allude too.

When you look at a line of code, what can you tell about its semantics without considering non-local information? What is invariant and what could potentially be redefined?

I think the answer to this question is extremely important for readability when you're not already familiar with a codebase.

There's functional alternatives to Haskell which adopt the non-lazy as default, such as Elm, Rust, SML, Lisps, Fantom, Elixir, Scala, etc.

I have to admit though, this is a bit of a trade off situation. Working with pure functions is very simple, but to map those to unpure behavior, like IO, you need something that isolate that, and without laziness, I'm not sure how you can get that to be practical.

I totally agree with you about pure functions. They can be a real simplification, but only if any deviation from purity requires special syntax at the call site. Otherwise you're back in the guessing game.

Haskell makes it easy to write data and function types that enforce purity at the call site, throwing a type error if you make a mistake. Not just purity though, you can restrict these types to any arbitrary set of methods of your choosing. This lets you do things like parsing a blob of JSON and having all functions that depend on the result be guaranteed not to have to deal with a failed parse or otherwise invalid data. The fact that the data is good has been encoded in the types, preventing you from passing bad data by throwing a type error.

Definitely Haskell's game then

It's just toy first-timer Haskell examples of quicksort (that still work, mind you) that don't.

But then again, take a language like C, and consider how many things (like proper error handling) are missing from 99% of the toy tutorial examples available.

“The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.”

~ Edsger Dijkstra

I think i can honestly say i did not fully get that quote until i learned Haskell

A language like Haskell lets me write extremely complicated code, but it also lets me concisely express the constraints I want in the form of types without getting too verbose. Go lets me do neither.

Less powerful languages force the programmer to come up with their own clever abstractions so that if you have multiple programmers you'll end up with 20 different clever ways of doing the same thing.

Dynamic languages - ruby, python, bash, objective C etc - allow all sorts of cleverness - such as monkey patching, attribute injection, dynamic lookup - because of their dynamic runtime. All the checks about whether the code makes sense is performed at runtime.

Languages with more mature/strong/static typesystems are initially restrictive - but the emphasis in cleverness is to be able to know upfront - and at compile time - if the code expressed is consistent in the way data and effects are represented and expressed.

Of course - there are other kinds of code complexity -in terms of ease of understanding, and maintainability - that will always involve tradeoffs considering the task at hand and nature of the programming environment (solo, community, commercial, academic etc).

I was forced to use go for a job, it actually made me feel stupider, so much that I didn't know how to use the right types anymore when i moved back to a more sophisticated language. I was afraid the language wouldn't let me do what I want, just like Go.

There will be a "go programmer generation" and it's not going to be pretty. If people deem "generics too complicated to understand", what can you expect from programmers who don't want to learn anything? The only thing I find nice about the language is implicit interfaces. But not at all cost.

Yes, you are a little bit limmited sometimes because of the lack of generics and the like, but at the same time, if you learn to use Go interfaces well, you end up using them most of the time happily. The parallelism primitives are great too.

As much as I love complex type systems, pattern matching, algebraic data types etc., I know that if Go had those things, it wouldn't be the language I love to write everyday anymore.

Somehow, Go is a really practical language and you end up being very productive in it, at least from my experience.

Saying that people who write Go should be stupid is shallow thinking. Complex languages aren't the only complexity that you should have. Some people concentrate on sophisticated architectural design (like Kubernetes).

There is one thing in Go, that I haven't met anywhere else. I can really understand any codebase I stumble upon in a matter of seconds. This is a huge boon to productivity.

Anyways, I never had any problems switching between Go and languages like F# or Scala on a daily basis. Rust looks interesting, though I think it will end up being too complex for a lot of people to understand, which will hinder its growth.

Care to elaborate a bit more?

I understand that when you see for(...) { b[i] = f(a[i]); } then you instinctively know that it's a loop that maps over some sequence, and so on. But let's say you have a 50-100kloc codebase with a 100 files in it. In what unique to Go way does Go help you understand the big picture/coarse architecture of such a project?

I meant smaller parts of code, and not for loops actually. (I prefer maps, filters etc.). Things like gofmt and the simplicity (in that, small number of concepts) of the language lead to most people writing fairly idiomatic code. This way most codebases look the same and you read each other's code as it were yours.

I genuinely despise that about it.

I think it's in the same position Java found itself in the early 2000s, another boring and unimaginative language that ended up being a workhorse.

But they could still build a better bridge, in less time, with proper materials.

I’d be interested if you can name any fields where non-Google go projects dominate. I only know of containers.

EDIT: You can also check out all the stuff the CoreOS team puts out.

We never even heard of any of those except for CockroachDB.

Are you sure these are "dominating the entire industry"-products, as you mentioned before? Or is it more that they’re only used in SV?

EDIT: Cockroach is actually the most SV'ish of all those.

I wouldn’t call Consul "industry-dominating technology", as you’d do with ElasticSearch, Hadoop, Spark, etc.

Almost everywhere else, it’s not "industry-dominating" at all, so I’m not sure why people use the argument "go is used everywhere and everything is in go" (which is obviously false) to argue that go is a good language.

(besides, C is actually used everywhere, but no one would use that as argument to show how C is a good language).

So standard that it doesn’t even have a Wikipedia page? Nor is there even one for this specific type of datacenter-oriented service discovery?

This is all pretty niche tech, used by a handful of startups that engineer technology for billions of users, but not used anywhere else. I’ve never seen any companies on national scale operate with this – nor would they need to.

Anyways, Service Discovery like this is less niche than containers are. If containers are still niche for you, then there you go.

Well, so are you, your comments are even so grey I can barely read them anymore (and I can’t downvote you).

Regarding the rest: Containers are far less niche than Consul is. For service discovery, the market isn’t nearly as monopolized as containers are. And containers are far more used than consul is – most places I’ve seen build their own service discovery systems, or hardcode a main node and then have services in containers register with that, etc.

While for containers, at the moment, there’s almost only docker, due to the ecosystem.

Go's main attraction there is that it's a simple, script-like language that compiles to easily deployed static binaries. That enables people who's main job is not necessarily coding, but with a good scripting background to solve problems by writing more complex/performance-critical stuff which was previously not feasible in languages like Python, Ruby, ...

These projects requiring more performance would have required a seasoned dedicated C/C++ coder before, but now they can be started and maintainer by people initially not focusing on programming, but on solving problems they are facing in their daily job. They don't have the time to invest learning a language with complex typesystems where initially, you'll be fighting the language itself more than solving actual problems. For programmers, this investment is useful, it's their main skill and is worth something. Ops people have other things to worry about, and just want to solve problems.

It does mean wheels are being reinvented, but the major projects now have pretty smart people working on them, hitting the limits of the language and it's garbage collector, pushing them forward.

Thankfully, this is true only in the HN bubble. One example: Amazon.

That said if I look back on the past 6 months, I believe I have improved. In fact, a core principle I hold dear goes as follows:

"If I look back 6 months and I'm not any better, there's a big problem".

At one point, it seemed to annoy my non-technical boss because he couldn't understand why some of the code I wrote 6 months ago is perhaps not as good as it could be. He has kept me around so maybe it isn't a bad thing :)

We will, I think, always have programmers who don't want to learn anything new. It's interesting that there exists "Continuing Professional Development points" in the UK for healthcare: you get a rebate for each hour spent on courses to further your education. Maybe software engineering would benefit from this given the amount of, quite significant, cost sunk into large scale projects. Their universal credit programme should be incentive enough.

Entirely different problem though. If not Go, then what?

So I end up stuck working with crappier tech, crappier tools, and dealing with the effects of fewer and fewer resources going into improving the last 5% of annoying things about Erlang. While a deluge of resources go into partially reinventing the first 50% of it over and over again in some other random language.

Erlang would have been a great fit for Pusher's problem space.

Blargh! :-(

Agents don't seem like they should be in the standard library. The pipe operator should probably have some sugar for representing the first implicit argument to the function because it's weird to have things like Enum.map/2 become written as Enum.map/1 in that context. Protocols are bizarrely complex (you can do the same thing in Erlang with about 10% of the ceremony) and made weirder by the fact that structs are represented as maps with a special key instead of as records, so field access and key walking has an unnecessary amount of overhead comparatively. It doesn't feel "complete", because there are pretty big chunks of the underlying system that still make you extremely aware you're really running atop Erlang (debugging, tracing, profiling, etc.), up to and including the docs themselves which often just point you straight to the relevant Erlang documentation.

I like that it has brought a lot of new energy to the BEAM ecosystem. I like the tooling and focus on docs and testing that have come with it. I like the macro system, even though I think it's overused by the community and often to ill effect, but the system itself is much cleaner than Erlang's.

tl;dr... Sure, why not. :-)

Only you can easily change languages...

Stoicism was referring to actual things one cannot change. Like, say, death, or their status as a roman slave.

So it's less stoicism and more "our way or the highway".

That's a ridiculous blanket statement to make. Changing languages can incur a very high cost. Making peace with this as an individual seems like a useful skill to acquire. If you want to insist then there's no connection to stoicism, then fine, but don't try to pass off language choice as something that's easy to change along the way.

Yes, but you can always not even get started with Go (or whatever language you don't like) to begin with, so no change cost there.

Also, you can always change organizations, especially in today's "buyer's market" IT landscape. Better than working with something that you feel makes you miserable and non-productive.

And it's best to apply the principle of charity to what one responds to. Things are not always meant at their strictest interpretation. Compared to the "things you cannot change" stoicism was concerned with (like death, your past, some genetic misfortune, etc.), a programming language is nothing especially unchangeable -- which was my point.

That said, I absolutely love your libs and programs and use them all the time :-)

I don't write Rust or Go code but his repo seems like it is a great showcase for both languages - from what I read, it seems Rust is a little bit more expressive than Go but, having not written anything significant in either, I'm not the best judge.

I think Rust especially should be on on my "to explore" list :)

I would consider changing organizations to be an immense cost. It would be perfectly reasonable to apply stoic principles to make peace with language choice. Many of the costs associated from using a tool one believes is inferior are related to one's own emotional reaction to it. If you can conquer that, then you've made yourself a lot more flexible.

I can't imagine how anyone could claim that changing organizations is something that's easy. :-/

Thanks for your comment on charity. I admit that I came on a bit strong after rereading my comment. I sometimes get frustrated quite a bit with your commentary on Go, and I let it get the best of me. Sorry about that.

Perhaps then the stoic lesson is we should write some machine code from time to time to really enjoy the benefits of anything above. Or, to relate, writing a bit of Go for some time when you mostly write Haskell.

It's significantly harder for an organization of 10+ developers to change from a single language to another single language without a technically savvy and respected manager just mandating what it will be.

Other times, though, being forced to work with obtuse tools feels like trying to construct a skyscraper out of sticks and dog crap. No matter how elegant a structure you manage to construct, doing so is a miserable experience because you're never able to transcend the feeling that you're working with twigs and poo.

As someone whos written code in Haskell (even some medium sized programs) and moved on just fine, no.

Frankly, Haskell can be an excercise in frustration.

Choosing a language that makes these things difficult, is a poor choice. We should not accept subpar languages to be used just because.

I think the problem lies in the fact many programmers don't have the luxury of making those decisions. I imagine if one of those programmers refused to use the mandated tools, they'd get the sack. Many of those programmers, again, don't have the leg room to handle that. Plus, I don't think any employer would look favourably on "I got sacked because I refused to use language X because language Y is superior". I know that isn't the kind of attitude to work I would appreciate.

The companies that allow freedom of choice in tools and languages are perhaps the best companies to work for. Unfortunately, those companies hire the best programmers in the first place, or at least set the bar with that in mind. Most programmers, including myself, are not of this calibre.

Source: at a previous job we had a "use whatever tool you want, just get the job done" policy. After two years we had everything from Perl to JavaScript in the same project.

Edit: ... and this project was a desktop application!

Perhaps we are unearthing various kinds of choices i.e choices for best fit vs best convenience. Perhaps that's a case of engineering vs something other.

Also, the newer parts of the language such as the object system and the presence of closures and first class functions are almost pleasant to work with: for the most part, the annoyances come from the old stuff

I abused Ruby's metaprogramming capabilities to build a small functional language with operators. I monkey patched symbols with operator overloading to add the typical functional operators such as composition (using * since . isn't possible). I created operators for piping, partial application, etc. Terrible abuses that probably reduced inter-library and future compatibility to 0.

I don't think that would be possible in any way with PHP without PECL (there is an extension for operator overloading magic methods) whereas it is with Ruby out the box.

If the language allows me to abuse it in such a way more than another, I reckon it holds more expressive power. Case in point: Lisp.

bad programmers do that. As professionals, we should refuse to implement something in the wrong language and allow somebody else to do the job.

That said FP/Lisp are very hard to leave, I can understand that.

Just the other day I was struggling with the hopeless nightmare of Java's lack of true first class functions (but still having some first class function like semantics) combined with embedded classes restrictions combined with generics thrown in for good measure (AsyncTask embedding in an activity and updating result in the activity).

Go features are clearly specified in a very readable and fairly concise spec and guide and its features fit seamlessly together virtually every time​