5 ms·

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 run

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).

abledon 9y ago
How is the debug experience in elixir compared to go ?
- hlieberman 9y ago
  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.
  - hak8or 9y ago
    How on earth is it world class if you can't do line by line or step debugging?
    - hlieberman 9y ago
      You can? The Erlang debugger has been there since at least R10....
- deleted 9y ago
  [deleted]
- bitwalker 9y ago
  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.
  - ramchip 9y ago
    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-techniques-in-elixir-lang/ http://blog.plataformatec.com.br/2016/04/debugging-technique... It supports stepping, etc.
  - melling 9y ago
    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.
    - hack4supper 9y ago
      Here's a link to benchmarks of different languages including Elixir. https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks
    - siscia 9y ago
      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
- defined 9y ago
  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.
- thejosh 9y ago
  Great. 1.5 which was just released really helps with pattern matching failures and gives suggestions. I really like testing with elixir.
- zeptomu 9y ago
  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.
  - ves 9y ago
    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/ http://debug.elm-lang.org/ [1]: http://elm-lang.org/blog/the-perfect-bug-report http://elm-lang.org/blog/the-perfect-bug-report
  - justinclift 9y ago
    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.
    - zeptomu 9y ago
      :) 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.
pkroll 9y ago
How long ago was that? 'cause it seems pretty easy to get running now, even on Windows.
- justinclift 9y ago
  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
jchw 9y ago
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.
erikbye 9y ago
https://www.jetbrains.com/go/features/ https://www.jetbrains.com/go/features/
tmaly 9y ago
there is a debugger for Go https://github.com/derekparker/delve https://github.com/derekparker/delve you can step through things and print stuff out

abledon 9y ago

How is the debug experience in elixir compared to go ?

hlieberman 9y ago
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.
- hak8or 9y ago
  How on earth is it world class if you can't do line by line or step debugging?
  - hlieberman 9y ago
    You can? The Erlang debugger has been there since at least R10....
deleted 9y ago
[deleted]
bitwalker 9y ago
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.
- ramchip 9y ago
  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-techniques-in-elixir-lang/ http://blog.plataformatec.com.br/2016/04/debugging-technique... It supports stepping, etc.
- melling 9y ago
  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.
  - hack4supper 9y ago
    Here's a link to benchmarks of different languages including Elixir. https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks
  - siscia 9y ago
    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
defined 9y ago
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.
thejosh 9y ago
Great. 1.5 which was just released really helps with pattern matching failures and gives suggestions. I really like testing with elixir.
zeptomu 9y ago
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.
- ves 9y ago
  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/ http://debug.elm-lang.org/ [1]: http://elm-lang.org/blog/the-perfect-bug-report http://elm-lang.org/blog/the-perfect-bug-report
- justinclift 9y ago
  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.
  - zeptomu 9y ago
    :) 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.

pkroll 9y ago

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

justinclift 9y ago
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

jchw 9y ago

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.

erikbye 9y ago

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

tmaly 9y ago

there is a debugger for Go https://github.com/derekparker/delve https://github.com/derekparker/delve you can step through things and print stuff out