first experience with Rust

(by )


tl;dr: Rust code for the SIMPLE language available in a git-repo.


I had some spare time yesterday after I finished my last-ever bachelor exam (yey!) so I took my chances and started to write some Rust. Just two days ago I also started to read Tom Stuart’s book “Understanding Computation”. In Chapter 1, “The Meaning of Programs”, he introduces a small and simple programming language called SIMPLE. By using a small-step approach and Ruby as the language of implementation he builds up the virtual machine to execute an already built AST. Go read the first chapter, it’s in the sample (and thus free) to get a better idea. The original code is some simple to understand Ruby, just under 200 lines.

It has:

That’s nearly all it takes for a programming language. Usage of the Ruby code looks like this:

>> Machine.new(
    Sequence.new(
      Assign.new(:x, Number.new(3)),
      Assign.new(:res, Add.new(Add.new(Number.new(38), Variable.new(:x)), Variable.new(:y)))
    )
    { :y => Number.new(1) }
  ).run
x = 3; res = 38 + x + y, {:y=>«1»}
do-nothing; res = 38 + x + y, {:y=>«1», :x=>«3»}
res = 38 + x + y, {:y=>«1», :x=>«3»}
res = 38 + 3 + y, {:y=>«1», :x=>«3»}
res = 41 + y, {:y=>«1», :x=>«3»}
res = 41 + 1, {:y=>«1», :x=>«3»}
res = 42, {:y=>«1», :x=>«3»}
do-nothing, {:y=>«1», :x=>«3», :res=>«42»}
=> nil

Because we build the AST by ourself instead of taking a lexer/parser to do the job, the example takes a bit more code than you would think. But it still is simple enough to grasp.

Now the same small sample “programm” in Rust:

let mut env = HashMap::new();
env.insert("y".to_string(), number!(1));

let mut m = Machine::new(
    sequence!(
        assign!("x", number!(3)),
        assign!("res", add!(add!(number!(38), variable!("x")), variable!("y")))
        
      ),
    env);

m.run();
// Add this point `res` in the HashMap will be `Number(42)`

Yep, not much of a difference. It will even output the same steps as above (but without the environment hash). The full code is available in a git repository.

I don’t want to explain each and every peace of that code, but instead focus on what I learned about Rust.

Use the docs

There are API docs as well as a Reference Manual and even more general documentation (all links are the nightly versions as I use that). But Rust is in active development. Things are changing fast. Documentation on features might be outdated (especially older blog posts or StackOverflow answers) or even missing (but it gets better with Steven Klabnik working full-time at it). Get familiar with the Standard Library and its docs. Often you need to read that to fully understand how to use a certain data structure or how to implement a specific trait for your code.

Document your code. Rust makes that real easy. Comments are parsed as markdown (you know that already, don’t you?) and rustdoc generates a static HTML site from your code (all the API docs are generated this way).

Don’t fear the errors

The error and warning messages of the Rust compiler are great. Most often they actually find simple mistakes (wrong variable name, missing self) and actually tell you how to fix it. Other times, even though the message is quite clear, it’s not clear how to properly fix your code to compile. But when it compiles, it actually did what I wanted it to do. Most of my errors or “design mistakes” were caught by the explicit type system and safeness checks. Everytime I googled an error message I ended up in the GitHub issue tracker of Rust. Sometimes this helped as it clearly discussed the problem and gave useful answers.

Test your stuff

Rust comes with in-built test support. Simply tag code with #[test] and it will only be compiled and run if you pass the --test flag to the compiler (or use cargo test). It was the first time that I actually ended up doing TDD: First a small test, see it fail, fix the code, see the test pass, refactor if needed. Extend tests. Just super convenient, but make sure to extract your tests in larger code bases (huge files won’t help anyone).

Use language features

Pattern matching is nice. It often saves you one or two more if statements. Just deconstruct your object right in the pattern match. Macros are a nice addition, too. The pure Rust syntax might be a little bit verbose sometimes, so just save some keystrokes for your convenience and use a short macro (please, don’t over-do it, the docs explicitely say that macros are harder to debug than pure Rust code). Make sure you’re editor has proper language support, rust.vim worked quite good for me and did everything right from the start.

I still need to learn about a few Rust features.

Summing it all up

Yes, Rust is more verbose than Ruby. Yes, it’s much more strict than C or Ruby. Yes, it’s not yet ready and changing fast.

But its concepts are nice. More safe and robust code just by more explicit type checks and immutable by default make you think more about the actual application design. They catch errors before you even run the code and make it easy to explicitely state the intent of your code (“code should be self-documenting” ;)).

I don’t see me writing lots of Rust code in the near future, but it certainly helps to once in a while have a look at different systems to learn.

eurucamp 2014 - Video & Photos

(by )

Great short video documentation of eurucamp 2014 (by @polarblau):

eurucamp 2014 from Polarblau on Vimeo.

Some photos are uploaded to the eurucamp flickr group.

eurucamp 2014

(by )

eurucamp chalk

I’m just heading back to Aachen from eurucamp 2014. And all I can say is: What an awesome conference!

I met a lot of great people, had nice chats with a lot of new people, heard a lot of great and inspiring talks and had a lot of fun.

Besides the usual stuff you expected at a tech conference. there were also a lot activities happening. It started with the conference party Friday evening. Saturday noon was reserved for lots of activities, kayaking on the Griebnitzsee, with a jump into the sea afterwards of course, a slip’n’slide on the venue’s lawn and some football there as well.

During the talks I took some notes, just to remember things for myself, but I think it’s also a good idea to write these down publicly. There was also the Camp Compressor, the eurucamp’s own podcast, with interviews of speakers and attendees. Listen to it to get even more cool discussions and information.
(Hint: I was interviewed for Episode 3 ;))

Workshop: How to do Static Analysis Driven Refactoring

Friday afternoon I went to the Workshop How to do Static Analysis Driven Refactoring. Christophe showed us how a few tools can help to improve and refactor your existing code base. The whole list of tools is listed in a Gist. He made it clear how these tools lead to better code quality, especially if you’re a small team or even working alone. I will definitely try to use some of them.

Keynote

In the evening the real conference began with nusco’s keynote. He told us about how to be a really great developer. There are 3 stages in most things:

  1. Simple, most of the time you can automate this away.
  2. Complicated. You have to think about the problem, but if you’re good you find a solution
  3. Complex. These are the hard and most interesting problems. If you want to be a great developer you need to tackle these. For this you have to always learn.

But it is especially important to don’t just work on problems in one category. No one is a great developer from day one. Learn everyday. Be a great developer at the end of the day.

Culture Eats Products For Breakfast

Saturday started early. Laura told us how Culture influences your product. If you already have a project it’s not that easy to get it into a new market in a new country with a complete different culture. The audience for your product has completely different expectations, the country may have different laws. All these things need to be considered to be successfull.

rin live-coding a game

Let’s build a game with Ruby

Right after that, Rin gave a short live coding session in which she created a small side-scroller game using Gosu, a 2D game development library. Quite fun and easy it seems.

It Takes a Village to Make a Programmer

After a short coffee break Michele told us her story. She attended eurucamp last year and with the help of some great people from the community she managed to switch careers in less than a year. She encouraged all of us to give back to the community, help other people, mentor people or help people in otherways.

Internet of Dusty Things

Daniel talked about his DIY air purifier. Unhappy with the available proprietary and expensive products he sat down, purchased the necessary hardware and built a remote-controlled air purifier using mruby, a lightweight implementation of the Ruby language and some stripped-down libaries.

RubyMotion and Accessibility

One of the best talks for me was the one about Accessibility held by Austin, a blind developer. He’s using both an iPhone and a Mac, because all of these Apple systems have built-in accessibility features, like Voice Over, the screen reader in iOS and OS X. He also wrote software for RubyMotion to make accessibility-testing even easier and showed how easy it is to make iPhone apps more accessible. It’s build in by default anyway, adding information and labels is already a great improvement for every app. Test these things!

taking a brake in the shadow

Griebnitzsee

Refactoring Ruby with Monads (or, Monads: The Good Parts)

Tom gave one of the funniest and simplest introduction to Monads I heard. With just a few lines of Ruby code it’s possible to implement Monads, which are just an “abstract data type”. The code is available as a gem and on GitHub.


Lightning Talks

@benlovell: Eurucamp is so awesome that actual lightning ended the lightning talks #ec14
(Twitter, 10:52 PM - 2 Aug 2014)

(That’s all it needs as a comment)

Beautfiul sunset over the venue's lawn

Utils is a Junk Drawer!

Day 2 once again started early. Frank took a look at what’s in the project’s utils folder, often it’s junk. The speaker was interviewed in the Camp Compressor, Day One. As I heard that on the train ride to the venue I didn’t listen too much in the talk, sorry!

The Scientific Method of Troubleshooting

Blithe explained how the Scientific Method of Troubleshooting will help in software development as well. When troubleshooting, sometimes take a step back. Solving each and every problem by googling or looking at StackOverflow won’t help. Instead think about the problem, try to understand why it happened, how it can be fixed correctly and how to avoid it to happen again. Document your troubleshooting, improve the documentation of your project so problems that were fixed won’t happen again. And get help! If you can’t solve the problem alone, talk to others. Sometimes that is all it needs.

Take note!

Såndra gave a short introduction how visual note taking can help to efficiently take notes and later also actually remember what you meant. Now if I could just draw better, but maybe with some practice I can do this better. Oh, and she had the most awesome slides of all talks!

Decentralize ALL THE THINGS

The last talk I (really) heard was by Jan. He talked about how all these centralized services are bad in nearly every aspect. But it’s not only about self-hosting all your stuff (because that’s not an option ever), it’s also about decentralising our organisations and businesses to make the internet resilient against any kinds of threats again.

…and that’s it.

The whole weekend ended with some beers at the eurucamp after party, again talking to a lot of different people, and a lot of different topics. I hope there will be a eurucamp 2015, because we’re already planning things for next year.

Thanks to the whole eurucamp team, thanks to all speakers and thanks to all the great attendees! Hope to see some of you at RedFrog Conf in just 2 weeks or at RailsCamp Germany in September.

Extending Redis with Lua packages

(by )

Warning: If you patch your Redis as stated below, you won’t get much support from the Community.
Do not run this in production! You have been warned.


Redis comes with in-built support for Lua scripts. Using eval (or evalsha) it is possible to execute scripts right in the context of the Redis server. Redis provides some guarantees for these Lua scripts: Lua scripts are atomic and do not interfere with other scripts or normal commands. Redis tries its best to provide a sandbox you’re scripts are evaluated in, but it won’t stop you from doing stupid things.

This sandboxed mechanism also means that access to any external resources is not allowed. No IO, no external libraries (except thus already provided) and especially no compiled modules.

But what if you want to use a library anyway? Well, it’s actually not that hard. Three days ago a user came to the IRC channel (#redis on freenode) to ask how to use LGMP, an adapter to the GNU multiple precision arithmetic library, in Redis.

After some fiddling around I provided a solution:

First patch your local Redis checkout with the following patch:

diff --git i/deps/Makefile w/deps/Makefile
index 5a95545..9ec62be 100644
--- i/deps/Makefile
+++ w/deps/Makefile
@@ -58,8 +58,8 @@ ifeq ($(uname_S),SunOS)
  LUA_CFLAGS= -D__C99FEATURES__=1
 endif
 
-LUA_CFLAGS+= -O2 -Wall -DLUA_ANSI $(CFLAGS)
-LUA_LDFLAGS+= $(LDFLAGS)
+LUA_CFLAGS+= -O2 -Wall -DLUA_ANSI -DLUA_USE_DLOPEN $(CFLAGS)
+LUA_LDFLAGS+= -ldl $(LDFLAGS)
 
 lua: .make-prerequisites
  @printf '%b %b\n' $(MAKECOLOR)MAKE$(ENDCOLOR) $(BINCOLOR)$@$(ENDCOLOR)
diff --git i/src/scripting.c w/src/scripting.c
index ef00eed..c7f3735 100644
--- i/src/scripting.c
+++ w/src/scripting.c
@@ -549,10 +549,8 @@ void luaLoadLibraries(lua_State *lua) {
     luaLoadLib(lua, "struct", luaopen_struct);
     luaLoadLib(lua, "cmsgpack", luaopen_cmsgpack);
 
-#if 0 /* Stuff that we don't load currently, for sandboxing concerns. */
     luaLoadLib(lua, LUA_LOADLIBNAME, luaopen_package);
     luaLoadLib(lua, LUA_OSLIBNAME, luaopen_os);
-#endif
 
}
 
 /* Remove a functions that we don't want to expose to the Redis scripting

This makes sure the provided Lua is compiled with support to load modules and it actually enables the package module in the embedded Lua interpreter (it also enables the OS module). The package module will then provide the require method used to load external modules.

Next compile your Redis as usual:

make distclean # Just in case it was compiled before
make

Next, grab a copy of the LGMP files from Wim Couwenberg (Direct link, .tar.bz2, make sure to grab the Lua 5.1 sources). Unpack it to a location, e.g. ~/code/lgmp and compile it:

gcc -O2 -Wall -lgmp -o c-gmp.so lgmp.c -shared -fPIC -L ~/code/redis/deps/lua/src/ -I ~/code/redis/deps/lua/src

Adjust the paths for -L and -I to point to the Lua bundled with Redis.

Once this is done, just start the Redis server (but make sure you do it from the directory with the gmp.lua and c-gmp.so):

~/code/redis/src/redis-server &

Alternatively copy gmp.lua and c-gmp.so to the libraries the following command gives you:

$ ~/code/redis/src/redis-cli eval "return {package.cpath, package.path}" 0
1) "./?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so"
2) "./?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/usr/local/lib/lua/5.1/?.lua;/usr/local/lib/lua/5.1/?/init.lua"

As the last step, use the library:

$ ~/code/redis/src/redis-cli
127.0.0.1:6379> eval "local gmp=require'gmp'; return gmp.version" 0
"6.0.0"
127.0.0.1:6379> eval "local gmp=require'gmp'; local x = gmp.z(123); local y = gmp.z(456); return x:add(y):__tostring()"  0
"579"

And that’s it. That’s how you can load external modules into the embedded Lua interpreter. Again: Do not run this in production! It may break at any time, it may erase your hard drive or kill kittens.

(These instructions are also available in a short Gist.)

OpenTechSchool - Javascript for Beginners

(by )

2 month ago I coached at OpenTechSchool’s HTML & CSS for Absolute Beginners workshop. This weekend I once again helped at one of their workshops, this time Javascript for Absolute Beginners.

What should I say? It was again a great experience. It were less learners this time, but the ones that attended where very motivated and eager to learn new things. The material (Day 1, Day 2) was again provided by the OpenTechSchool movement and also translated into German. After just the first day, there were already great programs implemented, e.g. a star system, with rotating planets and moons.

The second day was a little less packed, but again all attendees worked their way through the material, asking interesting question and I did my best to answer them. But sometimes I couldn’t and needed help from the other coaches or even a quick online search to give a correct answer. (Would you know how to describe the difference between null and undefined in Javascript in about 1-2 sentences to a first-time programer?)

This time there was a small lottery. The winner already blogged about his experience: Cool JavaScript stuff I learned at the Open TechSchool workshop.

For this lottery I hacked a small and completely fair(!) winner-picker with the same tools/code also available to the learners. As requested the code is available online in a gist.

A big thanks again to the organizers of the OpenTechSchool Dortmund Team! Spread the word, attend meetups and workshops and use the chance to coach!