The State of Go & Go in Go

From C to Go

The gc tool chain has been converted from C to Go.

Machine-translated compile tool replaces 6g, 8g, etc.
Machine-translated link tool replaces 6l, 8l, etc.
New asm tool replaces 6a, 8a, etc.

Go 1.5 has no C code in the tool chain or runtime.

Rob will talk more about this.

http://talks.golang.org/2015/state-of-go-may.slide#1

Go in Go

As of the 1.5 release of Go, the entire system is now written in Go.
(And a little assembler.)

C is gone.

Side note: gccgo is still going strong.
This talk is about the original compiler, gc.

http://talks.golang.org/2015/gogo.slide#1

Rust for Python Programmers

“Now that Rust 1.0 is out and quite stable, I thought it might be interesting to write an introduction to Rust for Python programmers. This guide goes over the basics of the language and compares different constructs and how they behave.

Rust language wise is a completely different beast compared to Python. Not just because one is a compiled language and the other one is interpreted, but also because the principles that go into them are completely different. However as different as the languages might be at the core, they share a lot in regards to ideas for how APIs should work. As a Python programmer a lot of concepts should feel very familiar…”

http://lucumr.pocoo.org/2015/5/27/rust-for-pythonistas/

Pregel: A System for Large-Scale Graph Processing

“Pregel: A System for Large-Scale Graph Processing – Malewicz et al. (Google) 2010

“Many practical computing problems concern large graphs.”

Yesterday we looked at some of the models for understanding networks and graphs. Today’s paper focuses on processing of graphs, especially the efficient processing of large graphs where large can mean billions of vertices and trillions of edges. Pregel is the system at Google that powers PageRank, which makes it a very interesting system to study. It is also the inspiration for Apache Giraph, which Facebook use to analyze their social graph.

There are single machine-sized graph processing problems, and then there are distributed graph processing problems. You probably don’t want to be using a distributed graph processing platform to solve a problem that would fit on one machine (See Musketeer), but if you really do have a large graph, then…”

Pregel: A System for Large-Scale Graph Processing

Lush: Lisp Universal SHell

“Lush is an object-oriented programming language designed for researchers, experimenters, and engineers interested in large-scale numerical and graphic applications. Lush is designed to be used in situations where one would want to combine the flexibility of a high-level, weakly-typed interpreted language, with the efficiency of a strongly-typed, natively-compiled language, and with the easy integration of code written in C, C++, or other languages.

Lush is Free Software (under the GPL license) and runs on GNU/Linux, Solaris, Irix, and Windows under Cygwin.

Lush can be used advantageously for projects where one would otherwise use a combination of an interpreted language like Matlab, Python, Perl, S+, or even (gasp!) BASIC, and a compiled language like C. Lush brings the best of both worlds by wrapping three languages into one: (1) a weakly-typed, garbage-collected, dynamically scoped, interpreted language with a simple Lisp-like syntax, (2) a strongly-typed, lexically-scoped compiled language that uses the same Lisp-like syntax, and (3) the C language, which can be freely mixed with Lush code within a single program, even within a single function. It sounds complicated, but it is not. In fact, Lush is designed to be very simple to learn and easy to use.

If you do research and development in signal processing, image processing, machine learning, computer vision, bio-informatics, data mining, statistics, simulation, optimization, or artificial intelligence, and feel limited by Matlab and other existing tools, Lush is for you. If you want a simple environment to experiment with graphics, video, and sounds, Lush is for you…”

http://lush.sourceforge.net/

Pagination and HTTP caching

“00f.net’s initial blog engine worked that way. Pages URIs were made of timestamps:

http://example.com/1298640310.html

The content of such a page is N documents whose timestamp is greater than or equal to 1298640310.

This scheme works pretty well, because pages can get easily cached and indexed. Pages that don’t get any update can keep the same URI forever.

An article added to the freshest page automatically causes the URI to change, without invalidating the previous URI.

Timestamps were good enough for this blog, but any increasing and globally unique identifier would be a good fit.

The downside of non-monotonically increasing ids is that while it’s easy to jump to older content (“next page”), it can be tricky to get links to previous pages (newer content) without falling into duplicate content or HTTP redirects. But for infinite scroll pagination style, it makes wonders…”

CAP: if all you have is a timeout, everything looks like a partition

“This post is a part of the CAP theorem series. You may want to start by this post on ACID vs. CAP if you have a database background but have never really been exposed to the CAP theorem. This post showing some traps in the ‘Availability’ and ‘Consistency’ definition of CAP should also be used as an introduction if you know CAP but haven’t look at its formal definition…”

http://blog.thislongrun.com/2015/05/CAP-theorem-partition-timeout-zookeeper.html

Understanding Elm

Elm is an unusual programming language as first one needs to learn to think in a different paradigm (FRP). To me, one of the challenges in such a process was to gain sufficient understanding of how tasks and ports are related to each other.

Part of developing an idea in Elm involves understanding the dataflow of your program. In normal imperative programming (say in Python or Java) one essentially constructs a series of operations to perform (thus “imperative”). Whereas in Elm, you define the dataflow. There is no sequence of logical steps to define, hence the paradigm is fundamentally different.

The architectural abstractions entailed in constructing such a dataflow are: models, actions and view. The model describes the current state of your entire program at any point in time; outside of the model, there is no state and everything is ephemeral. Actions happen to the model. Acting upon a model updates it, resulting in a newer model; this is how your program handles state. Finally, the view defines how to render any model on the screen. For more information, see the Elm architecture tutorial…”

http://www.srid.ca/posts/2015-05-24-understanding-elm.html