triple sulk posted:

i legitimately still want to give go the benefit of the doubt, but when i go back and look at it again beyond the very basic scripting stuff i tried with it a few months ago, i see stuff like this

quote:

Why doesn't Go have "implements" declarations?

A Go type satisfies an interface by implementing the methods of that interface, nothing more. This property allows interfaces to be defined and used without having to modify existing code. It enables a kind of structural typing that promotes separation of concerns and improves code re-use, and makes it easier to build on patterns that emerge as the code develops. The semantics of interfaces is one of the main reasons for Go's nimble, lightweight feel.

See the question on type inheritance for more detail.

How can I guarantee my type satisfies an interface?

You can ask the compiler to check that the type T implements the interface I by attempting an assignment:

code:

type T struct{}
var _ I = T{}   // Verify that T implements I.

If T doesn't implement I, the mistake will be caught at compile time.

If you wish the users of an interface to explicitly declare that they implement it, you can add a method with a descriptive name to the interface's method set. For example:

code:

type Fooer interface {
    Foo()
    ImplementsFooer()
}

A type must then implement the ImplementsFooer method to be a Fooer, clearly documenting the fact and announcing it in godoc's output.

code:

type Bar struct{}
func (b Bar) ImplementsFooer() {}
func (b Bar) Foo() {}

Most code doesn't make use of such constraints, since they limit the utility of the interface idea. Sometimes, though, they're necessary to resolve ambiguities among similar interfaces.

Captain Foo posted:

go gently caress yourself, i think

prefect posted:

Captain Foo posted:

it's a bad go joke lol

prefect posted:

ah. i saw it right after my post and thought i might have been a cock somehow

Captain Foo posted:

should have been golang gently caress yourself i guess

Captain Foo posted:

it's a bad go joke lol

MALE SHOEGAZE posted:

go compiles quickly because it doesn't have to link to any libraries because no one has written any useful libraries for go

pram posted:

cant spell good without go

pram posted:

crufty hunk of poo poo

suffix posted:

dockerizing go programs seems a bit pointless, tbh

like i was mucking around thinking about running some java programs in docker but i realized they're already self-contained with all their dependencies

pram posted:

that joke only works if thats actually at the end of the post fyi

pram posted:

crufty hunk of poo poo like java

Blood alpha source code posted:

George [Broussard]

I just got off the phone with Nick, who told me he had passed my previous message about Ken [Silverman] to you. I hope that you understand that I was really just venting at Nick, and I didn't intend that my message be passed on to you, Ken, or his father. There is still, however, a very significant problem we (Q Studios) have in dealing with Ken.

Every update Ken makes to his engine turns out to be a major tribulation for us. He regularly makes changes that break our code without any advance warning. He consistently ignores our requests for fixes or suggestions for design strategy. Nick is constantly on me to "Call him. Just get on the phone and talk to him," but to be honest, talking to Ken on the phone is pretty much near the bottom of the list of things I'd like to do with my life.

The problem is, he's just so completely unresponsive. I'll ask him a question, and nine out of ten times I'll either get silence or "I don't know"
as a response. I know he's highly intelligent, but so are a lot of people I
know, and I can TALK to THEM. Okay, so perhaps his personality is a bit different, but he still needs to work WITH us, not AGAINST us.

We've had a resource and memory manager in Blood since last year, and it's been working well and is very solid code at this point in time. To get it working back in December though, I had to completely replace parts of the engine, no thanks to Ken. A well designed system would have been built on the ground up from a good memory manager, or at the very least with hooks laid in so it could be developed later. To get our virtual memory system to work with Ken's engine, I had to spend weeks reverse engineering Ken's code, documenting variables, prototyping functions -- all things that Ken himself
should have done or provided.

Now in June, he hacks in his "group file" system, and says we have to use it. In one sense he's right -- he's hard coded the thing into his engine, and it's broken Blood unless I can figure out which parts of the engine I need to replace. By the time we're done with Blood, we probably won't have any of Ken's engine left... Perhaps you'll want to reconsider the royalties that you are paying him.

A few months ago, Ken made a change to the engine that allowed each tile to have its own origin -- a reference point by which it could be positioned. This change was a good one, but there were some problems with the implementation. When the bit was turned on to enable sprites to be centered on their origin, animations bounced, and sprites appeared at the wrong position.

It turns out the solution was one of procedure -- by setting the origin at
the base for sprites that are supposed to be on the floor, everything appears correctly. Unfortunately, setting the origin for several thousand tiles using Ken's EDITART tool was just a bit too cumbersome for us, so I spent a
few days developing a tool that would allow simple tweaking of the tile origins, among other things. This tool is integrated with our new sequence editor, which will be used to create and edit all the actor animations (walking, attack, death, etc.)

Everything with this system was going fine until we discovered that Ken has some engine flaws in dealing with sprites that use origin based centering. The clipmove() function doesn't work, and neither does hitscan(). These two
functions are pretty much essential to doing anything with the engine. I
could rewrite them, of course, but that would be a few days to weeks out of our schedule, depending on how many more bugs and design problems crawl out of the woodwork.

We had waited a few months before switching to the new origin based
centering, so I was quite surprised to find such fundamental problems with
it. We called up Ken and told him about it, and he said he didn't think
anyone was using it, but he really didn't know. We asked him to fix it.

Tonight I called up Ken because of the group file problems, and because weBstill don't have a fix for the clipmove() or hitscan() problems. Ken he wasn't going to fix it and we should go back to using the old centering mode. This is totally and completely unacceptable. We've already invested time and effort (need I say money?) into using something, and we're not about to waste more regressing.

Ken understands algorithms, and he understands graphics. What he doesn't get is how to design SYSTEMS. Everything he does to the engine is a piecemeal enhancement to something that should have been designed right from the beginning. The memory system is a poignant example of this. It is a hack, like most of his code, and not very robust. From what I've disassembled of the group file code (trying to figure out a way to eliminate or replace it), it too demonstrates plentiful opportunities for crashing the system -- pointers being freed without validation, files being closed without
verifying the handle, etc.

Our resource and memory manager are quite superior to Ken's (no bragging), so to abandon our body of code would be a step in the wrong direction. When I mentioned to him that our resource manager used an LRU list to handle purging of resources, he said that he didn't understand how they worked and
he didn't want to undertake something that complicated. It isn't that complex; it's just outside the realm of Ken's experience.

I usually end my phone conversations with Ken with something like the
following: "Ken, is there anything I can do, anything I can provide to you,
that would help you make these fixes or changes?" The answer is invariably "No." After we hang up, I usually bang my head on the desk for about ten minutes. I've tried to explain to Nick that this is why I don't like to call Ken, but I think he already knows.

Tonight I tried to explain to Ken what a library file is. I told him how
linkers work, and how they resolve symbol name when producing an executable. I tried to impress on him the benefits of "code granularity" -- breaking a system up into as many small discrete modules as possible so that the linker can efficiently pack only used code into the executable. I informed him about "dead code", and why there was so much of his in Blood. I don't think I made any impression at all.

George, I want you to understand one thing. When I ask Ken to make a fix or enhancement, it is most surely something we absolutely need for Blood. I wouldn't force myself to make the phone otherwise. However, everything that I ask for would benefit not only Blood, but EVERY OTHER build project. I've spent enough time as a Project Manager for commercial programming tools that I know what makes a good API, and I know what makes a system extensible. The
things I've been asking for are "hooks" so we can implement our own features, not have him do them for us.

I sometimes wonder, though, if I'm going against the flow. Perhaps Ken added his cache system in response to other teams request for a memory manager? Maybe the group file code was asked for by the Duke Nukem team? These fears usually turn out to be unfounded, since other teams report similar problems as a result of Ken's "updates."

I realize that most of the problems I've been describing with Ken are highly historical in nature, and there's no way to change the past. What can and must be done though is to make Ken more responsive to our needs. He needs to work WITH us, not against us. I don't know why he is so combative, but I can guess -- ego. He probably feels about his code the way a lot of programmers do: it's okay to criticize your own code, but for anyone else to do so is blasphemy. I used to be that way until I realized that a lot of the
suggestions people were making to me were actually right.

Luigi Thirty posted:

Subjunctive posted:

who wrote that?

Luigi Thirty posted:

the project manager of blood, to George Broussard

Subjunctive posted:

Rob's smart, but it's not like he redefines the category. he had a lot of latitude on p9 and so he got to flex all over, but it's not clear that he's really that connected to the realities of industrial software development. go seems like a language designed for "software development as experienced by Rob Pike", but not necessarily one that generalizes to "software development as experienced by anyone who actually has constraints".

coffeetable posted:

karpathy's rnn post made mention of how torch7 doesn't compile poo poo like theano does, and that feels v shiny

rob pike posted:

I wanted to see how hard it was to implement this sort of thing in Go, with as nice an API as I could manage. It wasn't hard.

Having written it a couple of years ago, I haven't had occasion to use it once. Instead, I just use "for" loops.

You shouldn't use it either.

Sean Talts posted:

Hi everyone,

I'm wondering if there are plans or it would be useful to implement map and filter on top of native Go collections, or maps and slices at least. Is there a reason that was not included? I've read a bit about why generics has not been included on a language level and instead they have been special cased on collections, but I don't see that precluding type-safe (i.e. not just translating everything to interface{} and back) implementations of map and filter. On the contrary, it seems to my admittedly Go-newbie self that they would, in fact, solve most of the use cases for generics. Thoughts? Does this violate some fundamental Go design decision I haven't yet encountered?

Thanks in advance,
Sean

PS I tried searching for this on the mailing list but my search-fu is weak and terms like "map" and "filter" are not particularly googleable. If I've missed a thread, feel free to link it! Thanks again.

quote:

I'm reluctant to add increasingly special purpose builtin functions.
There is no obvious endpoint as we head down that road.

Ian

quote:

The modern programmer thinks a newline is a thousand times harder to
type than any other character. If instead you take a newline as only
one keystroke, which it is, the fact that your program might not fit
on one line is a bearable burden.

-rob

comedyblissoption posted:

https://groups.google.com/d/topic/golang-nuts/RKymTuSCHS0/discussion