Category Programming
My First Deno Experiment
This is another not-requested opinion on Deno! But what can I do? When I read “node replacement,” “TypeScript,” and “Rust,” I lose any inhibition. Therefore, I ported to Deno an old npm package and wrote a brief report on my experience. What I liked? What I disliked? Will Deno be succesful in the overcrowded world of programming platforms? These are my answers.
Happy 5-Years Birthday Rust!
Today has been five years since Rust 1.0 release. I really want to wish happy birthday to this awesome language! I could write an article on it or I can link you to this wonderful post in the official Rust’s blog. Enjoy!
Swift announces official Windows support — maybe too late
Swift is a pretty language that hits a sweet, sweet spot: it is a compiled language built around LLV, it is modern, it took advantage of decades of programming language design efforts, and it is esthetically pleasing. It is the kind of language that could have taken a lot of market shares. Unfortunately, official Windows support will come only with version 5.3. It may be already too late to wash away the “iOS Language” stigma.
My favorite Visual Studio Code extensions
Visual Studio Code is my editor of choice. I started with it because of the top-notch TypeScript integration, and then I stuck with it for all the rest (all but for big projects in languages with outstanding IDE support, such as Kotlin). During the years, my extension page grew bigger and bigger; new extensions get installed, old extensions get removed. You know, the usual stuff. But during all these years, a bunch of extensions has always remained the same.
Go is still fighting over generics. In 2019.
I dislike Go. I dislike it a lot. Nevertheless, I usually do not bash on it because I am deeply convinced that people should use whatever they want and they like. Many people I respect use Go. I mean, this blog run on Hugo, that is written in Go! How could I be one of “those guys” who always bitch about what other people enjoy? However, sometimes, I fall into watching discussions in the go community, and they are so absurd I cannot shut up.
On Rogozhin's Universal Turing Machines
Every now and then, we see some headline about Turing Completeness of something. For example, Minecraft or Dwarf Fortress, or even Minesweeper are famous examples of accidentally Turing complete systems.
If you know what a Turing machine is (and you should) you will have an intuitive idea of the claim: you know that X can compute any computable function. Sure; but if you stop thinking about that for a bit, it is not so intuitive how we can prove that. If we think long enough, we can start understanding how X can simulate a Turing machine, but how can we be sure that we can encode a Universal Turing Machine and what is the program of a UTM and how we can prove that it is, in fact, universal?
Kotlin Development in VS Code
Kotlin is a really sweet language. It is the perfect thing in between a “super-powerful and but difficult language” like Rust or Modern C++, and a “super-easy but that seems to be designed in the 80s” like Go. With the upcoming release on Kotlin Native, then, you can even ditch the JVM!
However, while IntelliJ is a great IDE, often I do not like to rely on big IDEs — especially when VSCode works perfectly well for 90% of my use cases. Therefore, it is time to see if and how I can use Kotlin in VS Code (and see what is missing).
Quick Look at F# in Unity
I am a functional-oriented developer. I have a bit of expertise in game development, especially in Unity 3D. It comes naturally that I am interested in the obvious link between the two: F#.
F# is a functional language of the ML family born in the Microsoft Research and now developed by the F# Software Foundation. Of course, F# run on the .NET framework, the same as C#, the language used by Unity3D. It is clear, then, that we could use F# in Unity. And, in fact, we can with moderate easiness.
Should we? How easy is that? answering these questions is the goal of this article.
[Link] Go: the Good, the Bad and the Ugly
My opinion is that talking about languages is usually a very unproductive use of time. If these discussions are just cat fights, then it is even worse. Unless you are a language designer, you are writing a language or study a language, you should just use a language and nobody should care. But good articles on language pro and cons are always nice. They may be helpful to choose the right tool for the problem.
The State of Game Development in Rust
Game Development is one of the fields in which Rust can gain a lot of traction. As a modern compiled language with performances comparable to C++, Rust can finally free us from the tyranny of C++ bloated feature set, hard-to-link dependencies, and header/implementation file double-madness (I am obviously exaggerating, btw).
However, if this freedom arrive, it will be a very slow process. To make it slower, the feature of memory safety in videogames is not a huge priority compared to the ability to quickly prototype. The borrow-checker and the strict compiler are an obstacle in this regard. On the other hand, memory safety also means easier multi-threading. And this is sweet!
Fortunately, the annoyances of borrow-checker will get less in the way while people becomes more confident with the language, and while tooling gets better and better. I am confident we may see Rust carve out its space in this domain.
But this is the future. What about now?