Here we go another language. Our IT world is full of different languages; I was born when the major and most used languages was COBOL to manage money, FORTRAN to manage numbers and Pascal to teach the real programming. Obviously BASIC for beginner’s… yes and LOGO for kids… oh yes! I remember something about RPG in the environments similar to COBOL… ok you bet! Our world was always full of programming languages but now they appears to be too many.

As the majority of the people born in the seventies like me and approaching the IT world in the mid 80s I began coding with “Beginner’s All purpose Symbolic Instruction Code” – BASIC for friends: CBM Basic for the Commodore guys, Applesoft for the Apple fans; every product has its own dialect; there was an attempt to cleanup this mess with MSX… cool but money wins and this standard passed to the history in few years.

For the people willing to make serious coding C is there; I admit that I don’t like(d) too much C; this things that a string has to be a pointer to an array of char… but as my former friend in USA said times ago “C is a middleware language, one step above Assembly”; ok so, don’t bother with each microprocessor Assembly, write in C and port (quite) everywhere – cool.

Cool until your code crash (while running) with this message:

Segmentation faults

All the times I saw this message I felt like my computer shown me the middle finger! Is like saying me: “F***k off you and your code! It’s wrong!”

Frustrating.

Any more information? What caused this mess? Easy to debug if you’re running the helloworld.c but in real world application may be very frustrating.

New languages like Java is not so much clearer:

Monitor Ctrl-Break #12 daemon prio=5 os_prio=31 cpu=17.42ms elapsed=11.42s tid=0x00007fd7a6896200 nid=0x6603 runnable  [0x000070000dcc5000]
   java.lang.Thread.State: RUNNABLE
at sun.nio.ch.SocketDispatcher.read0(java.base@15.0.1/Native Method)
at sun.nio.ch.SocketDispatcher.read(java.base@15.0.1/SocketDispatcher.java:47)
at sun.nio.ch.NioSocketImpl.tryRead(java.base@15.0.1/NioSocketImpl.java:261)
at sun.nio.ch.NioSocketImpl.implRead(java.base@15.0.1/NioSocketImpl.java:312)
at sun.nio.ch.NioSocketImpl.read(java.base@15.0.1/NioSocketImpl.java:350)
at sun.nio.ch.NioSocketImpl$1.read(java.base@15.0.1/NioSocketImpl.java:803)
at java.net.Socket$SocketInputStream.read(java.base@15.0.1/Socket.java:981)
at sun.nio.cs.StreamDecoder.readBytes(java.base@15.0.1/StreamDecoder.java:297)
at sun.nio.cs.StreamDecoder.implRead(java.base@15.0.1/StreamDecoder.java:339)
at sun.nio.cs.StreamDecoder.read(java.base@15.0.1/StreamDecoder.java:188)
	- locked  (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(java.base@15.0.1/InputStreamReader.java:181)
at java.io.BufferedReader.fill(java.base@15.0.1/BufferedReader.java:161)
at java.io.BufferedReader.readLine(java.base@15.0.1/BufferedReader.java:326)
	- locked  (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(java.base@15.0.1/BufferedReader.java:392)
at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:61)

Locked ownable synchronizers:
	-  (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

I saw this kind of hieroglyph on my console with the code still running… 

(Of course I’m taking this sample from the net but if you ever get your hands dirty with Java you know what I mean)

I always hear the voice of Mr. Steve sayin’ “Get rid of me beginner!” for sure, but as a freelance contractor I’m compelled to code fast and effectively in the language used by my customer or give up and forget the salary – Welcome to the cruel real world. IT is not a white coat environment anymore; now it appears much more like a bazaar with lots of people screaming “Wanna buy?” every step you move along the way (is one of my souvenir of Tunisia – cannot walk along a way without people assaulting me with this “wanna buy”).

So my trip in the programming languages continued with a quick raid to C++ that suffered from lack of standardisation – as I understood – and a very complicated history: After that (finally) the porting of my AnoniCloud backend from php (quick and cool language) to go.

The first time I got my hands dirty with golang I asked myself why another programming language; but the involvement of names like Ken Thompson and Rob Pike convinced me that I had to give it a chance!

Golang is born to make coding funny again; coding must be fun, easy and safe. On the handbook (maybe one of the “in action” series) I read, everything is cool; trainers and writers have this kind of capability to make everything cool; same when I read the Ada handbook: “Ada is powerful and fun”.

What disappointed me about go is the lack of a real object orienting: Objects appeared something like a struct with functions appended where you have to pass them as argument a pointer (again) to the struct (for sake of completeness the syntax is a bit different but this is the essence). So basically it’s a C style approach? Passing a pointer to a data struct to a function that does something with that data? Old approach…

Another feature that disappointed me is that it compels to organise the code into directories that became units; if I’d like in future to organise the code differently the mess is served. This doesn’t happens – for example – in Swift where – beside you have real class with data AND functions inside – you can organise and change the organisation of the sources but the code continue to compile (yes I know that xcode has some automation behind the scene).

The successive exercise with go was to port the client side of AnoniCloud: Modern language, can be compiled cross platform, can be interfaced with major widgets libraries, it has it’s own (fyne) … let’s go.

Maybe was not the right time (working with tight schedule at job), maybe I tried to port 1:1 the Swift code, the porting is stuck since month. Yes every language has it’s own philosophy and is not a good practice to port 1:1; what’s hard for me is to grab the golang philosophy.

Considering that every language can be used to build bad programs I began to study RUST, not for a real application, just for fun, just to know.

As a guide for my trip I chosen “RUST in a month of lunches” by Daye Macleod from Manning. You can buy the book in your favourite local bookstore or from Amazon.

The style of the book is clear and the approach is practical with examples you can run also on the RUST web player.

My first impression about RUST is that is a cool language (so the book reached his first target!), system oriented (people are evaluating to write pieces of linux kernel with) and with the emphasis of underlining errors and critical issues before running the code, this saving the application from horrible crashes while running.

I love the comparison the author made between RUST and wives!

Rust is like a critical spouse

The lenient language spouse sees you going out the door and calls out: “You look great, honey! Hope the interview goes well!” And off you go! You’re feeling good. But maybe you don’t look great and don’t realize it. Maybe you forgot to prepare a number of important things for the interview. If you’re an expert in interviews, you’ll do fine, but if not, you might be in trouble.

The Rust spouse isn’t so lenient and won’t even let you out the door: “You’re going out wearing that? It’s too hot today; you’ll be sweating by the time you get in. Put on that suit with the lighter fabric.” You change your suit.

The Rust spouse looks at you again and says, “The suit you just changed into doesn’t match your socks. You need to change to grey socks.” You grumble and go change your socks.

The Rust spouse still isn’t satisfied: “It’s windy today, and it’s at least a quarter-mile walk from the parking lot to the company. Your hair is going to be messy by the time you get there. Put some gel in.” You go back to the bathroom and put some gel in your hair.

The Rust spouse says, “You still can’t go. The parking lot you’ll be using was built a long time ago and doesn’t take credit cards. You need $2.50 in change for the machine. Find some change.” Sigh. You go and look around for some loose change. Finally, you gather $2.50.

This repeats and repeats another 10 times. You’re starting to get annoyed, but you know your spouse is right. You make yet another change. Is it the last one?

Eventually, your Rust spouse looks you up and down, thinks a bit, and says: “Fine. Off you go.” Yes! Finally! That was a lot of work.

You head out the door, still a bit frustrated by all the changes you had to make. But you walk by a window and see your reflection. You look great! It’s windy today, but your hair isn’t being blown around. You pull into the parking lot and put in the $2.50—just the right amount of change.

You look around and see someone else arriving for the interview in a suit that’s too heavy and is already sweating. His socks don’t match the suit. He only has a credit card and is trying to find a store nearby to get some change. He starts walking to the store, his hair in a mess as the wind blows it every which way. But not you—your spouse did half of the work for you before you even started.

(Excerpts from the cited book)

We’re going to terminate this discussion here at the moment; on my next step of my RUSTy trip we will going to talk about the error when compiling and how I discovered rust handle function’s arguments, very differently from other languages: People call this “ownership”.