tcard

Wren doesn't use LLVM nor claims C-like performance. It's a (fast) dynamic, interpreted language.

Both are worth every penny.

They showcase delightfully a way of understanding and writing software, a kind of down-to-Earth simplicity aesthetics that is usually ditched in favor of sophistication.

I believe we're mostly past the point of favoring such philosophy (the Go programming language being maybe the most recent attempt, only partially successful at it), as it has fallen short of what the world demands from software, but it remains a very valuable influence.

Ugh, thanks. I've edited my comment.

[Removed. I had linked to a fake tweet.]

I'm not even arguing the Catalan government actions aren't _justified_, as the American Revolution may have been. My point is that the Spanish judiciary's reaction is just that of a normal, European, liberal democratic state under rule of law.

(It's my opinion that it's _not_ justified, though: there's a fair chance of getting through the necessary changes to allow a referendum and other self-government demands by following legal procedures, given the current Spain-wide political climate. I believe this is mainly a politically dishonest and populist move by the Catalan government. But that's besides the point.)

I'm not a lawyer and I don't have an opinion on the Spanish government's or judicial system's concrete actions to stop a illegal law to take effect, but: the only websites, posters, etc. being seized are those paid for and organized by the Catalan government. Any association, political party, or individual is completely free to campaign for whatever they want, including independence.

We have a Spain-wide constitution. The Catalan government decided it has a democratic mandate by the people of its region to not abide by it. The NORMAL reaction by the state is to apply it, and stop the Catalan government from breaking it. It's only oppresive insofar laws and the judicial system are opressive.

Disclaimer: I'm a non-nationalist Spaniard living (but not born) in Catalonia. I don't particularly care about Catalan seceding or not (except for pragmatic concerns such as freedom of movement, etc.). I do care about whatever country I live in being able and willing to enforce its laws, insofar they are enacted by legitimate democratic institutions (and thus can be changed or repelled by democratic means) and there's freedom to disagree with them.

I also support a secession referendum for Catalonia. There's a very strong and majoritary demand for it that the state should address. But it needs to happen in due lawful process.

> I can't recall ever seeing code like this in the wild, and if I ever saw it in a code review, I would certainly tell the author to rename the local variable.

This is somewhat common in Go, specially when capturing a for-loop-scoped variable in a closure. It's even recommended in the official FAQ [1].

1. https://golang.org/doc/faq#closures_and_goroutines

A great take on this topic is a talk by Evan Czaplicki, creator of Elm, another functional language: Let's be mainstream! [1] The conclusions are more or less the same than the article, but Evan goes into a lot more depth. And in my opinion, as a result, Elm does very good in this regard.

[1] https://www.youtube.com/watch?v=oYk8CKH7OhE

At the very least, you get as code reuse mechanisms: functions, ad hoc polymorphism via interfaces, struct and interface embedding, and reflection.

The official compiler doesn't. Then there's llgo [0] and gollvm [1].

[0] https://github.com/go-llvm/llgo [1] https://go.googlesource.com/gollvm/

Now that you mention Quake 3, this article [1] by John Carmack himself on the subject is interesting, and then someone reviewed the source code from Doom 3 [2] where apparently they put some of that in practice.

[1] https://web.archive.org/web/20130819160454/http://www.altdev... [2] http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-...

Separation of concerns: the code handling the envelope doesn't need to know about the format of the payload. The JSON in that payload will only be encoded (on the sender) and decoded (on the recipient) once.

I don't think this is misguided at all. I've heard right-wing people say work hours should be an employee-employer agreement that shouldn't concern the government. The author argues, quite civically in my opinion, that one can disagree with this particular example but that shouldn't interfere with the main point.

It's not a feature for a user. If you're sharing a piece of code for the hacker (as in _Hacker_ News) community to check out, the language it's written in is definitely relevant.

Yes. Disclaimer: I'm one of those.

I started a degree, but dropped out. It was just a waste of time and money, "learning" and doing what they put before me, which often was outdated, badly presented, silly or plain wrong (this might be different in a good college, I tried three different Spanish ones). I could just go and learn by myself the right things, from the right sources (seriously, the Internet is full of _amazing_ stuff), both theoretical and practical.

If something, I wish I could take back all that time and money rather than go back and finish. I never had a problem so far on getting hired or learning what I want or need.

Not in this context. It's an old functional programming language that influences a whole family. https://en.wikipedia.org/wiki/ML_(programming_language)

But that wasn't true either at the time of Go 1.1, nor ever I believe. It was the _default_ behavior to have a single core running at a time, but you could just tweak that with the [GOMAXPROCS](https://godoc.org/runtime#GOMAXPROCS) variable, documented everywhere. (That's what changed in Go 1.5; now the default for GOMAXPROCS is the number of cores in the machine.)

I found interesting what Rust's Graydon Hoare had to say about it:

"It's very similar to earlier versions of rust. In terms of actor local GC, language provided scheduling of actors, separated function and async invocation system, mixed structural and nominal types, and an overabundance of language supported reference qualifiers. I think they did a good job at it, certainly much better than I did, but I'd be nervous about the cognitive load of the reference qualifiers (capabilities). See this page for example, or the previous few in the tutorial. We had that sort of cognitive load on variables early on and people basically rejected the language because of it, as well as associated compositionality problems. The many years of design iteration had a lot do to with factoring that space into fewer, more essential and general qualifiers. Slow, tedious, world breaking refactoring work. I hope for pony's sake this doesn't happen to them too -- it looks really nice -- but that's my biggest worry for it."

http://www.reddit.com/r/rust/comments/34rszb/pony_type_and_m...

I don't think so. It seems to me that they did a good job on the interface between Objective-C and Swift, so one could perfectly live without the other. Objective-C constructs are exposed as native Swift constructs.

It is by design. All those work in the same direction:

    dest = src // Variable assignment.
    <-ch; // Read from channel.
    // in net/http
    type HandlerFunc func(w ResponseWriter, req *Request)
    // in io
    func Copy(dst Writer, src Reader)
    // builtin
    copy(dst, src) // Slices.

So the reason is consistency. I suppose the Pipe exception is to map Unix's pipes.

As I understand it, he is pointing out that people who really get deep into using the language with a constructive purpose don't complain about such perceived issue. Also a pun against early judges.

He wrote more about this here: http://commandcenter.blogspot.com.es/2011/12/esmereldas-imag...

EDIT: Well, the answerer of that question was Robert (Griesemer), not Rob (Pike), but I suppose the same applies.

I'd bet Pike, Thompson and Griesemer, as Google developers themselves, knew Google's problems for developers even better than "Google as a corporate entity" would have. It's true that they weren't asked by anyone upstairs to face these problems, but that's how Google works.

It's just a shortcut, not essential. You have help links in each Markdown-capable textbox anyway.

Those people could, you know, not use Google. But I bet there aren't/won't be many of those in practice.

Out of curiosity, I made a comparison between the two towns where most of my photos are taken as seen in GMaps vs. OSM.

http://cl.ly/133M1H3W2W362S2F0l13 http://cl.ly/2P2d3y042N1T0o2p390H

600k and 60k inhabitants respectively.

A quick glance at the sources shows immediately what Go offers per se in terms of readability and maintainability. Go strongly encourages, even forces at compile time, certain style constraints that results in such a delightful code to explore. Were it written in C, you'd have to deal first with arcane #whatever directives in .h and .c files and strange makefiles and such stuff.

I hope someday Go will get the acknowledgement it deserves as a real piece of genius. I really encourage recommend just to take a 15-min try at http://tour.golang.org.

I find the whole point of the article to be weak, to say the least. OK, I'm doing monads, or something equivalent to monads, all the time along my imperative code without even noticing because it's so intuitive concept. So when this common abstraction of "conditional function calls" is made explicit through monad syntax instead of intuitive-implicit, it is supposed to be easier to deal with?

Perhaps it's cleaner, and you can get accustomed to it, but it surely comes with an overhead over imperative thinking, at least for a beginner.

That's like saying that the 'T' letter key on the keyboard behaves unpredictably and should be removed just because any program could map it to any other character or action.

JS semicolons are actually encouraged —omitting them, while syntactically valid, can lead to obscure bugs. http://bonsaiden.github.com/JavaScript-Garden/#core.semicolo...

That's a common thought from anybody who first looks at Go code. But when you play around a little you realise that all these sharp syntax constructions happen to increase pragmatism, they are well-thought to make the coder happy.

I think that Go syntax falls into something like an uncanny valley —so similar to C-like languages that you instinctively compare it to them but just so different that it feels weird at first. But you'll love it.