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

171–178 of 178 posts

Re: Go Modules in 2019

#171

Post by candiodari »

4ad wrote: post #167
candiodari wrote: post #145

Earlier quoted context omitted.

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

Ken Thompson has been writing compilers for over 50 years now. If you believe that Ken "barely knew how to get a compiler working in the first place", we have nothing to talk about, as you obviously made up your mind already.

Then read the source for the compiler yourself. Tell me I'm wrong.

Re: Go Modules in 2019

#172

Post by 4ad »

candiodari wrote: post #171
4ad wrote: post #167

Earlier quoted context omitted.

Ken Thompson has been writing compilers for over 50 years now. If you believe that Ken "barely knew how to get a compiler working in the first place", we have nothing to talk about, as you obviously made up your mind already.

Then read the source for the compiler yourself. Tell me I'm wrong.

Not only I have read it, I have written several compiler targets for it. You are wrong. It's by far the easiest compiler I have worked with.

Re: Go Modules in 2019

#173

Post by zemo »

almostdeadguy wrote: post #168
zemo wrote: post #59

Earlier quoted context omitted.

the fact that you call Rob Pike "Erik Pike" really reads like the complaints of someone who doesn't do their homework and asks questions that have already been answered in many places. Generics is a major tell, too, since the Go team's position on generics was always "generics are interesting but we don't know how to make them work well with Go's existing type system". See for example, this blog post from 2009: https…

The kinds of parametric polymorphism implementations mentioned here do not represent the full set of options. Charitably this represents an ignorance on the part of the Go developers, but really it has felt like an apathy towards the field of programming language design and research. Intensional polymorphism (basically passing the type of a parametric argument as a parameter, and either using a specialized implementa…

That paper is mentioned in the comments of my first link. I would be surprised if the Go team doesn't know about it. In that thread, as well as here, both you and the other poster haven't actually stated how the paper's strategy would work for Go, and haven't actually stated how the strategy affects compile times, binary sizes, and execution time.

edit: addendum: but also, in every thread about Go, there are some Haskell people showing up to talk about how the Go team is too stupid to understand the Haskell type system. This happens regardless of what the opening topic is, which in this case, is dependency management. No matter what the topic is, if it's a thread about Go, you will find Haskell programmers there, condescendingly talking about how Haskell's type system is so much better than Go's type system. It is very tiring.

Re: Go Modules in 2019

#174

Post by spullara »

geodel wrote: post #139
spullara wrote: post #132

Earlier quoted context omitted.

If you realize something is wrong a couple years in and it takes 5+ years to fix it, then that seems like a long time to me.

In between community developed many solutions when official solution was lacking. So it's not like people were twiddling their thumbs for 5 years. Also check how long Java took to get official module solution. Work on that started in 2008 and solution was delivered in 2017.

Hah. They don't have one now. The de facto solution is Maven. Java itself doesn't actually have a module system like the one discussed for Go. It is merely a access control system rather than a dependency system.

To be clear, I give the Java people shit about it all the time and was on the original Java module system JSR that was supposed to deliver it. In the end, the Sun people yanked the dependency part and shipped a module system that is really only useful to the JDK.

Re: Go Modules in 2019

#175

Post by tandr »

lsllc wrote: post #67
jonahx wrote: post #60

Earlier quoted context omitted.

Contemptuous scorn seems to be the officially-sanctioned strategy for responding to reasoned critique or even questions about "the go way" within the community. My favorite example here is this arrogant dismissal of the idea that a one line expression , rather than a 5 line mutating statement, might be preferred for conditionally setting a value: if expr { n = trueVal } else { n = falseVal } > The if-else form, altho…

> A language needs only one conditional control flow construct. If by "one" you mean `if` _and_ `switch` then yes!

and `select`

Re: Go Modules in 2019

#176

Post by rufio »

jonahx wrote: post #137
Merovius wrote: post #133

Earlier quoted context omitted.

> Allowing single line if statements (as, eg, ruby does) also allows for clearer code, at the expense of consistency. This (or rather allowing conditionals without braces) was what I was referring to. They are a foot-gun, because of the lack of clarity. It's a common source of bugs in C/C++ code that a developer thought they'd add a line of code to a conditional block or loop but didn't, because of a lack of braces.…

I'm aware of the reasoning. As you say, in C people would carelessly edit: if (condition) doSomething to if (condition) doSomething doSomething2 So fair enough, you protect against that. You cannot therefore conclude that: if (condition) { doSomething } is clearer or that 1 line if statements aren't clear. First of all, you've purchased your insurance at the cost of brevity. Which is quite a high price, especially wh…

on that note: here's an example of a very costly example of this exact mistake, Apple's famous "GoTo Fail" for anyone that isn't aware of it: https://dwheeler.com/essays/apple-goto-fail.html

Re: Go Modules in 2019

#177

Post by lenkite »

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 keep the source code for my projects in ~/src and I always set my GOPATH to my home dir. So the special 'go' in the path can be avoided. It will just be ~/src/github.com/...

But, yes, I rolled my eyes when learning about GOPATH for the first time.

Re: Go Modules in 2019

#178

Post by atombender »

cyphar wrote: post #150
atombender wrote: post #102

Earlier quoted context omitted.

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

But that's not the same thing. You don't have to switch all the projects you work on over to Go modules at the same time, only the projects you want to upgrade. It's entirely possible to migrate incrementally.
Post reply on HN