3 ms·
If you don't have trouble switching between Go and Python, then the concept of Neugram has much less to offer you than me. Possibly you don't because you use b
by crawshaw 9y ago
If you don't have trouble switching between Go and Python, then the concept of Neugram has much less to offer you than me.
Possibly you don't because you use both languages more than me. My scripting needs are approximately once every other week, sometimes even longer. That's enough time for me to forget what python package has the date/time functions I need.
I also wouldn't even begin to compare something in its infancy like Neugram with something as well-established as Python's huge collection of libraries. There are many years of work between here and there.
- wybiral 9y ago> Possibly you don't because you use both languages more than me. It depends what the client or project demands. I've worked in Python, Javascript, PHP, VBA, Java, Go, and C (plus a few dialects of SQL). Spending months writing mostly one or two of those at a time. The only ones I enjoy enough to use in my hobby projects are Python, Javascript, and Go. But in my experience the hardest part of toggling between languages like that is the ecosystem (libraries and tools). In this case it seems like you're adding a new ecosystem which means I'd still have to stop and figure out "what's the right package to use for this?" For the most part, language is easy. It's the idioms, libraries, and tools that I find myself googling the most.
- crawshaw 9y agoMy goal is very much to reuse Go packages. It is somewhat working today. The underlying mechanism is when you type something like: import "github.com/pkg/errors" A .go wrapper file is generated, a Go plugin is built, and then loaded into the ng executable. You can then use the errors package in the Neugram evaluator. Under the hood the lifting is done by the reflect package. Very much my goal is when scripting, to use the os.Open and ioutil.ReadFile I know, along with filepath.Join, time.Now, and friends.