Hacker News Reader

Comment by treis | Hacker News Reader

>I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows.

My experience was similar. In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs.

The other thing that turned me off from Go was testing. It has good enough support for unit testing but it really lags behind in integration testing. Sometimes you want to know that if you hit this endpoint with this payload you get this response back. It's harder than it should be to write integration testing where you spin up the application and test it end to end.

View on HN

> In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs.

This is like comparing apples and oranges, or at least, like comparing apples and apple-orange hybrids :)

Just saying that Rails (RoR) has a command like byebug that opens an in-context REPL, seems to ignore the fact that compiled languages like Go catch many errors earlier, at compile time, so you don't even need an in-context REPL or a debugger to find those.

Not saying that features like byebug have no use at all, of course.

Yeah, and having access to a REPL can catch semantic and architecture issues before you finish integrating and fire up the whole application. As do testcases.

Compilation is not a magic bullet. Although, to be fair, I pushed Golang at work precisely because you have to compile it first. Not everyone is diligently testing their code...

>Yeah, and having access to a REPL can catch semantic and architecture issues before you finish integrating and fire up the whole application. As do testcases.

True about the semantic and testcases parts. Not clear how it helps with architecture.

There's gomacro, which is a Go REPL with debugging:

https://github.com/cosmos72/gomacro

It would be awesome to have a REPL in the standard Go distribution, and I definitely feel the lack: even Java now provides one (JShell).

>There's gomacro, which is a Go REPL with debugging: https://github.com/cosmos72/gomacro

Will check it out, thanks. Had just been thinking whether there is any Go interpreter some time ago. I remember C having at least one, back in the day.

>It would be awesome to have a REPL in the standard Go distribution, and I definitely feel the lack

Agreed. And it should be more like IPython (command-line version) than like the stock Python shell.

>even Java now provides one (JShell).

Good to know.

>This is like comparing apples and oranges, or at least, like comparing apples and apple-orange hybrids :)

>Just saying that Rails (RoR) has a command like byebug that opens an in-context REPL, seems to ignore the fact that compiled languages like Go catch many errors earlier, at compile time, so you don't even need an in-context REPL or a debugger to find those.

I definitely liked the type system of Go and the compile time errors it found. It gives you a lot of peace of mind and reduces some errors. However, those errors aren't the things I use byebug for. Byebug is for things like figuring out why your code went down Path A when you expected it to go down Path B. Or if you don't know how to do something it's a sandbox to try a few different things until you get the output you were looking for.

>Byebug is for things like figuring out why your code went down Path A when you expected it to go down Path B.

Got you now. The classic use case(s) of an REPL. I may have misunderstood your earlier comment, which is why in my own earlier on, I had said "seems".

Is this the same type system that famously forces you to cast items in your collections to the universal supertype?

Everyone's aware of the lack of generics, it's been rehashed to death. This is a discussion on Go 2, which will add them.

The current type system is poor, but still better than dynamic languages.

> which will add them.

"Generics" can be a lot of things in a lot of ways. AFAIK there is no official Go design for generics, or a list of the deficiencies they will have, so a blanket "this particular problem will of course be solved well" is speculative.

You know well that it is. Add /s or /rhetoric to your question next time :)

Languages can be pretty useful even if they are imperfect, as others have said. And Go is plenty useful. The Stroustrup quote about C++ comes to mind ...

Here you go:

https://en.wikiquote.org/wiki/Bjarne_Stroustrup

"There are only two kinds of languages: the ones people complain about and the ones nobody uses."

And here's a good set of Q&A from his FAQ; it includes the above quote too:

"Did you really say that?":

http://www.stroustrup.com/bs_faq.html#really-say-that

Elixir's IEx.pry/0 function, that opens a REPL at a particular point of execution, is probably the stdlib function I call the most while developing. In a compiled language, to boot.

Wow, that's cool. Wonder how it works. Does it spawn an instance of the REPL with your app and its current state?

I think the closet Go equivalent of 'byebug' would be delve[0].

It's got more of a learning curve than a REPL, but very powerful. Editor plugins for Go also tend to have good convenience support for delve, making using it less painful. For example, vim-go[1].

[0]: https://github.com/derekparker/delve/blob/master/Documentati...

[1]: https://github.com/fatih/vim-go/blob/master/doc/vim-go.txt#L...

> For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs.

Isn't that what a normal debugger does? Or am I simply just living in lala-land because of C#.NET/Visual Studios terrific debugging experience?

I remember php and the hell that was xdebug. It was much easier and more efficient to simply to a `var_dump` whenever you needed to debug.

Reply on news.ycombinator.com