Live data from Hacker News

Four years of Go

blog.golang.org

191–200 of 202 posts

Re: Four years of Go

#191
post #144

Earlier quoted context omitted.

> It will tend to make a dent one program at a time - like etcd, docker, nsq. Soon, a significant fraction of your installables will have to be compiled with Go. Only if commercial UNIX and Windows also get rewritten in Go. > This was reason enough for C to get popular. C got popular because UNIX was adopted by the enterprise and C was the system language. I doubt C would ever been popular without UNIX.

I might be off, but I think C still would have been popular. It's such a simple language, very easy to learn, easy to reason about, close to the machine but provides enough abstraction to easily write complicated code. C's merits as a language are self-evident beyond its usage in Unix. Of course, some other language with this set of properties might have taken C's role if it had not been for unix, so maybe that's wha…

> It's such a simple language, very easy to learn...

Mhm.

> ... easy to reason about...

So very much no. There is nothing about the stateful nature of C-programming, its syntax or the patterns people use that is easy to reason about. You're comparing it to what, exactly? C++? C is an amazing language but comparing it to the languages that were around when it became popular it's not even close to relatively easy to reason about. Even less so nowadays.

> provides enough abstraction to easily write complicated code

This strikes me as a weird thing to list in "pros". Complicated is the opposite of good. Abstractions should let you write simple code, not complicated code. I feel like you've either misunderstood the word "complicated", massively mischaracterized C or you have a very weird view on abstraction.

> Of course, some other language with this set of properties might have taken C's role if it had not been for unix, so maybe that's what you meant.

I'd like to point out that your assumption that people use programming languages because they are better than the alternatives is pretty naive. The most popular languages are decent, no doubt, but have you noticed how every really good language suffers from a pretty huge lack of users? We all know these languages are better, but it's never been an issue of "You're not good enough for people to use you".

If there was ever any indicator for a good language it'd be "What do people choose when they have the freedom, knowledge and opportunity to choose anything without any outside influence?". That scenario is so wildly scarce to observe and anyone who is in that situation likely suffers from biases acquired earlier on his programming journey.

Re: Four years of Go

#193
post #173

Earlier quoted context omitted.

I find good old /bin/sh is better than perl or python for the use case you are talking about. Perl rose out of the huge gulf between shell and C. The distance from shell to go is much smaller.

I have a bunch of scripts which are written in standard shell, and for simple stuff, it's fine. But as soon as it starts doing file name manipulation, or working with collections of files (say finding the age of the most recently changed file in a directory, and checking how long ago that was and changing color-extended attributes of the enclosing directory so projects untouched in over a month turn grey...), and you…

What you described is exactly what I mean by simple stuff where shell is ideal. People generally find perl or python easier for those tasks because they took the time to learn perl or python, but didn't take the time to learn sh.

Re: Four years of Go

#194
post #170

Earlier quoted context omitted.

>especially if you're the kind of programmer (a systems developer) that appreciates that kind of balance. Go really failed to appeal to a lot of systems programmers, despite their intentions. Go is picking up people who used untyped languages and still didn't accept that static typing does not mean java. They finally have a simplistic statically typed language that isn't java to use.

This is more "Internet article of faith" than actual fact; it's something people say because it was said in some blog post once. For whatever it's worth to you, I've been a systems programmer since ~1995. The lingua franca of systems programming is C; Golang's type system is strictly superior to C.

It is more "direct observation" than "internet article of faith". I know one person who likes C and go. Every other go convert I know came from a scripting language. Golang's type system is strictly inferior to D.

Re: Four years of Go

#195
post #57
post #49

Earlier quoted context omitted.

> None of the languages being compared against were released in the ubiquitous-internet age with things like Github and widespread blogging to drive interest and adoption. Which doesn't seem to matter anyway. There are tons of languages released every year that fare even worse than languages released in 1980, despite having "ubiquitous-internet, Github and widespread blogging" at their disposal.

How many are backed by one of the largest companies on the internet?

Not many, including Go. Go is extremely peripheral to what Google does -- it's essentially a 20% project that did well.

Re: Four years of Go

#196
post #95

Earlier quoted context omitted.

That's true. Java in the 90s was a spectacular con job that millions of developers and managers bought hook, line, and sinker. XML was pretty big back then, too, and now nobody gives two warm shits about XML. Just saying. Anyway the hype is surely not the reason why anyone should use go. People should use go because it has good libraries, encourages good interfaces, is fast and space efficient, has good self document…

Both Java and the XML are in heavy use today with plenty of people caring about them. XML is still the right tool for the job for many use cases. JSON is great for serializing data structures. XML is great for marking up various types of textual data. Other people have already covered your comment on Java.

I don't understand why people dismiss XML like that, I use it a lot at my line of work and it makes sense.

We need the structure that JSON can't give us and other data markup languages are too obscure to teach them to everyone we work with.

Re: Four years of Go

#197
post #144

Earlier quoted context omitted.

> It will tend to make a dent one program at a time - like etcd, docker, nsq. Soon, a significant fraction of your installables will have to be compiled with Go. Only if commercial UNIX and Windows also get rewritten in Go. > This was reason enough for C to get popular. C got popular because UNIX was adopted by the enterprise and C was the system language. I doubt C would ever been popular without UNIX.

This is correct. C was dying off in the mid-1980s until UNIX-based workstations were invented, causing a resurgence in C's popularity.

Sorry, but that's just plain wrong. Everything was being implemented in C from embedded control to PC apps with C++ just around the corner.

Re: Four years of Go

#198

Earlier quoted context omitted.

My experience with Go was bizarre -- I loved programming in it, but I don't understand why! For example, Go has no REPL. (It's difficult for statically-typed languages to provide one.) It's commonly believed that a REPL is valuable and increases productivity. So if you were offered the choice, is there any circumstance in which "no REPL" is equally powerful as having one? Well, the vast majority of great hackers seem…

Perl and PHP are also open source languages were people don't use repls often. Java and C# don't have repls either. I don't think everyone has ever thought they needed a REPL for any reasonable definition of everyone .

re.pl is invaluable to the modern Perl programmer (as is cpanm).

Re: Four years of Go

#199
post #198

Earlier quoted context omitted.

Perl and PHP are also open source languages were people don't use repls often. Java and C# don't have repls either. I don't think everyone has ever thought they needed a REPL for any reasonable definition of everyone .

re.pl is invaluable to the modern Perl programmer (as is cpanm).

I don't think it's invaluable to the modern perl developer. I don't know whether I disagree with your concept of invaluable or your concept of modern perl developer or both. I tried searching "perl repl" on twitter and google to see if there's much talk about it and there doesn't seem to be much. AFAICT it just isn't a big part of the perl workflow, modern or not. Most of the people who like it could manage just fine without it. I don't think the same is the case with python or ruby. Some pythonistas and rubyists use the repl for everything.

I use small files instead of repls most of the time. There's no program that's too short to be stored in a file.

Re: Four years of Go

#200
post #198

Earlier quoted context omitted.

re.pl is invaluable to the modern Perl programmer (as is cpanm).

I don't think it's invaluable to the modern perl developer . I don't know whether I disagree with your concept of invaluable or your concept of modern perl developer or both. I tried searching "perl repl" on twitter and google to see if there's much talk about it and there doesn't seem to be much. AFAICT it just isn't a big part of the perl workflow, modern or not. Most of the people who like it could manage just fin…

The best place to search (for Perl REPL's) is on CPAN - https://metacpan.org/search?q=repl

The current grandaddy is Devel::REPL - https://metacpan.org/release/Devel-REPL

The new kid on the block is Reply - https://metacpan.org/release/Reply

PS. I do find using a Perl REPL invaluable for me.

Post reply on HN