Hacker News Reader

> Like, you do 'assert.equals(x,y)', and it doesn't even show you what the values of x and y are, let alone figure out that maybe "x!=y" would be an obvious thing to print.

That's why pytest is my buddy. You don't use any odd method, you just write `assert x == y` and if it fails it tells you that it fails, and what the operands were:

        def test_py():
            a = geta()
            b = getb()
    >       assert a == b
    E       assert 7 == 467

if you add an assertion message, it just gets added to the output:

        def test_py():
            a = geta()
            b = getb()
    >       assert a == b, "assertion message"
    E       AssertionError: assertion message
    E       assert 99 == 343

It also tends to show local variables and function arguments. It also has --pdb.

This makes debugging without --pdb pretty easy in most cases: http://i.imgur.com/IqRzKnG.png

pytest gets a lot of stuff right, though it also has many faults (like almost any piece of software).

pytest is great, but a just a bit too much magic for me. And I really don't like it when you pass a user defined failure message, you lose all this nice introspection.

With unittest, longMessage = True + my own failure message with the info I want gets me where I need to be. That being said, it is more work/boilerplate.

https://docs.python.org/2/library/unittest.html#unittest.Tes...

Python 3 has subtest, which gives you built in parameterized testing. I have no idea why this was not backported to 2.7, so you must used pytest or nose_parameterized or ddt.

https://docs.python.org/3/library/unittest.html#unittest.Tes...

> pytest is great, but a just a bit too much magic for me.

There isn't much magic there, just an import hook which rewrites the assertion during compilation.

> And I really don't like it when you pass a user defined failure message, you lose all this nice introspection.

Er… you don't, that's what the second snippet shows: if you have a custom assertion message, it just prints the message alongside everything else…

> Er… you don't, that's what the second snippet shows: if you have a custom assertion message, it just prints the message alongside everything else…

Is that a new addition to pytest? I do seem to remember the user defined message stomping over whatever pytest would normally spit out.

That seems to have been fixed in version 2.6.2 released in September 2014[0]:

> Implement issue549: user-provided assertion messages now no longer replace the py.test introspection message but are shown in addition to them.

[0] https://docs.pytest.org/en/latest/changelog.html#id228

cool, thanks for clearing that up for me.

This is because Python makes it excessively easy to analyze call stack. It may be the case for many other VM-based runtimes, like Ruby or JVM, but it's hardly feasible in Go.

> This is because Python makes it excessively easy to analyze call stack.

Wrong. Pytest uses AST rewriting to inject debugging information, introspection has not been the default mechanism for years[0], and was removed entirely in pytest 3.0 (released mid-2016).

> It may be the case for many other VM-based runtimes, like Ruby or JVM, but it's hardly feasible in Go.

Wrong again, see above, as long as you can statically inspect a function body and rewrite an assertion statement you can do what pytest does.

[0] I think rewriting was made the default as soon as it landed back in 2011 but am not actually certain

Wow... I am using Django's stock test runner and that makes me jealous. I've wished I could just write python asserts and have it print useful information.

Of course, this technique only works in dynamic languages. In Go I use testify assert and that is good enough for me.

> Of course, this technique only works in dynamic languages.

Actually, pytest does that by rewriting the AST[0], basically it rewrites the `assert` statement into a more complex form which extracts all the info it needs upon failure. In a statically typed language, you could do that with a compilation hook and some codegen.

There used to be a "reinterpret" mode where it would walk the stack frame and try to understand the expression involved at runtime, that was removed in Pytest 3.0, now the choices are assert-rewriting and plain assert (without any introspection).

[0] http://pybites.blogspot.be/2011/07/behind-scenes-of-pytests-...

> Of course, this technique only works in dynamic language

It can work in any language that supports reflection, dynamic or not.

Or macros, or just direct language (i.e. compiler) support.

Just switch to pytest + pytest-django. It can run Django tests.

Slightly related:

The lack of an easy to use debugger is a huge issue for me when working with go.

Coming from PHP, I spend 90% of my time in the debugger running my code line by lines (with xdebug coupled to phpstorm).

A debugger is especially useful when working with other's people code and large softwares. For example, contributing to large Go projects like Kubernetes can be daunting due to the very steep learning curve. This curve would be greatly reduced if we had a good reliable go debugger, which doesn't seem to be the case at the moment. (I'm aware of delve, but last time I looked, it was still fairly complicated to have it work).

https://www.jetbrains.com/go/features/

How long ago was that? 'cause it seems pretty easy to get running now, even on Windows.

Delve only works on Linux, OSX, and Windows. Not at all on *BSD.

∙ Delve works "ok-ish" on Linux. Sometimes breakpoints don't fire (for me), but generally it's mostly usable.

∙ Windows and OSX both have issues with (at least) cgo code.

∙ The lack of BSD support is just because no-one's contributed the native bits yet:

    https://github.com/derekparker/delve/tree/master/pkg/proc/native

So, it'll probably get done at some point in the future.

As an example of the problems, a basic search on the Jetbrains issue tracker for Gogland (which includes Delve) shows many, many, many bugs filed.

  https://youtrack.jetbrains.com/issues/GO?q=debugger

eg breakpoints not firing, variables being shown outside their scope, variable names being incorrect, debugging session just hanging (etc)

That being said, the problems are getting looked at and fixed, both by the Delve dev's, the Jetbrains people for things where Gogland can help, and in Go itself when problems originate there (incomplete DWARF info on some OS's for example). Go 1.9 (due for release any day now) helps with the variable scope problems.

Still, it's a long way from "just works" to the level C developers are used to. Though it's improving. Personally, I really wish the "just works" was already here. :D

Have you looked at Delve? I haven't personally tried it, but it works well with VS Code for line by line debugging.

I've strangely found success without even worrying about line by line debugging. Typically, unit tests and the occasional printf debug has done well enough for me.

there is a debugger for Go

https://github.com/derekparker/delve

you can step through things and print stuff out

How is the debug experience in elixir compared to go ?

Erlang/Elixir debugging is world-class. You can directly instrument functions running in production with fairly little overhead.

I highly suggest reading "Erlang in Anger" by ferd/MononQC. It (and his recon library) are indispensable tools for people running Erlang or Elixir in prod.

How on earth is it world class if you can't do line by line or step debugging?

You can? The Erlang debugger has been there since at least R10....

I have to admit, although I use domain specific debuggers sometimes (gdb, debuggers of IDEs), I mostly debug via print-statements, as it just works in most scenarios.

Am I missing out? AFAIK step-back debuggers are still more research (I think Elm has something like this), but otherwise I just want to have system snapshots and there print($foobar) works very well for me across languages.

Elm used to have a crazy time-traveling debugger in elm-reactor[0], but that's been replaced by session-event-export[1].

This is really, really easy to do well when every function is pure and every data structure is immutable, and you use an MVC/Event-sourced/FRP architecture for (more-or-less) all control flow. Of course, Elm enforces all of these things.

I've written / worked on other systems (e.g. accounting / transaction pipelines) in other, less safe languages and implementing a shoddy version of this is really straightforward and immensely useful.

That said, with pure functions and immutable data structures, you don't really need a debugger for the same reasons, or indeed nearly as often, as in less safe languages.

[0]: http://debug.elm-lang.org/ [1]: http://elm-lang.org/blog/the-perfect-bug-report

Yeah, you're missing out. :)

Print statement style debugging can (with effort) get a lot of stuff figured out.

But :), it's often fairly slow to go through that iteration cycle with non-trivial bugs, compared to using a debugger.

With a debugger, you start from the same place in your code you'd put your print statements. But instead of modifying the code to spit out values, the debugger will pass control of the running program to you. You can then go forwards through your program, seeing how the variable values change, which branches are taken, etc.

It'll get you to the same end result as the print statements, but faster.

Also, for complicated/hairy/weird bugs, being able to follow the actual execution can be enlightening which print statements don't really do.

:)

Some time ago I did more Java and used Eclipse heavily and its debugger was really nice, so I share your opinion that you get nice features.

However if you are working on a project (at least that has been my experience so far) that does a lot of multiprocessing (let's say a web service with a processing scheduler in the background calling into processes implemented by different languages) and you may have bugs on several layers using different programming languages, I like the fact that I can use the same concept for all of them and write some custom "debug.log" that I can later analyze (obviously good logging in the first place can help a lot).

But I may check them again: Do modern debuggers work across languages (assuming available source), let's say web-request -> Python -> FFI -> C++?

Previously such scenarios have been non-trivial to debug (although there are some pretty advanced multithreaded code analyzers now), but maybe it has changed for the better.

> But I may check them again: Do modern debuggers work across languages (assuming available source), let's say web-request -> Python -> FFI -> C++?

Gah... no idea. I'm still doing mostly doing single language stuff. :D

The kind of request path you're mentioning there... yeah, I'd probably go back to using print statements too, as I'd have no idea how to hand off from one language to another in some kind of meta-language-debugger. Which would actually be nifty if it exists.

They do for Java-> C++, .NET -> C++ and Swift->Objective-C->C++.

I don't think it's meaningful to compare.

Erlang/Elixir work with immutable values, so when you call a function, assuming it's side-effect free, you always get the same result.

Add to that the fact that there are no global variables (outside of table-like things like ETS), and that you can jump on the running system in an Erlang/Elixir shell and call any exported function and immediately see the results, debugging becomes much, much easier. I can honestly say that I have not needed a stepping-style symbolic debugger since 2008.

And when you find and fix a bug, you can copy the fixed code file (.beam file) to the server, start a remote shell, and do this:

    > l(my_module).

and the new code is running, with no perceptible perturbation to the system.

There are also other tools like dbg that let you monitor calls to specific module/functions based on pattern matches. The representation of these pattern matches is powerful but not so pretty - but it gets the job done.

Nothing's a panacea, and Erlang/Elixir undoubtedly have their warts, but for the Erlang VM's use case - soft real-time, extremely robust, highly concurrent distributed systems - I believe they are peerless.

One of the warts may be that the ecosystem doesn't have a library for every possible scenario, but that's improving rapidly, and in many cases, some of these are trivial to write. On the plus side, the quality of code is generally pretty good.

It is very challenging to describe what a massive level of confidence a hybrid-functional, battle-tested language and environment like this affords a system designer.

So debugging in this environment is very different and hard to compare directly to a line-by-line stepping debugger. Even if such a tool may be available (and things change so quickly these days, I probably missed that), it's easier to do without it.

It's so difficult to convey the experience of using this ecosystem, one cannot do it justice in a HN comment. T be fair, there are so many mature tools in more heavily used ecosystems like (I suppose) Java, that some may give up on Erlang/Elixir prematurely if used to that level of tooling.

Elixir does an amazing job of showing you why a test failed, but as for debugging, up until the latest release, 1.5, there wasn't really a debugger, it had pry, which lets you play around in the environment at the point where pry is called, but you can't step though code. 1.5 introduced a more useful debugging experience, but you can't step line by line, you can only step from breakpoint to breakpoint as far as I'm aware, but I haven't played much with it yet. It's getting there though! I should note that I haven't really lamented the lack of a good debugger, and I came from .NET where I had one of the best debuggers available.

How is the performance of Elixer vs Go? I’ve done some web stuff with Go and I like the performance. Elixir looks interesting. Wanted a reason to give it a try.

They are not paragonable.

Anyhow there are different reason to learn a new languange if ir change the way you think.

For me those languanges were

1. C learn to code

2. Python learn that there are more way to write code than C

3. Clojure keep everything as simple as possible

4. Elixir stuff fail, find a way to deal with it

5. Rust get as much help as possible as soon as possible from the tools that you use (namely the compiler.)

Now in whatever languange I write I bring with me those experiences. So I search to solve the problem in the simplest possible way keeping an eye on the reliability and I let my tools do as much as possible of all the heavy lifting...

All this just to say to give elixir a run that will make you a better r developer :)

Now my code in any languange

Here's a link to benchmarks of different languages including Elixir. https://github.com/kostya/benchmarks

Erlang's graphical debugger works with Elixir since OTP-19 (last year). See this page after the section on Pry:

http://blog.plataformatec.com.br/2016/04/debugging-technique...

It supports stepping, etc.

Great. 1.5 which was just released really helps with pattern matching failures and gives suggestions. I really like testing with elixir.

This is why I love Elixir. It comes with tests as a first-class citizen. Colors! Line numbers! Visual grep! DEVELOPER UX. Check this out:

http://i.imgur.com/qDPE9Pc.png

Came out of private mode on my phone to upvote this.

One key point I'd like to add though is that you must _always_ run git diff before committing anything. There's been enough times where that has saved me from erraneously committing logging statements that are absolutely unnecessary post bug fix.

You can also use a different function for temporary debug prints, and a git pre-commit hook that fails if this function is invoked.

Pros: Easier to insure that your collaborators follow process; your CI server can run it too.

Con: This doesn't catch other issues that a manual `git diff` review will also catch.

Getting into the habit of always adding via `git add -p` is useful to stop this from happening.

Yea commiting by hunks is also super useful. I find a lot of engineers only have a cursory understanding of a lot of git. Rebase vs merge throws a lot of people off and not a lot of people know about git bisect which is just incredibly useful. I think some of it is that people like the graphical nature of things like sourcetree which while offering pretty interfaces don't fully flesh out git. Give me the command line any day.

It's better to do the big commit and then refactor it. Otherwise you won't have tested whether the hunks depend on each other, which means history littered with broken commits.

"Golang drops GOPATH" - I am waiting for this headline.

The biggest hurdle with Golang and working on different unrelated projects that are in their own GIT repo. Golang forces you to have one single path were all the code should reside - GOPATH. Name me one other language that has such a restrictive requirement. Why not offer a config?? Beside that I like everything else about Go a lot.

> The biggest hurdle with Golang and working on different unrelated projects that are in their own GIT repo. Golang forces you to have one single path were all the code should reside - GOPATH.

No one forces you to have one single path where your code should reside. It's just an environment variable, so you can have a GOPATH set per project if you wish. It could be your git root.

> Why not offer a config??

That's what they did, or what am I missing?

Not really. :)

These are the Go .bashrc lines in my Linux dev desktop:

    export GOPATH=${HOME}/go:${HOME}/git_repos
    export GOBIN=${HOME}/git_repos/bin
    export PATH=$PATH:/usr/local/go/bin:${HOME}/go/bin:${HOME}/git_repos/bin

Note the two different paths in GOPATH?

∙ $HOME/go is where "go get foo" puts stuff

∙ $HOME/git_repos is where stuff I'm developing goes (eg $HOME/git_repos/src/github.com/sqlitebrowser/dbhub.io)

The separation means I can backup stuff I'm working on, and exclude the general downloaded Go code from backups as that would just be a waste of space.

Most people do seem to use just one path in GOPATH though, and I remember also doing things that way when first starting out. Not sure why, maybe it's due to some incorrect assumptions given by the Go learning material commonly read when starting out?

Good idea, but it doesn't work for me.

I can't understand the GOPATH restriction, I want to put the Go source code where I want. Think about the following projects (Win/Linux doesn't matter, I use both)

One GOPATH doesn't work when you have several projects in different structures e.g.

* D:\Projects\ABC\repo\server\go\src\

* D:\Projects\XYZ\git\backend\go\src\

* T:\svn\go\src\

Rename Projects to "src" and set GOPATH to D:/.

Yeah, I remember it was a pita for me to change my directory layout habits to work ok with Go. Maybe it'll become more flexible in future. :)

The GOPATH system blows for the learning curve, but it's good for a lot of other reasons, like being very simple to understand and reason about. I don't really enjoy the way Node.js and Python handle package management personally, because it can get complicated. But I've wondered why someone hadn't wired up Go with an npm style package manager, since it would totally be doable.

The Go team does seem to care about the problem though, and they at least made a sane default Go path of $HOME/go, so you can go get right away.

In my project I use "env GOPATH=$PWD go ..." in the makefile, that way it all goes in the current directory. There's probably some good reason this is a bad idea, but go is kinda funky anyway so I make up my own best practices :-)

Have a look at virtualgo

https://github.com/getstream/vg

> As far as I can tell you can’t step through tests in the debugger

Actually, you can, if your IDE lets you. Eg. In Intellij if you're using the Go plugin, you will see little green arrow in the margins of your tests. Set a breakpoint and click the little arrow. The new Gogland IDE has this too.