←back to thread

“Go’s design is a disservice to intelligent programmers”

(nomad.so)
131 points apta | 3 comments | 25 Mar 15 21:48 UTC | HN request time: 0.929s | source
Show context
carbocation ◴[25 Mar 15 22:12 UTC] No.9266352[source]▶
My summary of the author's points: no generics, inexpressive, no good package manager, procedural.

Of these, caring about the fact that it is procedural seems pure opinion. Lacking a package manager is not really a language issue (PHP's package manager, for example, is not coupled to the core language).

So, we are left with the lack of generics and the lack of expressivity. I'm not deep enough in the weeds to be able to argue pro/con for generics intelligently right now, so I will concede that as a concern that has been raised by many.

The lack of expressivity seems to be an inexorable consequence of the goal of simplicity, so I'm sympathetic. That said, it seems to be a tradeoff acknowledged by Go's authors, not an oversight.

Overall, these points don't convince me of the author's thesis (or, at least, they don't seem to justify the title's degree of inflammation).

replies(5): >>9266432 #>>9266452 #>>9266511 #>>9269687 #>>9281940 #
mmcclure ◴[25 Mar 15 22:40 UTC] No.9266511[source]▶
> PHP's package manager, for example, is not coupled to the core language

"Lacking a package manager isn't a language issue, this language that's nearly universally derided doesn't have one."

I see what you're saying, but that strikes me as a really bad example. That being said, it is strange to me that a modern language wouldn't have any reasonable story around package management. The argument I've most commonly heard is that applications should be very small bits of functionality, thus making a full-blown package manager unnecessary...sure, that seems reasonable...except dependency management is still (aside from the whole generics flame war) one of the most common complaints I've heard from Go devs.

To be honest, I don't understand all the vitriol. That's by far the most bizarre thing about Go to me.

replies(2): >>9266687 #>>9266758 #
benihana ◴[25 Mar 15 23:23 UTC] No.9266758[source]▶
It's bizarre to me that you started your post by dismissing an entire language based on popular opinion then end it by saying you don't understand the vitriol people have about a different language.
replies(1): >>9267133 #
mmcclure ◴[26 Mar 15 00:55 UTC] No.9267133[source]▶
I personally don't understand the vitriolic posts on Go. I personally do understand the vitriolic comments about PHP, of which there are examples that are well-reasoned and go beyond "no generics!"[1]

[1] http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design

replies(1): >>9267739 #
Gigablah ◴[26 Mar 15 03:56 UTC] No.9267739[source]▶
It's 2015, the PHP ecosystem has progressed. Citing that blog post hurts your argument more than it helps.
replies(1): >>9268521 #
1. NateDad ◴[26 Mar 15 09:24 UTC] No.9268521[source]▶
The blog post is only three years old, and the problems it brings up are basic language problems. Has the language really changed that much in three years? And if so, wouldn't that leave all the existing projects out in the cold?

Serious question. I don't know the PHP community at all.

replies(1): >>9272991 #
2. kmshardware ◴[26 Mar 15 20:49 UTC] No.9272991[source]▶
I do a fair amount of PHP (really, I run hhvm, but let's say modern php), and effectively nothing in that article affects me.

No one should be using mysql_* anything; no one should have been using it for years. It's deprecated. It throws warnings when run. PHP's love of forced backward compatibility causes some very interesting things to be remained.

Paamayim Nekudotayim isn't called that anymore and hasn't for a long time.

The author raises issues about things like @fopen(url) - no one I know, or myself, has ever done that. It makes absolutely no sense to.

PHP has autoloading/"modules"/dependency injection/a proper package manager/etc (article is from early 2012: composer was largely popularised from what I can see a bit after that).

The author complains about no stack traces - sure, there won't be any on a single file bad function name, but any time I've used a proper request library or anything best practice, I've gotten a proper stack trace with file names, lines, etc.

--

There are a lot of somewhat odd complaints or wildly strange, like "No Unicode support" and "PHP is naturally tied to Apache. Running it separately, or with any other webserver, requires just as much mucking around" which makes absolutely no sense to me. The author of this article even says that if you want to run two versions of PHP, you rebuild Apache? That's absurd.

> 'The “bunch of files” approach, besides making routing a huge pain in the ass, also means you have to carefully whitelist or blacklist what stuff is actually available, because your URL hierarchy is also your entire code tree'

None of this makes sense either: unless you are doing some seriously outdated horrors, you have effectively one /index.php router and a public asset folder for the webroot.

replies(1): >>9275422 #
3. NateDad ◴[27 Mar 15 10:15 UTC] No.9275422[source]▶
Thanks for typing all that out. It's great to hear that most of what that article complains about is not affecting current PHP projects. I know there's a ton of PHP out there, so it can't be that bad. :)