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

21–30 of 178 posts

Re: Go Modules in 2019

#21

Post by erik_seaberg »

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.

It's frustrating how much résumé-driven development I'm seeing on problems the industry already solved. I'd rather work on harder problems using more powerful tools.

Re: Go Modules in 2019

#22

Post by cstejerean »

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 agree completely, that’s precisely the same impression I got. Maybe it was mostly from discussions on HN and it doesn represent the community at large. Whatever the reason I’m glad to see focus on fixing the GOPATH abomination and the plan to finally add generics in Go 2.

Re: Go Modules in 2019

#23

Post by cstejerean »

purple_ducks wrote: post #18
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'…

And then proceed to shit on whatever did bubble up from the community, at least as far as package management goes. I’m glad we’re finally getting the core team to focus on modules but as an outsider that whole situation was handled poorly and doesn’t give me a lot of faith in solutions bubbling up from the community.

Re: Go Modules in 2019

#24

Post by [deleted] »

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…

[deleted]

Re: Go Modules in 2019

#25

Post by cgag »

revskill wrote: post #20
cgag wrote: post #9

Earlier quoted context omitted.

Honestly I got the impression no one ever liked gopath.

Because setting environment variables is something most devs like to avoid.

No, because I have like 50 projects in ~/src and suddenly have to keep some of my code in ~/src/go/src/GitHub.com/cgag and that annoys me.

Re: Go Modules in 2019

#26

Post by stcredzero »

jerf wrote: post #16
stcredzero wrote: post #10

Earlier quoted context omitted.

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 programmi…

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

I didn't mean "now" as in right this second. Generics will indeed be key.

Re: Go Modules in 2019

#27

Post by agnivade »

dmurray wrote: post #19
stcredzero wrote: post #10

Earlier quoted context omitted.

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.

https://github.com/gonum/gonum is that.

Re: Go Modules in 2019

#28

Post by latch »

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 wrote a blog post about the error handling. Someone put it on /r/golang (note the subreddit name).

There were 22 comments, and the one from the Go developer was (and I quote):

"Tempted to stop reading after the first word in the article. (The language isn't called Golang)"

Re: Go Modules in 2019

#29

Post by cyphar »

cgag wrote: post #25
revskill wrote: post #20

Earlier quoted context omitted.

Because setting environment variables is something most devs like to avoid.

No, because I have like 50 projects in ~/src and suddenly have to keep some of my code in ~/src/go/src/GitHub.com/cgag and that annoys me.

I have tried several times to fix this problem in the past 5 or 6 years, once with symlinks (which would break quite often -- it's unsurprising that Plan 9 developers wouldn't care too much for handling symlinks correctly :P).

The current way I handle it is that $HOME/.local is my GOPATH, and $HOME/src links to $HOME/.local/src. So you can just have $HOME/src/github.com/bar/foo -- which is less ideal than just $HOME/src/foo, but it's something at least.

Re: Go Modules in 2019

#30

Post by candiodari »

Maybe it's just me but I hate this option. Are we really, really trying to optimize the downloading of source code ? All 5 megabytes of it ? Why would you do that ?

I regularly find myself in a position that this system would make impossible: I need a few custom changes in public available libraries. An extra method. A bugfix. What have you. This makes that impossible using the default method.

What we want is consistent builds. That means a build that happens, with the same source, with the same ... every time, always, on everybody's workstation.

Post reply on HN