Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Modules in 2019

blog.golang.org

Post reply on HN
Print view View original

11–20 of 178 posts

Re: Go Modules in 2019

#11

Post by crimsonalucard »

llimllib wrote: post #6
plg wrote: post #4

I really want to get into Go, I like that it's opinionated, I like that it's compiled, I like that it's garbage-collected, I like that coroutines are built-in. My primary use case is scientific computing, both data processing and interactive visualization. I know Julia is an option as well. For reasons I don't want to bother getting into I dislike Python. Thoughts?

It's not well-suited to scientific computing at all. I use and like Go for writing network servers and ETL processes. In a scientific context though, the type system is awkward in the extreme, there is essentially no library of modules, and the interactive visualization story is nonexistent. Python, R, Julia, even C++ would be better options IMO. (I'll clarify again: I like Go! I just think it's not well suited for t…

Agreed. For data stuff if you want type saftey you really need a language with support for recursive types. More languages lack this feature than have it.

Re: Go Modules in 2019

#12

Post by weberc2 »

treve wrote: post #8

One of the thing that's always been a bit off-putting about the Go community and leadership is that it seemed that when I came across things that I perceived as flaws in the tooling or language, I often felt told off and was made to feel that it's me who is wrong for a variety of reasons. Examples of this include GOPATH, the package infrastructure, error handling, lack of generics. Rob Pike disagrees so I must be wro…

I don't know. While no doubt some individual conversations have played out this way (law of averages and all that), I think this is a bad way to characterize the overall conversation. From my viewpoint, the conversation is largely people coming from other languages telling the Go community its way is wrong while the people on the Go team argue that there are tradeoffs that they'd like to explore. For example, pretty much every Go-related conversation over at /r/programming seems to have someone arguing that it's literally impossible to build software in a language that lacks generics (or exceptions) while people from the Go community argue that generics are probably worth the tradeoff, and then only if the maintainers can figure out a way to implement generics _well_ (i.e., not like C++ or Java).

Re: Go Modules in 2019

#13

Post by innagadadavida »

plg wrote: post #4

I really want to get into Go, I like that it's opinionated, I like that it's compiled, I like that it's garbage-collected, I like that coroutines are built-in. My primary use case is scientific computing, both data processing and interactive visualization. I know Julia is an option as well. For reasons I don't want to bother getting into I dislike Python. Thoughts?

Python has a huge ecosystem for this and levering it is a good idea. In one of the projects I'm working on, I train and test tensorflow models in Python but load it in Go for inference - these types of hybrid approaches can work great for scientific computation.

Re: Go Modules in 2019

#14

Post by DannyBee »

stcredzero wrote: post #10
llimllib wrote: post #6

Earlier quoted context omitted.

It's not well-suited to scientific computing at all. I use and like Go for writing network servers and ETL processes. In a scientific context though, the type system is awkward in the extreme, there is essentially no library of modules, and the interactive visualization story is nonexistent. Python, R, Julia, even C++ would be better options IMO. (I'll clarify again: I like Go! I just think it's not well suited for t…

If one wants to be a pioneer and be one of the people who starts the movement, now is the time to jump in and make a name for yourself.

This is absolutely true. It's also a lot of work :)

Re: Go Modules in 2019

#15

Post by petre »

plg wrote: post #4

I really want to get into Go, I like that it's opinionated, I like that it's compiled, I like that it's garbage-collected, I like that coroutines are built-in. My primary use case is scientific computing, both data processing and interactive visualization. I know Julia is an option as well. For reasons I don't want to bother getting into I dislike Python. Thoughts?

Dlang is better suited for that use case. Have you looked at mir?

Re: Go Modules in 2019

#16

Post by jerf »

stcredzero wrote: post #10
llimllib wrote: post #6

Earlier quoted context omitted.

It's not well-suited to scientific computing at all. I use and like Go for writing network servers and ETL processes. In a scientific context though, the type system is awkward in the extreme, there is essentially no library of modules, and the interactive visualization story is nonexistent. Python, R, Julia, even C++ would be better options IMO. (I'll clarify again: I like Go! I just think it's not well suited for t…

If one wants to be a pioneer and be one of the people who starts the movement, now is the time to jump in and make a name for yourself.

I'd suggest "now" is actually a terrible time to try to make Go do scientific computing. With generics all-but-guaranteed to be incoming, but also not here yet, a lot of what you would do is going to be superceded in the forseeable future, on the same sort of time scale as your library's expected completion date.

I'd say that even once Go has generics, that will simply take it from being an awful scientific programming language to a mediocre one. I don't really understand why there's a few people who seem to think it's a good idea to try to do their scientific computing in Go when there are so many better options for that that already exist.

Post-generics, though, if you really insist, it will probably be the case that Go can be upgraded from "mediocre" to "tolerable" with a lot of library work. (Part of the "mediocre" is lacking libraries. That aspect can be fixed.) But it'll be hard to start that work without running generic code. Even if you assume the current documentation is the final specs, you still won't be able to guess the performance implications of anything you'd be blindly writing, and performance is very important for this sort of code.

Re: Go Modules in 2019

#17

Post by skybrian »

treve wrote: post #8

One of the thing that's always been a bit off-putting about the Go community and leadership is that it seemed that when I came across things that I perceived as flaws in the tooling or language, I often felt told off and was made to feel that it's me who is wrong for a variety of reasons. Examples of this include GOPATH, the package infrastructure, error handling, lack of generics. Rob Pike disagrees so I must be wro…

I think this is an example of rounding things off to one bit: either a feature is good or bad. Worse, people will round a language off to one bit: either it's great or terrible.

Sometimes this is just due to defensiveness: someone uses a flaw to say the whole language is terrible and that gets a response from people who have learned to live with the flaw.

Generally, if you back to the original statements you'll find something more nuanced: generic types have a lot of complicated effects on language design and they didn't like their own early proposals, so they started out without them. Yes, error checking can be repetitive, but many of the attempts to fix that in other languages were worse.

In the meantime, the "Go way" is about following common conventions for working within the language's limitations. This isn't a bad thing!

But it's tricky to be welcoming while getting across that the best way to deal with limitations is just to accept them, for now. On the Internet, everyone wants to be Steve Jobs and demand changes.

(Also: Rob Pike, not Erik.)

Re: Go Modules in 2019

#18

Post by purple_ducks »

treve wrote: post #8

One of the thing that's always been a bit off-putting about the Go community and leadership is that it seemed that when I came across things that I perceived as flaws in the tooling or language, I often felt told off and was made to feel that it's me who is wrong for a variety of reasons. Examples of this include GOPATH, the package infrastructure, error handling, lack of generics. Rob Pike disagrees so I must be wro…

i think the "Go way" was more like: Google have a different in-house solution for this so let's just leave it out and for something to bubble up out of community.

Go solves Googles main problem -> something which new engineers can use to write practical solutions without having to think too much. It's not beautiful or expressive or technically interesting; most "craftsman" devs won't stick with it too long..But that's not the majority of devs google is hiring.

Sit down, bang out code and don't concern yourself too much with craftmanship - it will be re-written in a couple of years. Just worry about performance.

Re: Go Modules in 2019

#19

Post by dmurray »

stcredzero wrote: post #10
llimllib wrote: post #6

Earlier quoted context omitted.

It's not well-suited to scientific computing at all. I use and like Go for writing network servers and ETL processes. In a scientific context though, the type system is awkward in the extreme, there is essentially no library of modules, and the interactive visualization story is nonexistent. Python, R, Julia, even C++ would be better options IMO. (I'll clarify again: I like Go! I just think it's not well suited for t…

If one wants to be a pioneer and be one of the people who starts the movement, now is the time to jump in and make a name for yourself.

I was looking at this very recently. It's probably impossible - not just difficult - to write a Numpy equivalent for Go as a library. I didn't feel I had what it took to extend the compiler to make that work, but some day someone will.

Re: Go Modules in 2019

#20

Post by revskill »

cgag wrote: post #9
treve wrote: post #8

One of the thing that's always been a bit off-putting about the Go community and leadership is that it seemed that when I came across things that I perceived as flaws in the tooling or language, I often felt told off and was made to feel that it's me who is wrong for a variety of reasons. Examples of this include GOPATH, the package infrastructure, error handling, lack of generics. Rob Pike disagrees so I must be wro…

Honestly I got the impression no one ever liked gopath.

Because setting environment variables is something most devs like to avoid.
Post reply on HN