Rust will be the language of the future

Rust will be the language of the future. I bet on it.

What does it even take for a language to become successful?

Well, lots of things I think but at the very least it should have a unique selling point. Something that makes the language stand out and is attractive to developers.

In 2009 I was all excited about Node.js. I was writing web servers with ASP.NET at that time. Suddenly evented I/O was there to teach us how all our threading was bad for scalability. That combined with the promise of sharing code between the client and the server got all of us excited…Yay, five years passed since then.

Well nowadays it’s all about the march towards Go it seems.

So what does Go bring to the table? First of all: It’s a compiled language. For the last thirty years or so we’ve seemed to focus on interpreted languages or such that operate on a Virtual Machine. Think Java, Scala, C#, F# JavaScript, Python, Ruby and so on.

Now it’s all the fuzz about compiling to native code again. Even the .NET team just recently announced that you can now compile your C# code to native code to get the speed of C++ with the joy of C#.

So one of Go’s claims is to be fast just like C++ but without the pain of C++. It also offers a great answer to parallelism with goroutines and channels. In a few words: threads without the costs of threads[1]. Green threads.  Yeah, sounds great! As a language geek that got me hooked as well. Well not for long. Go is simple. It’s easy to learn. Great. But…On the other hand. It’s just a little *too* simple for me. No generics, barely any functional programming influence, it has nil (null). I quickly came to the conclusion that Go is not good for me.

So, what’s up with Rust?

Rust is a language by the awesome folks of Mozilla. It’s entirely developed in the open (that alone is such a huge win!) and it makes big claims that have potential to disrupt our current programing language world.

One of it’s biggest claims is that you can use Rust for projects that previously would have been written in C of C++. Like kernels, operating systems or browsers. Not even Go in it’s current form could make such claims because it’s not low level enough.

Rust on the other hand tries to achieve two things at once. Being low level and being high level at the same time! This is the most exciting part for me!  On one hand Rust is a very modern language. It has generics, traits, it is expression orientated, has pattern matching, closures and a lot of other exciting features.

On the other hand it is very low level, too. It doesn’t use garbage collection by default. It just defines a couple of new rules that the compiler enforces on you *at compile time* which eliminates the need for a garbage collection. That said, you still can apply garbage collection to certain parts of your program if you need to!

But it’s not just all about garbage collection. It also lets you take deep control about heap vs stack allocations that for instance wouldn’t be possible in Go because Go’s compiler uses escape analysis to figure out if something should go on the heap. So basically, you can have all the low level control you need, when you need it!

But does that mean that it’s restricted to low level systems programmers? I don’t think so! Speaking for myself, I’m certainly not a low level systems programmer. I wish I had C or C++ skills. Unfortunately I coded with pampers on for all my live. I used BASIC, Visual Basic, PHP, Java, C#, F#, JavaScript but I never used C or C++[2].

Whatever! I’m currently getting my feet wet with Rust. I started to work on a web application framework for Rust that aims to be simple. Nickel.rs.

Does this look too low level to you (apart from the terrible syntax highlighting)?

extern crate http;
extern crate nickel;

use std::io::net::ip::Ipv4Addr;
use nickel::{ Nickel, Request, Response };

fn main() {
    let mut server = Nickel::new();

    fn a_handler (_req: &Request, res: &mut Response) {
        res.send("hello world");
    }

    server.get("/bar", a_handler);
    server.listen(Ipv4Addr(127, 0, 0, 1), 6767);
}

This is a simple nickel.rs application. I think it doesn’t look too scary for anyone ever written a web application in express.js. I’ll talk about it at the next Rust Bay Area meetup.

Leave alone the language for a moment. The community is great, too!

I’m probably the one with the most stupid Rust questions on StackOverflow but people invest a lot of time to put together great answers. And as I’m writing this people  on IRC help me to get the wording right.

And dear reader, if you are looking at this from a JavaScript or Ruby angle, you might be surprised to find some familiar faces. Yehuda Katz, EmberJS and Ruby on Rails core developer is currently hard at work to work on a package manager and several other libraries for Rust.

If you didn’t take a look at Rust yet I highly recommend to do so…

[1] Not trying to be accurate.  Go hacker news, kill me.
[2] Not 100%. I tried C++ with the age of 11 but failed miserably.

Some advice for Go debugging with gdb

I’m currently getting my feet wet with Go. I quite like the language but when it comes to debugging I I’m still trying to get warm with what it offers. I’m just not the “printf” kind of guy. I want a real debugger which I can use to step through the program flow to investigate (and manipulate) state.

Go programs can be debugged using the gdb debugger. I’m slowly getting warm with it and I thought I share some advice.

1. There is a Sublime plugin for gdb but my current feeling is that I rather use gdb directly on the command line

2. create such two aliases for your command line:

alias god=‘go build -gcflags “-N -l”‘
alias godrun=‘go build -gcflags “-N -l” -o debug && gdb debug’

The `god` command just compiles your go app with all useful debug flags and uses the default program name for the output file. The `godrun` command uses a hardcoded name “debug” as the output file name and directly feeds it to gdb so it’s as easy as calling “godrun” to start debugging. Yay!

3. Put “debug” on your `.gitignore` file to not commit this special debug build to your repository

4. If you want to see the value of, say, a struct behind a pointer the syntax in gdb is `p *’&varName’` (yep asterisk outside the quotes, then the varName in quotes with an ampersand prepended). 

5. Each print in gdb assigns the printed variable to a temporally $-prefixed variable (e.g. $5) which can be used from then on (e.g. `$5.SomeStructProperty + 1000`

6. Variables can be manipulated with `set variable varName=value (e.g. `set variable varName=1000` or `set $5.SomeStructProperty = 1000`)

Those are just random findings and might be totally obvious if you ever worked with gdb before. However, chances are that if your are looking into Go, you are actually NOT coming from the lower level language eco system (e.g. C/C++) but rather from higher level eco systems such as Node.js or .NET.

On famo.us, semantic html and the future for web apps

Now with famo.us being out of private beta and the code being online I was eager to take a closer look.

I stumbled over this talk by Steve Newcomb the CEO of famo.us.

It’s *super* interesting to watch this stuff. Go watch it!

It would be very interesting to take some time to play with famo.us sometime soon. What’s interesting though is that it’s an entirely different paradigm than what AngularJS, Polymer, vue.js or even WebComponents are after.

They basically say that the gaming industry got rendering right (minute 43:35), and and the web industry got everything else right and they are trying to combine it. They don’t believe in semantically correct HTML for web apps. They say this stuff is for documents and no one should care about it building web apps. That’s also what Sencha is telling people.

It’s interesting and a part of me agrees with that. On the other hand, HTML is awesome for designers to work with. People even start building things *outside the browser* (think: githubs Atom editor) with web technology *because* of HTML/CSS.

I remember that working with Sencha was a pain from a designers perspective *because* you work very decoupled from the underlying HTML.

It really seems people are strongly divided about the direction the web is taking. Google seems to strongly believe in semantic html and to enrich it for web apps. Angular, Polymer, vue.js, WebComponents are all projects strongly driven by Google. From the perspective of a company driven by ad sales this makes perfect sense. Semantic markup has great value for Google as a search engine / ad selling company.

On the other hand there are companies like Apple, Sencha, Famo.us which do *not* believe this would be the right way forward.

I can’t say that I have a clear opinion about this stuff. Just that it’s an interesting observation.

Aside

StackWho is now ninya.io

A couple of weeks ago I blogged about StackWho - a project to search for users on StackOverflow by their location and skills. Today I’m happy to announce that StackWho is now ninya.io!

Why the new name?

I felt that it was just too tightly coupled to StackOverflow. I’m planning to increase the scope of the project by combining different sources. I’ll soon leave more words about that…

With the new name, we knew that it was also time for a really cool logo.

 


We were lucky to have @oriSomething join us and support the project with his awesome design skills! You should definitely send him hugs on twitter!

Is this a true open source project?

I have been asked this question a couple of times so I want make this 100 % clear: There isn’t a single bit of code of this project that is not on github or not covered by the MIT license. You find all the code at our ninya organization on github and if you ever find a repository that is missing the MIT license, just send a PR and I promise to merge it instantly. Everything about the project will remain open source as long as I am in charge of things. And btw, you should really star the project here!

That being said, I have bills to pay for this project and if you are feeling generous feel free to leave a tip here :)

What’s coming?

Yep, lots of things. There’s a new sync API brewing which will make it much easier to sync with more sources. It will also drop the postgresDB dependency.

It’s also planned to overhaul the entire design of the website and to create a real ninya blog. Stay tuned.

Tag related sorting just landed in StackWho

StackWho just got a nice update which makes it much more useful! Previously results were always sorted by the users reputation. That’s probably what one would expect if you only search by location.

However, once you start searching by tags you would probably expect that the sorting relates to such tags. Fortunately that’s exactly how things work now :)

This makes for some very interesting queries. If you combine multiple tags then the results will be sorted by the cumulated answer score of such tags.

For instance those are the users from Hannover, Germany sorted by cumulated answer score for the tags javascript, angularjs and git.

This is just scratching the surface of what’s planned for the future. I migrated the search to use ElasticSearch to expand the feature set. Previously the search was implemented on top of postgresSQL (used as a NoSQL DB) which was fine for the beginning but I felt I can move faster by migrating to ElasticSearch.

StackWho is entirely open source and MIT licensed, if you like to get involved, head over to the repository and help shaping it’s future. If you don’t like to directly contribute you can still help if you star the repository on github and share this blog post as much as you can :)

What out for more awesomeness coming soon!

Aside

Introducing StackWho

I’m working on this little side project and I thought I share some words about it.

So, I wanted to figure out other StackOverflow users from my city and filter them by skill set. Turns out that’s not possible by default with the search provided by StackOverflow. Oh wait, it is! They have a thing called “Candidate Search”. Unfortunately a one month subscription for the candidate search costs 1000 $.

And of course the API provided by StackOverflow doesn’t make it easy to run such queries either. However, what you can do is just scrape the entire[1] user data of StackOverflow and then build such a search yourself.

Introducing: StackWho.

It’s pretty rudimentary at this point. You can enter comma separated locations to combine users from multiple cities (or to alias different spellings) and you can enter multiple tags which the users should have as their top answer tags.

Bild
The data is continuously synchronized with StackOverflow[1] which means user data should usually be only a couple of days old. The frontend is written with AngularJS and the backend is built with NodeJS and split into a query and a sync part. It’s hosted on heroku. Everything is MIT licensed and I’m happy to merge Pull Requests :)

Also any feedback is highly welcome! Now go and check it out the top users from San Francisco & Berkeley with strong AngularJS or NodeJS skills: Check it out here!

[1] I currently only sync the top 150k users

A flexible team- five things to get right

On the first of November 2012 I joined CouchCommerce to lead the frontend development. Here are five things that I highly enjoy here and that I think make my life easier and more fun.

1. Use a notebook + monitor  approach rather than a PC + monitor approach

At my previous job I used a regular PC at the office with three monitors attached. Not that they forced me to use that, I could have had any system when I started my job. But since nobody worked on a notebook, it was the obvious choice to use a PC as well. It was the fasted machine one could think of. 16 GB Ram. Core i7. Fast SSD drives. The machine was super swift and never let me down.

At my new gig here at CouchCommerce everyone used MacBooks with only one monitor attached. Since every web developer seems to work on a MacBook these days it again was the obvious choice to align with that :) It’s the fastest retina MacBook you can  buy. I don’t like to make compromises when it comes to speed. I take my work seriously and same goes with my tooling.

It was a bit of a hassle at first to get used to work with only two physical screens but since you can use multiple virtual screens on OSX  I quickly got used to it. I don’t want to go into too much detail about how the switch to OSX went. There are plenty of other good posts on that topic.

The point is: using a notebook/MacBook + monitor is so much more convenient than using a stationary computer + monitor. Previously I used to work on three different machines:

- my office PC
- my PC at my home office
- my notebook

Multiple systems lead to multiple problems:

- I had to maintain three different machines with tooling, updates etc
- I often forgot to push code so when I worked from home I had to ask a team mate at the office to boot my computer. Or even worse I forgot to push code after a day of doing home office so I was lacking the code when I returned to the office

I really enjoy having only one system. I’m sometimes in the middle of a coding session when I decide to close the lid and go home. At home I can directly continue with my work. I also have the latest stuff with me. May it be on the train, at a conference or at the office. I also only reboot once every couple of months or so. That makes my life so much easier.

2. Be flexible.

That goes hand in hand with the previous issue. In my six month at CouchCommerce I already had four different work places. The team went from 4 people to 10 people within that time. We rearrange desks, switch offices just as it fits our needs. That also relates to everyone working on a MacBook. The setup is just super lightweight. We also regularly try out new software that has the potential to make our life easier.

3. Use dropbox and google docs for file Management.

I remember file management often was an issue at my previous job. We used to put documents on a central file server. Files went quickly out of date and manually versioning with multiple dated file names didn’t make it any easier.

I highly enjoy working with team mates together on one google doc. Everything stays in sync. Automatic version control makes sure nobody has to lose their sanity.

4. Use a company social network like yammer.

Well yammer, has it’s own dark corners. It’s not all milk and honey. However, we also tested several other company social networks and didn’t come across any better one so far. In general it really helps to get everyone up to date dramatically. It’s an important cornerstone of our communication. We always know about who is where. We share code improvements, interesting articles, fun stuff, being off, doing home office.

5. Speak english. Prepare to go international.

One thing that always bothered me at my previous employer was that we used too much German. Code comments where made in German. Some variable or methods where named in German. Technical documents where written entirely in German. That makes it much harder to scale the team.

Here at CouchCommerce three of my team mates don’t speak German as their mother language. We use ca. 95 % English when communicating through yammer and  at least 60% English when talking directly to each other at the office. Our product was designed English-first, German-second. All our technical documents, the entire code base everything is entirely written in English. We can easily scale our team and employ people from all around the world.
Those things might or might not work for your. Works for us.