Hacker News Reader

Comment by thinxer | Hacker News Reader

I don't see the point of writing a machine learning package in Go.

Go is designed for system programming, which is the opposite of scripting. In scientific computing, interactivity is an important feature. Softwares like MATLAB and IPython(now Jupyter) become popular because of this. Go doesn't have a nice REPL like IPython, and it never will. Besides, Go doesn't allow operator overload, which leads to verbose programs. Compare `c = a @ b` with `c := Must(Mul(a, b))`, the former Python statement is much cleaner than the Go one.

Usually, researchers use MATLAB, R, and Python for prototyping and training. The final model will be put into production by using something like TensorFlow Serving or by hand written C++ for performance. Even if the final product uses Go for serving, the Go program mostly runs the model via cgo or RPC.

Write in C/C++, and wrap the library in Python and Go is a much saner option. TensorFlow and MXNet are both good examples.

View on HN

I've been

> scientific computing

for quite some time, and I've the value of a REPL steadily in decline: what's far more useful is a tested code snippet or function & a debugger, occasionally.

Also, if a scientific stack were available in Go, I'd jump on it, because deploying Go is so much simpler than Python. Python's deployment story for scientific software often starts with either )a) create the perfect storm of dependency versions or (b) use Anaconda. Even MATLAB is way better in this regard.

In fairness, "use Anaconda" usually nullifies this dependency / deployment problem completely.

The "perfect storm of dependency versions" is a problem in Go as well though?

Not in practice. The vendoring solution that they are standardizing on makes versioning issues very manageable.

Which solution is this? Do you have any links or more information about that spesifically?

https://github.com/golang/go/wiki/PackageManagementTools

out of interest, what do you find lacking in https://github.com/gonum offering as a scientific stack?

I agree with you in general. However, I contend that people are lazy. Part of the reason why I wrote Gorgonia was because I spent waay too long trying to deploy theano on the cloud (this was circa 2 years ago).

Also, thanks for informing me about MXNet. I've never seen that before. Kinda cool.

> I don't see the point of writing a machine learning package in Go.

If nothing else, to prove a point that there are solid alternatives to C and C++, in memory safe languages.

If the point is feasibility, Java has shown us that for a long time...unless we consider the null pointer evidence of something not memory safe.

Not only feasibility, but having a GC enabled programming language with AOT compilation to native code (until Java 10, you will need to buy such compilers as the FOSS aren't as good).

After all the OP mentioned that only C and C++ were valid alternatives, hence why it is so important to implement such tools in other safer languages.

If people don't do it, as usual there will be a myth that only those languages are able to produce such type of applications.

Similar to the myth that C was the first systems programming language, when many of us were using something else before UNIX got widespread in the industry.

This is starting to seem fairly specific -- machine learning with memory safe languages that have AOT compilation to native code. It's not even, memory-safe languages that are performant -- because Java would totally match that requirement.

What I'm suggesting here is that there is nothing really remarkable about it, from either a research or implementation perspective, given the achievements of the Java community in recent years.

Interactivity can be an important feature for scientific programming, but so is having correct underlying algorithms that are implemented in a clean, composable way. Go is a good language for such implementations.

> Go doesn't have a nice REPL like IPython, and it never will.

https://github.com/gopherds/gophernotes

> Go doesn't have a nice REPL like IPython, and it never will.

https://github.com/motemen/gore

There are a few others too.

It's not a real repl. It just records everything you've typed, puts it in a file, and compiles and runs it. It does that every time you add a new line. It's a huge hack and doesn't behave like you'd expect at all.

https://godoc.org/golang.org/x/tools/go/ssa/interp

Yes, but that's not exactly a REPL, is it? It's just an incomplete tool that may someday be used to create a REPL.

Go is not set up to have a REPL; even if someone develops one someday it's always going to be limited compared to a language that was designed to do it. REPLs are actually pretty hard; even some languages designed with them from day one (or at least very early) like Haskell still come with an interesting list of caveats about the REPL.

I beg to differ. See: https://github.com/sbinet/igo

It is a true REPL (not like "gore", mentioned somewhere in that thread). It doesn't implement the whole Go specs, but there's AFAICT nothing in the Go specs that prevent `igo` to implement the whole Go specs. It's "just" work. Moreover, with the introduction of the "buildmode=plugin" in the yet-to-be-released Go-1.8, import-ing packages on the fly should be easy implementable.

("my" new vehicle to provide a true REPL for Go is at https://github.com/go-interpreter)

If you have to link to a different project, then the link I was saying is not a REPL is not a REPL, no?

Further, I'd suggest waiting for one of these projects to complete before you confidently declare that the REPL will be great. I didn't say it's impossible, I said "it's always going to be limited compared to a language that was designed to do it". I looked into what it would take to make a REPL around the Go 1.2 timeframe. There are many issues, such as the inability to query a package for what symbols it has, or the way the obvious workarounds have their own problems, brought on for instance by the fact that you can't re-export symbols in another package so the whole "just keep compiling a module incrementally" has its own issues. At this point I'm pretty confident that the best reasonably-possible Go REPL (i.e., not one that basically reimplements Go again) is going to come with a list of caveats a mile long. And if you do reimplement Go for the REPL, which a SSA interpreter basically is, you don't really have a Go REPL... you have a Go-like REPL at best.

I was challenging your "Go is not set up to have a REPL" assertion. we are in violent agreement about the (non) "REPL-ness" of _gore_ and the fact that "just keep compiling a module incrementally" is a dead end.

I don't see how reimplementing Go in Go but with a REPL (on top of, let's say, a SSA interpreter) is a Go-like REPL at best and not just a Go REPL. Could you expand a bit?

AFAICT, once one has a Go interpreter (the x/go/ssa is basically just that), implementing a REPL is "just" providing a program counter to the interactive interpreter layer, together with the ability to modify that PC... (many details have been dropped on the floor, of course)

Bold statement. https://github.com/go-interpreter/proposal/issues/1

The problem I see with it is not so much that you don't want a native, compiled implementation of a machine learning as that you want to be able to call it from Python, MatLAB and R. It is somewhat less straightforward to go Python<->Go than Python<->C or even Python<->Rust.

https://github.com/go-python/gopy

it automatically creates a CPython-2 extension module out of a Go-1.5 package.

I plan to update it for Go>=1.6 and also directly generate a "cffi" python module so CPython-{2,3} and PyPy can be directly supported out of the box.

Woah.

Sorry, I have nothing of substance to say, but this deserves more than an upvote.

FWIW: there is a virtual identical golang equiv to Jupyter in the golang tour (which is all open source).

FWIW: You can use Go in Jupyter https://github.com/gopherds/gophernotes

you can even use it on the web: https://github.com/gopherds/mybinder-go

Reply on news.ycombinator.com