[lug] Tom Cargill's Go talk

[Tom Christiansen]

In-Reply-To: 
    Message from Rob Nagler <nagler at bivio.biz>
    of "Sun, 17 Jan 2010 21:49:54 MST." 
    <3a9f8bfb1001172049r5a29444cgd2d91e814a4372c4 at mail.gmail.com>

>> Otherwise, why aren't maps access-protected?

> Because it doesn't solve problems that we have and causes more
> defects than it prevents.  Yes, it might protect people who
> don't really understand shared-memory multi-processing, but
> that's irrelevant. Anybody building systems which actually
> *require* shared memory probably know what they are doing, and
> will add locking at the appropriate level.

I agree with you, Rob, that proper management of shared data is something
any experienced programmer should be plenty used to.

I was given to (mis?)understand that unprotected maps could corrupt not
only data in a contended map, but also the program's whole execution state
so it later crashes in various messy and mysterious ways.  That's a worse
outcome than I'd've expected.  

I wonder whether it was pointed out because it's different that what
happens with the other built-in types?

In Go's expvar package, which provides a standarized interface 
public variables, 

    http://golang.org/src/pkg/expvar/expvar.go

you can see then bundling up mutexes from the sync package
for proper access control, such as

    // Int is a 64-bit integer variable, and satisfies the Var interface.
    type Int struct {
	i  int64
	mu sync.Mutex
    }


    // Map is a string-to-Var map variable, and satisfies the Var interface.
    type Map struct {
	m  map[string]Var
	mu sync.Mutex
    }

which is all well and good.  But the comment on this function makes me 
wonder, nervously:

    // TODO(rsc): Make sure map access in separate thread is safe.
    func iterate(c chan<- KeyValue) {
	for k, v := range vars {
	    c <- KeyValue{k, v}
	}
	close(c)
    }

I'm probably just being slow again, but I don't see how maps are more
troublesome for multithreaded programming in Go than any other data type.

Because it's normally passed by reference, and programmers might forget?
Or is it more than this?  

Is read access also a problem, or just write access?  

Why can it hose the program state?  

Might it have to do with the implementation of the dynamically
sized hash table?

Do the "incorrect synchronization" examples shown in
http://golang.org/doc/go_mem.html#tmp_111 have bearing 
on this map issue? (I'm thinking not.)

>>  (Damian Conway, who *is* a CS prof, recently answered me that
>>  question with, "Nowadays your graduate CS course would
>>  largely consist of endless reviews of advanced Java libraries
>>  for scalable enterprise web apps."  *SIGH*)

> I don't think this is true.  Grad school curricula looks pretty much
> what it was when I went to grad school:

> http://www.drexel.com/online-degrees/engineering-degrees/ms-cs/curriculum.aspx
> http://www.ecs.baylor.edu/computer_science/graduate/index.php?id=43910
> http://www.stanford.edu/dept/registrar/bulletin/current/pdf/compsci.pdf
> http://www.eecs.mit.edu/ug/NC-MEng_checklist1-2_09-15-09.pdf

    (I checked grad school curricula at three other universities--
    here at CU, UWisc, and Berkeley--and I'd concur that they don't 
    seem particularly altered from when I went to school.)

Didn't you never hear any of bitter controversies that sprang up
about which programming languages are taught, used, and/or
required in university CS programs?  Similarly for operating
systems and commercial libraries and IDEs?

There's been nasty friction when schools have changed the
programming language and environments in their first two
programming courses, typically "Introduction to Programming" and
"Algorithms and Data Structures", whatever they're called.  A
school switches to Java from (C and) C++ for its lower courses
but still requires C++ for its later courses.  This is tough on
students who often as not are expected to "just" learn C++ on
their own.

Arguments in favor aren't just one of ease of teaching, which has
some merit.  You also hear mumblespeak about being more
businesswise realistic--as though that were somehow relevant to a
university's mission.  *This* is where you see people flare.

You'll see some university environments that are completely
Microsoft endowed (same arguments), but then you'll see others
that have dual tracks. The folks who aren't expected to continue
to grad school are shuffled through Microsoft-based tracks that
waste lots of time teaching proprietary libraries like the
Microsoft Foundation Class library and such, while those who
expect to go to grad school may be given more general versions of
the same classes.

Places like MIT and Berkeley have often used Scheme early on,
which just gets industry-first types bitching to high heaven. 
Or, at some schools you'll have some professors doing Java while
other profs for the very same course are teaching (in one case I
know of) first Python and then C++.   The second is supposed to
be for CS majors; the first is not!

This sort of thing isn't completely new, at least in some ways.  My
first programming course was in FORTRAN, and my data structures class
was in Pascal.  My next course was in PDP-11 macro assembler, but *all*
further coursework (except the AI course) was to be written in C--even
though C was never [at that time, yet] taught at my school!  Maybe it's
easier to pick up C on one's own after Pascal and assembler than it is
to pick up C++ after Java; probably.

What *is* new is so-called "industry standard" (read: Microsoft's)
libraries and toolsets being pushed on students at the *university*
level. That doesn't seem the business of a university to some but not
all professors, who see it more the proper domain of some business tech-
school.  They do not feel they should be doing Microsoft training at a
university, even if Microsoft provides for "free", and I can't say I
blame them.  

Me, I kinda like the idea of a Scheme and Python and C++ regimen with zero
proprietary indoctrination, but I'm not a good little M$FT soldier.
(Not that I'm a great fan of C++, mind you.)

This type of hullabaloo really does cause unpleasantness at
universities, much moreso than ever it did when I was in school,
so I found Damian's comment made perfect sense in that context.

--tom