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

141–150 of 178 posts

Re: Go Modules in 2019

#141

Post by candiodari »

pokstad wrote: post #78
candiodari wrote: post #30

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

Go modules still allow for changes to local copies. You are not required to use a proxy to use modules. Also, you can always fork a public project and use a replace statement in a module to redirect an import path to your customized module. Check out this related tool: https://github.com/rogpeppe/gohack

And another configuration file that you (and all tools) need to know about pointing at yet another global directory (global for all your projects). That override file, of course, does have to be in your project folder and is yet another thing to take into account.

If I want to share things, I am aware of links in filesystems, thank you very much Go authors. "go.mod" overrides ... I wish golang did not try to solve yet another non-problem badly.

Re: Go Modules in 2019

#142

Post by stcredzero »

Merovius wrote: post #128
stcredzero wrote: post #112

Earlier quoted context omitted.

The best course of action for Go on this front, would be to expose operator overloading of numeric operators, combined with a community expectation that this isn't to be used for anything but numeric operations. What would be the disadvantage of using a syntactic preprocessor to accomplish the same thing? We have an API for parsing golang. What if there was a way of marking certain files to be parsed and re-written w…

> The best course of action for Go on this front, would be to expose operator overloading of numeric operators, combined with a community expectation that this isn't to be used for anything but numeric operations. I don't think this solves the issues. For example, I have yet to think of a way to overload `+` in a consistent and performant manner. E.g. think of `a += b` vs. `a = a + b`. Either you make them separate o…

Either you make them separate operators (in which case there's no guarantee they do the same thing - see for example Python, where they commonly differ)

Geez. That's obnoxious. Why do we programmers do this to ourselves?

or you are overallocating in the common case.

I see. I was thinking along the lines of being able to use complex numbers with arithmetic operators, not along the lines of doing high performance crunching of floats.

Re: Go Modules in 2019

#143

Post by candiodari »

Merovius wrote: post #121
jonahx wrote: post #109

Earlier quoted context omitted.

Oh let's be very clear: Go is actively, explicitly anti-FP, anti-expressiveness, anti-brevity. Those are simply not its values. And any attempts to write Go in FP style will be considered unidiomatic Go. And the missing ternary will be the least of your problems. Do you enjoy `map` and `filter`? Sorry, the "go way" is to use a for loop every time. Reimplementing map on every type where you need it is considered best…

> Have a problem with that? Expect a snarky comment about your priorities. Whereas your comment is completely devoid of snark.

That comment, however, is a comment on hacker news.

Not the official docs of a programming language. In one of those, a bit of snark is really quite normal and of no real impact.

Re: Go Modules in 2019

#144

Post by TheDong »

Merovius wrote: post #130
pjmlp wrote: post #72

Earlier quoted context omitted.

Same applies to Maven, in fact many enterprises forbid access to Maven central, while curating an internal one.

> Same applies to Maven, in fact many enterprises forbid access to Maven central "Maven central" implies there is a central repository though.

There are two different meanings of 'central' in play here, 'center' as in a town square, and 'center' as in the centralized component of a system.

It does not imply that there is a central repository when using 'central' to mean 'a unique, difficult to replicate, or otherwise somehow special component in a system' as in 'centralization'.

Central in the case of 'Maven Central' means something closer to 'default' or 'town square' or such.

Saying that 'maven central' implies maven isn't decentralized would be the same as saying "Most go projects are on github, so go can't be hosted in a decentralized way because github is 'golang central'".

Re: Go Modules in 2019

#145

Post by candiodari »

yashap wrote: post #103
Felz wrote: post #90

Earlier quoted context omitted.

Why not have if/else be an expression in the first place, like Kotlin? n = if(expr) trueVal else falseVal No need to learn a separate ternary operator.

Quite a few languages do if expressions, and IMO they’re great. Simple syntax, readable and powerful. It’s crazy to me that any new language wouldn’t have them.

The argument specified in the docs is "a language needs only one conditional flow construct" (in a language, of course, that has half a dozen conditional flow constructs ...)

The more palatable argument that people who try to cover for ... seems to be that when people nest if expressions, it becomes a mess. I'm glad these people exist.

The real reason is found here: http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/

(or if you prefer, in the compiler's source itself. It doesn't take a compiler expert to realize it's not very clean code. Even violates the go style, and the C one before that was just horrendous)

The TLDR is that Go's compiler is a "fisher-price my first compiler" and really shows that the authors simply barely knew how to get a compiler working in the first place. That they were not ready to go into a rational discussion on programming language and type theory ... is not something anyone should be surprised about.

That they avoid the arguments by dismissing the people making them in such a condescending way is ... well, there's not really anything good to say about that.

Re: Go Modules in 2019

#146

Post by erik_seaberg »

iainmerrick wrote: post #106
Felz wrote: post #90

Earlier quoted context omitted.

Why not have if/else be an expression in the first place, like Kotlin? n = if(expr) trueVal else falseVal No need to learn a separate ternary operator.

Because the designers of Kotlin are more open to experimentation and new ideas.

  (setq n (cond
    (expr trueVal)
    (t falseVal)))
This particular idea dates back to at least 1965.

Re: Go Modules in 2019

#147

Post by karmakaze »

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…

What I've come to learn from using Go on a number of projects and reading the long mailing list threads on topics that lead to the decisions and development of language features is that Go is a language intended for many programmers (e.g. average) to be successful writing systems(-like) software. Officially, it was meant to be for systems software, but it's since expanded beyond that scope. Given that it's designed and developed by very bright authors for everyday programmers, it's actually surprising how much thought has gone into seemingly obvious language features. They want users of the language to be successful more than they want their users ego to be happy about language features.

Given that, they do also 'talk down' in their official documentation. I had to look back in time to understand the memory model for the sync.atomic operations which is documented:

"These functions require great care to be used correctly. Except for special, low-level applications, synchronization is better done with channels or the facilities of the sync package. Share memory by communicating; don't communicate by sharing memory."

The final word on what 'great care' means is that Go doesn't actually have a memory model for this part of the standard library. The discussion thread around it has a different tone than the official documentation. They agree on how they want implementations to operate, but don't feel that it needs to be officially defined or documented. I would have been happy if they at least referenced the discussion thread rather than merely label it 'great care' meaning 'not for you'. The other thing you find is that the performant parts of the standard library often does not follow "Share memory by communicating; don't communicate by sharing memory".

One of the betrayals when working with I/O was finding that standard library routines can return a value AND an error, and that sometimes a non-nil error is not an error (EOF is not the only one of these).

Re: Go Modules in 2019

#148

Post by latch »

Carpetsmoker wrote: post #138
latch wrote: post #28

Earlier quoted context omitted.

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

There are "I've used Go for a week and here are my strong opinions on it!" posted to reddit (and elsewhere) every week. Frankly, it's just tiring; especially as a lot of the same points and misconceptions are repeated. Some points are valid, but it's repetitive at best. It would be like discussing Python's significant whitespace with inexperienced Python programmers every week. Sure, it's quirky and arguably not a go…

I started using Go in 2008, but I get your point.

Still, I think my and my parent's point is that: it would have been better if they'd just said nothing.

Re: Go Modules in 2019

#149

Post by chewxy »

sbinet wrote: post #41
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?

others have already mentioned Gonum: - https://gonum.org Gonum is almost on par with _e.g._ NumPy/SciPy (most notably lacking: ODEs). So still ways to Go but it's getting there. Go-HEP is my attempt to bring a few High Energy Physics oriented packages to particle physicists: - https://go-hep.org I've also written a few words on why I think Go is great for science: - https://sbinet.github.io/posts/2018-07-31-go-hep-ma…

There's Gorgonia too! :)

Re: Go Modules in 2019

#150

Post by cyphar »

atombender wrote: post #102
cyphar wrote: post #38

Earlier quoted context omitted.

I think a primary problem with the modules workflow is that you can't switch to it until all Go projects you work on switch to it. Plus, all of us have got our own GOPATH home-directory workarounds so there's no real point in switching anymore.

That's not true at all. A Go-modules-enabled project can import packages from a non-modules-enabled project that doesn't have Go.mod in it. This was always the case with Glide and Dep, too.

That's not what I'm talking about. I'm talking about being able to build outside of GOPATH. This requires the top-level project to use go.mod and many don't (like Docker for instance).
Post reply on HN