61–70 of 178 posts
So the mirror will serve both the package and signed hashes, what if the package has been indexed in the central index but not yet signed by the notary?
Earlier quoted context omitted.
Gonum is neat, but to the previously-made point about Go's type system making stuff more painful than it needs to be in this application: gonum's linear algebra is defined over float64 and int, which is problematic if you need arbitrary precision.
I guess it's scientific domain dependent. I've very rarely needed something else than float/double in my C++ days or REAL*8 in my F77 ones. sure, when you need it, you need it. but float64 caters for a good 99% of my usual work day. From a user POV, seamless installation of packages is a great boon. From a grid/cloud operator POV, static binaries are great too.
Nice overview, however a small correction to the statement about Maven repositories. Decentralized support has been a thing since the last decade.
I think decentralized is meant as "there's no central repository" here.
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?
I used go in machine learning contexts extensively while writing graphpipe[1]. Go is a fantastic language for servers, and distributed communication. Unfortunately, the lack of generics and dependence on interfaces and reflection makes writing things that deal with multidimensional arrays pretty terrible. See, for example, the janky conversion code in graphpipe-go[2] to convert a multidimensional slice into contiguou…
generics may help in that department.
in the meantime, there's Apache Arrow:
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…
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…
It was a comment on my personal experiences of interacting with the Go community, not the language and its limitations. My hope wasn't that Go implements my every pet peeve, my hope is that the community has gained some humility since I last dipped my toes in it.
Pike seems especially aggressive when interacting with people he disagrees with and this was for me indicative of the culture. It's been a few years though, so maybe by now I'm wrong!
Here's Pike on the topic of syntax highlighting:
https://groups.google.com/d/msg/golang-nuts/hJHCAaiL0so/E2mQ...
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…
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…
If by "one" you mean `if` _and_ `switch` then yes!
It is amazing that it took them this long to realize they were entirely wrong about how dependencies should be distributed. Since it was obvious from day 1 to most people from other ecosystems maybe they shouldn't have so much NIH. We'll likely get exceptions and generics soon as well. What a waste of time.
I think that having a system in place with the language may be a better option than a company with its' own motivations and needs separated from the language/runtime/platform.
As to generics, I think you may well find generics in the future. I feel that most of the resistance was in order to better support core language features. I can't think of any languages (I'm no expert) that started with generics support, so I'd be surprised if this wasn't a go 2.x goal.
For exceptions, I think that the go solution works. Similar to the callback interfaces in node, it puts errors in your face, which isn't a bad thing. I mainly contrast this with node, as it's another language/platform that has grown a LOT but also relatively recent.
You can compare the progress of node, go and others to say python2/3, C#, Java and others. I think go progress has been great by comparison, and pragmatic choices have ruled out.
It is amazing that it took them this long to realize they were entirely wrong about how dependencies should be distributed. Since it was obvious from day 1 to most people from other ecosystems maybe they shouldn't have so much NIH. We'll likely get exceptions and generics soon as well. What a waste of time.
The way dependencies are distributed (ie. downloaded) won't change a lot, and as they say the distributed model is very important. Maybe you mean how dependencies are installed by the go command? (As a side note, I don't think there are any plans for exceptions -- for good)
Also, https://go.googlesource.com/proposal/+/master/design/go2draf...
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…
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…
&&, ||, switch, select, for, and while all do conditional execution in Go.
So the rule is not "A language needs only one conditional control flow construct." The rule is really, "We didn't think a conditional operator was worth it." That's a fine rule, but it's better to be honest about it than to pretend the language was designed around some pure principle that doesn't actually exist.