redbad

Do you contend that concurrency—and I mean true concurrency in the abstract, not a particular implementation of a parallelization idiom like threads—is well-served by C++ or Java?

    ...invite.php?...

There goes your credibility.

    > Loadable modules like the way Apache/nginx do, or 
    > Nagios or quite a few other basic infrastructure 
    > applications.

I agree this style of composition is not currently possible in Go, but I do not agree that it is necessarily a good (in the engineering sense) solution to the requirement(s) it solves. There are lots of other ways to communicate between dynamically dispatched blocks of code, and dynamic code loading is by any account fragile.

Or, to put it another way,

    > you can't expose your Go code through any kind of 
    > native interface

I'm not convinced this restriction is anything but good.

    > Without dynamic linking it cannot replace C/C++ for 
    > lots of the intended use cases.

What use case requires dynamic linking?

Case in point: http://i.imgur.com/MyWGT.jpg

    > it lacks public transit directions

I would say 50% of my phone-in-hand time is (was) spent in Maps, and 50% of that time was spent navigating with public transit. This is a huge, huge problem.

Four glaring apostrophe errors, and at least two grammatical errors, on the first reading. I appreciate and agree with the sentiment, but there's no way I'm putting my name on something that amateur.

Well, his example code demonstrating the "bug" is definitely broken. But not because of any flaw in coroutines, rather in his understanding of them.

    session = sessions.get_session(cookie);
    if(!session)
        session = sessions.create_session(user_id);

Concurrent access to a global sessions object is obviously unsafe, even in a coroutine environment where "You know [the above methods] don’t yield to the scheduler." I'm not sure that anyone advocating for coroutines over async APIs is arguing that coroutines somehow magically absolve the programmer from considering race conditions. Only that coroutines, used idiomatically, remove classes of bugs _like this one_. And that snippet is not idiomatic.

One "coroutine way" of handling concurrent access to shared data is by piping requests to it through a synchronization point. For example, in pseudo-Go, it may look like

    // public, synchronous API method
    func (s *Sessions) GetSession(cookie string) Session {
        // return s.dataStructure[cookie] // bad, obviously
        responseChannel := make(chan Session)
        s.requests <- getSessionRequest{cookie, responseChannel}
        return <-responseChannel
    }

    func (s *Sessions) loop() {
        for {
            select {
             . . .
            case req := <-s.requests:
                req.responseChannel <- s.dataStructure[req.cookie]
             . . .
            }
        }
    }

(Another way is explicit locking, of course.)

    > someone has said exactly that about, and I'm really not 
    > kidding, every newly popular language over the last 20 
    > years.

That's probably true, and I grok your point, but pretty much everyone who's using Go in a production environment cites speed of development among the major, top-N reasons they're using the language. Past a certain threshold, there's something there that can't be hand-waved away.

    > Programming languages can make the easy stuff easy. 
    > They can't fix our own stupidity.

One of the neat things about Go, in my opinion, is that it converts a lot of "hard stuff" to "easy stuff", especially in the domain of concurrency, simply by the nature of its idioms.

    > where one song may have been remixed with three different 
    > people, now you have to start infecting the track names 
    > with the remixer.

For what it's worth, I don't consider that "infecting". It's really the only sane way to handle huge collaborative works.

There are always exceptions which break any categorization scheme. The point is to treat them as exceptions, ie. fold them into the 90% model as well as you can, rather than restructuring your model to accomodate for 100% of every conceivable artistic license.

    > And then you've got classical music, 

This one _is_ interesting, but I solved it (personally) when I realized I only cared about the original composer (eg. Mozart) in terms of "artist", and the minimum nomenclature to disambiguate movements, etc. in terms of "title". Trivia like the performing orchestra is perfectly well homed in the album title, or ignored entirely. I admit I'm only interested in listening to classical music, not cataloging it to some deeper academic purpose.

You're making the problem a lot harder than it needs, or ought, to be. The most telling example, IMO, is the Aphex Twin one...

    > Oh, and his real name is Richard David James. What are you 
    > supposed to use for the file system directories and files 
    > name? His name? The most common nickname? Both? One file 
    > system solution is to have symbolic links (do you link 
    > Richard David James to Aphex Twin, or vice versa?). For 
    > tags, if you don't want to lose information, this is 
    > another story...

You should—obviously—not attempt to "link" AFX to Aphex Twin to GAK to Blue Calx to etc. etc. The artist behind all of the monikers has made a deliberate decision to release work under different names. Organize accordingly.

Many of your nightmare scenarios appear to be a result of the same kind of over-thinking, or invention of nonsensical requirements. How are you supposed to deal with Japanese artist names? It literally doesn't matter—pick a scheme you can understand, and be consistent. How are you supposed to deal with multiple artists? List them, separated by commas, in the artist field. If they appear on an album released by a different group or person, use the "album artist" ID3 field. And since (if?) you use the ID3 fields to store your metadata, and presumably navigate your collection through an interface over that metadata, all of your questions regarding how to store files physically on disk are totally irrelevant, as long as you pick some scheme which doesn't generate conflicts. The default iTunes structure (Artist/Album/01 - Song Title.mp3) seems to work fine, for example.

    >  If the exact same recording of a song appears on two 
    >  albums, an ideal categorization system would allow it to 
    >  appear as such without storing multiple (redundant) copies 
    >  of the song.

I don't agree. The song was released twice; if you have both albums, you ought to have two copies of it.

    The question is: can I find something equivalent for
    less cost. My experience has been, with sufficient
    searching (and yes, there's a time cost to that), yes,
    I can.

As far as I'm aware, there is nothing equivalent to Outlier on the market today, much less anything at a lower price point. If you have information to the contrary, please do share.

Stop defending bad design. We can do better than this.

    The problem is it's no better than C

Multiple return values are pretty clearly better than C. The comma-OK or comma-err idiom is verbose, but powerful and unambiguous.

Sublime Text 2 + GoSublime has been a really great experience for me.

http://www.sublimetext.com/2

https://github.com/DisposaBoy/GoSublime

So?

Honest question. So, what?

Provided I don't make/imply a claim of authorship—and in this instance he clearly hasn't—I simply don't perceive a duty of attribution when I'm sharing things to friends.

    Java, C#, Python, Lisp, and Erlang would all criticize 
    Go for an unqualified new exception system

panic/recover is not an exception system in the sense that you mean. Nobody is writing large applications and using panic/recover for error handling. (At least, I hope not!) The idiomatic way of handling errors in Go is returning them explicitly, and checking for them at the call site.

    func canFail() (int, error) { ... }
    
    value, err := canFail()
    if err != nil {
        // handle
    }

    [Go] doesn't show much awareness of advances that have
    already been made.

Go's response would be to question that the things you're talking about are, in fact, unqualified advances. Especially in the context of large (ie. LOC) systems applications, maintained by large (ie. dozens to hundreds) of developers.

These things, like default global namespace, aren't just bad to a particular class of gray-beard enterprise developers who build AbstractFactoryFactories and are correspondingly easy to ridicule. They're _bad_ bad, net-negative properties of a language. I'm not sure why you would (appear to) defend them. Can you please clarify?

1. Understanding JavaScript type coercion correctly, including (emphasizing!) all of the corner cases that actually matter, is not an hour's task.

2. The fact that pathological-condition-X of a language is in theory understandable with sufficient study is a total red herring in a broad discussion of that language.

As a sort of meta-commentary, why is this presentation two hundred and twenty four (224!) slides long? Am I alone in thinking this is totally, absurdly unreasonable?

Another popular coworking café in Kreuzberg is The Nest, http://cafenest.de.

    Drinking and smoking are allowed in the underground stations.

Drinking is, but only beer (I think some max ABV%). Smoking is not allowed, though it doesn't stop some people, I guess.

    And those on Mac should be able to use:
    
    $ brew install c

Wow, uh, didn't it strike you that this might be a bad idea?

    Datagrams are encrypted and authenticated using
    AES-128 in OCB mode.

I'm curious to know more details. Does it leverage existing SSH auth infrastructure (ie. keys) for that, somehow?

    let's say I find a flight for $400.
    Would you pay without seeing details?

Sure. I mean, I would have to trust your system, but you're not emitting any scammy signals, so I basically do.

    we are targeting people who we can help
    the most. That is, people flying to remote
    places, or on complex itineraries, or who
    just want to absolve themselves of the stress.

Fair enough!

I'm also willing to pay, but only once I know what I'm paying for. I can find the flight I want for (say) $500. If this service can get it to me for $400, great! But I'm only going to enter my credit card details _after_ that's been established. Otherwise, what if your "experts" can only find something for $480? Or $525?

This seems totally self-evident to me. Maybe I missed something.

Congratulations to everyone involved.

When someone takes your factory and materials and electricity, you don't have them any more.