Live data from Hacker News

I Love Go; I Hate Go

dtrace.org

171–180 of 329 posts

Re: I Love Go; I Hate Go

#171
post #163
post #160

I like Go quite a lot. Mainly I am a Lisp programmer, so I am not looking for the next most high level programming language. I am looking for a language which gets things done, where Lisp doesn't quite fit. For jobs, which traditionally would have been done in C. Programs that run fast and have a reasonable complexity. It brings back the virtues of the Wirth computer language family back into modern times, as with st…

I am really curious about the kind of tasks that are easily done in Go but for which Lisp doesn't quite fit.

Sometimes I like to have a fully statically typechecked program. You can do that in Lisp, its easier in Go. Also, it directly produces statically linked executables. You can do a lot of this in SBCL, it also produces executables, has type checking etc. But for some of this, you have to wrestle a bit with the Lisp system. The Common Lisp numeric tower is great - until you want to write low level programs where you just want to have machine word sized integers which may wrap around. I once even submitted an abstract to a Lisp conference addressing some of these issues, but as it was not accepted, this side-project was postponed (but I plan to revive it some day).

And of course, there is always the question of the environment. The Go universe has tons of libraries, actively developed.

Re: I Love Go; I Hate Go

#172

Earlier quoted context omitted.

> ignoring years of research and good ideas And people are falling over themselves to use Go in places that seem inappropriate. Most of Go's strengths shine in a large team of mediocre developers: Low build times, low abstraction, quick ramp-up, etc. So why do startups choose Go? You're just shooting yourself in the foot. Use OCaml, use C++, use Clojure, hell, use Swift or Rust, just use something that at least prete…

You don't know what you are talking about. Have you seen any Swift backend used in production? Would you use C++ for a web API? Go was developed because C++ is a horibble language and I'm glad it didn't adopt the expressiveness and abstraction from C++.

> Have you seen any Swift backend used in production?

Lots of iOS applications use it already.

> Would you use C++ for a web API?

Facebook and Google apparently do use it.

Re: I Love Go; I Hate Go

#173
post #164

Earlier quoted context omitted.

> It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. On top of that it adds memory safetey due to the presence of GC. Wirth's work also includes languages with GC. :)

And more modern features than Go, even if designed in the 90s...

Out of genuine interest: could you elaborate on those? I have mainly worked with Pascal/Modula-2, and only shortly glanced at Oberon, so I am a bit shaky on his "later works".

Re: I Love Go; I Hate Go

#174
post #35

Earlier quoted context omitted.

i was shocked by that at first too. Then I came to love it. It's sooooo go. Don't import stuff you aren't using. Don't declare a var and just leave it there un-used. When I go back to ruby and commit that crime, I see why golang did what it did. There's something magical about a golang program that will compile without error. It's worthy of checking in to git. And months later, there will be no unsed imports FOR SURE…

Stockholm syndrome in action. There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. If someone is not disciplined enough to throw out unused variables/imports/whatever from release, Go will not save him from hell.

This may work for you code. But are you sure that all the libraries you use also follow that rule? Are you going to audit all of those projects and their dependencies to validate they follow the same best practices as you?

The end result of Go's opinion on warnings is that you know a certain class of bugs in not present anywhere in both your code and all of your dependencies. While it's true that people and teams that follow the best practices around warnings also tend to follow the best practices for other things but there is no guarantee for the ecosystem in a language that allows warnings, and no project lives in a vacuum.

Re: I Love Go; I Hate Go

#175

Earlier quoted context omitted.

> So you are trying to add some negative moment about borrow-checker, when my comment is not about borrow-checker, but you need something negative. Cheap trick. Now what the hell are you talking about? I didn't reply to your comment I replied to valarauca1, they're the one who mentioned the borrow checker, if you're unhappy about that whine to them don't include me in your pity party.

Are you drunk? You are responding to the branch my comment started, comment was about error messages and your response contain words: "And while many Rust messages are OK, one should be careful not to confuse familiarity with Rust's error messages[0] with Rust's error messages being good (being inherently informative and good)." So you will still try to pretend we are not talking about error messages here?

> Are you drunk?

I'd appreciate you not insulting me, as well as you starting to make sense.

> You are responding to the branch my comment started

I was not, however, replying to your comment. As I already told you I was replying to valarauca1's comment, which is why my own comment was threaded below and in reply to it, and quoted it.

> So you will still try to pretend we are not talking about error messages here?

I'll repeat my previous query in a new context and with slightly more alarm: what the hell are you talking about?

I never "tried to pretend"[0] we were not talking about error messages, my answer[1] to your original query[2] specifically noted the opposite.

[0] and would again appreciate not being insulted

[1] https://news.ycombinator.com/item?id=12209010

[2] https://news.ycombinator.com/item?id=12208873

Re: I Love Go; I Hate Go

#176
post #10

The most frustrating thing for me, by far, is that Go won't let you import unused packages. When you are commenting stuff out to debug a program, or adding debug statements and removing them later, it constantly requires you to go back to the top of the file and comment out the unused libraries, only to uncomment them later when you've solved your problem. The fact that there is not a compiler flag to disable this be…

It's a simple reflection of the fact that the Go creators have never used a modern IDE. Anyone using a modern IDE pretty much never even thinks about imports, which are (and should be) automatically managed by the tool, not by the programmer.

This statement is probably true but that's kind of irrelevant. IMO it is actually a virtue of the language if it is perfectly usable without a modern IDE. Contrast that with Java and you'll see what I mean. Go follows the Unix philosophy where things like imports or formatting can be supplied by any external tool. If you wish to bundle all these small tools into a single IDE you can do it, too.

Re: I Love Go; I Hate Go

#177
post #41

Earlier quoted context omitted.

You get warnings for lots of things in C. There's no getting around the use requirement in Go, at least not without crudding up your code.

I prefer what I do with Python in this regard: The IDE shows me unused variables, I can run my code with them, but I can't commit since the linting hook will produce a hard error at commit-time if something's wrong. It's not as easy to do with a compiled language, of course, but I don't think it would be over the top to have the compiler exit with a non-success code if there are warnings when building. The "warning f…

> I prefer what I do with Python in this regard: The IDE shows me unused variables, I can run my code with them, but I can't commit since the linting hook will produce a hard error at commit-time if something's wrong.

The problem is that while you do that, essentially no-one else on the planet does — and anyone who uses a library thus has to deal with the fact that that library has approximately a 100% chance of having nits like unused variables.

Re: I Love Go; I Hate Go

#178

Earlier quoted context omitted.

Devil's advocate: if you can disable -Werror, then users will disable -Werror, and we'll end up in a C-like situation where everything warns all the time, and real problems get buried. Better to inflict some pain during development if it keeps the Go source corpus hygienic. One under-appreciated consequence is that this policy limits Go to one implementation. Say I write an alternative implementation of Go, that has…

> Devil's advocate: if you can disable -Werror, then users will disable -Werror, and we'll end up in a C-like situation where everything warns all the time, and real problems get buried. Isn't it implied that programmers are adults?

> Isn't it implied that programmers are adults?

It's one of those irregular situations:

I'm a senior developer.

You're an adult programmer.

He's a stark raving juvenile lunatic.

Re: I Love Go; I Hate Go

#179
post #35

Earlier quoted context omitted.

Stockholm syndrome in action. There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. If someone is not disciplined enough to throw out unused variables/imports/whatever from release, Go will not save him from hell.

> There are two phases: active development and release > engineering. For you, perhaps. Go encourages you to think about your problem and develop it in the "release engineering" style from the very beginning. This is a virtue of the language, in my view.

No, there is no encouragement here. Go forces you to treat things that have always been just warnings in other languages as errors. And I wouldn't call a virtue something that doesn't give you a choice. I will be really pissed off if the language thinks that I'm so idiot that I need errors instead of simple warnings for the cases discussed here.

Re: I Love Go; I Hate Go

#180
post #172

Earlier quoted context omitted.

You don't know what you are talking about. Have you seen any Swift backend used in production? Would you use C++ for a web API? Go was developed because C++ is a horibble language and I'm glad it didn't adopt the expressiveness and abstraction from C++.

> Have you seen any Swift backend used in production? Lots of iOS applications use it already. > Would you use C++ for a web API? Facebook and Google apparently do use it.

And Google is actively replacing a lot of those with Go because using C++ for a web api is painful.
Post reply on HN