Live data from Hacker News

Ask HN: Go programming language is over ten years old. What do you think of it?

news.ycombinator.com

231–240 of 310 posts

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#231
Nonsense language. We've only had problems with it historically, both writing and deploying it. It's threading model sounds great in theory, but we've found that bounding most programs to one system thread improves performance in nearly all cases we've come across.

The tooling and ecosystem are ridiculous, the dependency management is a nightmare, and the fact it's backed by an incredibly evil company doesn't help either.

Further, any criticism of the language results in cult-like angry responses, as do most modern toy languages.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#232
post #97

Earlier quoted context omitted.

Boring is actually what a lot of people look for.

I never understood why people are looking for things which are boring and I think it is mostly employers who do. They should look for something which is good and solves their problems. I don't know how something with the attribute boring is of interest here as other attributes for a technology/PL might be much more important... Actually they mean something different with "boring": It is just a lack of courage for sim…

This, plus it enables them to fire and replace developers without much difficulty because there's a great number of people who know these languages (see Java...).

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#233
post #153

I have no interest in Go because it is so limited, more limited than other languages that I have already moved beyond, such as C#. I am far more interested in cutting edge languages such as Rust (borrow checker) or Idris (dependent types) or even C++ 20 (template madness), since these will allow me to express things that I cannot express in other languages. What does Go bring to the table? Note that my perspective is…

> What does Go bring to the table? A still maintainable code base 5 years along.

No language will magically give you maintainability. I've worked on several year old golang projects and they've been terrible, made worse by the fact that golang doesn't scale well for teams or larger programs.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#234
post #213
post #204

Earlier quoted context omitted.

golang is anemic in front of Java (the JVM, the language, and the ecosystem) and introduces its own set of gotchas. Once Java gets green threads (by means of Project Loom), golang will be an extremely difficult sell for anyone considering a new project.

Java's place in data processing is as secure as COBOL's. Go's is not. But, as with COBOL, it is not because Java is good, or getting better. It is because--like COBOL, FORTRAN, C, C++, Javascript and Python, and unlike Pascal, Ada, PL/I and myriad others--Java got a miracle. Absent a miracle, languages fade away.

Java is getting better. It's getting records, value types, and green threads, and pattern matching, and more.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#235
post #97

Earlier quoted context omitted.

Boring is actually what a lot of people look for.

I never understood why people are looking for things which are boring and I think it is mostly employers who do. They should look for something which is good and solves their problems. I don't know how something with the attribute boring is of interest here as other attributes for a technology/PL might be much more important... Actually they mean something different with "boring": It is just a lack of courage for sim…

> we are scared of specialists and talent and want to stay mediocre

This arrogance is just so weird. A High-quality code base is easy to read and change. a.k.a simple. Redis is a good example of this. To have found the perfect abstraction, or perfect feature set fit, for a particular moment in time and feature set, may feel good but doesn't really matter.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#236

Earlier quoted context omitted.

Can't say for the rest, but Symfony 2 was a resounding success. Current Symfony 5 is very similar to Symfony 2, with just a ton of refinements and facelifts.

Oh yes, I'm not saying those are bad projects. What they have in common is that migrating from previous version to them was especially difficult and painful. The few symfony developers I know indeed loved symfony-2 very much. But migrating their projects from symfony-1 to symfony-2 was felt basically as a rewrite.

You're right, Symfony 1 -> Symfony 2 was definitely a rewrite, but from then on, the general design was kept almost intact (again, not counting the evolution and streamlining of the framework).

I guess the first attempt is always tricky, let's see if Go 2 can find a smooth upgrade path.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#237
post #73

Non-exported struct fields are a way of preventing your library from being composable. Checking if a value implements an interface is a way of writing surprising bugs. The standard library uses both of these features extensively, to give users bugs and prevent itself from being composable. Checking that the user uses all values bound to variables but letting them discard errors by not binding them to a variable is a…

Related complaint, the standard library taking structs as input is kind of annoying. I'm specifically thinking of net.Dialer having a net.Resolver, where that's a struct and not an interface, so it's difficult to sub in custom logic there (but still possible, at least, with some contortions). Single-binary deployment and (these days) good dependency tracking (downloading multiple versions of a library) is great; I do…

> incompatible version break would cause too much strife, much in the same way of python 3 / perl 6.

The Perl world has solved this by renaming Perl 6 to Raku (https://raku.org using the #rakulang tag on social media).

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#238
post #233
post #153

Earlier quoted context omitted.

> What does Go bring to the table? A still maintainable code base 5 years along.

No language will magically give you maintainability. I've worked on several year old golang projects and they've been terrible, made worse by the fact that golang doesn't scale well for teams or larger programs.

> No language will magically give you maintainability.

That's true. But Go will certainly help with it.

> made worse by the fact that golang doesn't scale well for teams or larger programs.

What? That's one of the major recognized selling points of Go.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#239
My experience with Go is positive. I transitioned to Go from Python (which we still use in some projects), but overall I started to prefer Go over python.

What I like about Go:

- explicit error handling, one is forced to write correct code and think how exactly the errors will be handled. I now prefer Go's approach over exceptions.

- code is readable, I can look at the code of my coworker and very quickly see what exactly it does.

- surprisingly, I found myself not missing OOP features

- If project is compilable on localhost, it will be compilable on the server... this is easy to achieve and also deployment is straightforward.

- it forces to write "stupidly simple" code. for example, it doesn't allow function parameters with default values. The consequence is, that I sometimes need to spend a little extra time on refactoring, but then have more readable code.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#240

When a struct implements an interface one has to keep guessing that it really does so (unlike Java, C++ there is nothing in the syntax of go that would show interface inheritance as a fact), and that really doesn't help the poor guys who have to read/understand/maintain some code. Why did they do that to a language that is based on interfaces?

While sometimes it would be nice to have a source-code confirmation, that struct Foo implements the interfaces Bar and Baz, there is one huge benefit of not requiring to declare the interfaces a struct implements: a struct can implement an interface the struct creator doesn't know about. So you can design new interfaces, which for example structs from the standard library or any third party library happen to implement. You don't have to change the original libraries for that. This is quite a benefit for modularity.
Post reply on HN