I made a simple retro game out of pure passion and released it for free at itch.io, however I see many good games that sell for low prices. There's definitely a niche market. Alternatively users can also donate or become your patrons. From what I see, if the game is decent and the price is lowish, then it sells quite well. Obviously won't pay your bills, but it's something...
I've recently developed a very simple game for the ZX Spectrum in a week and within 2 weeks it was downloaded almost 200 times on itch.io. Despite being an extremely low effort attempt I got some feedback and even a review on Youtube.
Now I can't help but wonder what sort of feedback I'll get if I put in a decent effort. I'm pretty sure it's going to be worth it, since at least for me it was already a very pleasant surprise to have people enjoying my simple game.
The only problem I have found with Pyinstaller is that their "standalone" builds still depends on certain libraries that will change with the version of Python in the host OS, such as the glibc library, or others.
The proposed solution by Pyinstaller is to build your program in the "oldest" version you support, which is silly compared to build systems like Go's, which are true standalone.
Having said that, I'm curious about this solution, since it seems to claim a true standalone build...
The other issue with PyInstaller is that, by default, it includes all dynamic libraries that the Python interpreter has on your machine. It makes sense, it needs an interpreter and collects what is needed for it to run.
Unfortunately this might include libreadline.so, which is licensed under GPL, making your resulting executable unable to be under a proprietary license.
There are ways to solve this issue, but one has to search and read documentation (and code, in my case -- when I was researching it the docs were not clear).
> [PyInstaller] includes all dynamic libraries that the Python interpreter has on your machine.
Yes - and last time I used it, it created either a large folder or a compressed archive containing all of those libraries. Only the latter gives a truly standalone executable - but it's very slow to start up because it has to extract the archive to disk every time it runs.
It sounds like Nuitka has a solution for this problem, at least on Linux: "[the binary] will not even unpack itself, but instead loop back mount its contents as a filesystem".
Indeed it does. The only downside of this is that the resulting binary is (at least in my case) almost tripled in size compared to Pyinstaller (5MB vs 14.6MB). But I can live with that.
Still doesn't statically link C libraries (or at least I didn't find the setting for it), or other libraries for that matter.
Pyinstaller binary build depends only on: libdl.so.2, libz.so.1 and libc.so.6.
Nuitka binary build depends on: libdl.so.2, libz.so.1 and libc.so.6 AND libpthread.so.0 (for the loopback mounts I suppose).
The one that always creates problems is libc.so.6, which usually is not present 4 year old systems...
Go binaries are often not truly standalone. You can certainly make static Go binaries that don't use cgo, but you can't then use standard libraries which rely on it.
I believe that if you use MUSL for libc, you can statically link libc into the binary. That should make the standard library all statically linkable, I'm not aware of any other C dependencies (although I could very well be wrong).
Hmm, with Pyinstaller I generate true standalones which require no libs at all, nor Python to be installed on the host system. Do you use the --onefile option?
As an example, here's a little project which I also release as a single binary file that works everywhere I've tested, with no deps:
I just downloaded it and it works great. Took me a minute to figure out how it wanted me to enter my location (Austin, TX USA is what worked). Would it be hard to add a button to get the location from the OS? I think all the major operating systems have a location service these days.
Python and Go are also the main languages I've been using for the last decade. Noticing all the hype around Rust recently is prompting me to learn a new language. The last time I learnt a language from scratch was Go around 2010.
Go was fascinating to learn, precisely because it looked like C, but it wasn't. Another aspect that makes me love Go is its minimalism and concurrency features.
I also used to enjoy C++ and Java quite a lot for larger projects, so tell me, can I expect Rust to somehow remind me a bit of Go in comparison to C++ and Java? In other words, a simpler, more concise and more enjoyable to use version of C++ for instance?
> can I expect Rust to somehow remind me a bit of Go in comparison to C++ and Java?
Nope. Go and Java are about on the same "complexity plane" (Java is there 20 years later and having made different choices obviously, but the original java was not so different).
Rust is a much more complex language, in large part due to its purpose. It's often compared / conflated with Go because they arose around the same time, because the initial versions of Rust were much closer to applications languages (and Go e.g. runtime, green threads, segmented non-C stacks, …), and because Go's designers misleadingly called Go it a systems language.
Rust is more like taking OCaml, or Haskell, painting it in a C/C++ livery, and making it suitable as an actual replacement for C with all that implies.
I'd certainly agree that the initial learning curve of Rust can be substantial, wrapping your head around things like the borrow checker. It was for me.
But I'd never put it in the same tier as a completely different programming model like functional programming. It's still fundamentally a procedural language. Coming from C, I found Rust simpler than idiomatic modern C++, for instance.
> Nope. Go and Java are about on the same "complexity plane" (Java is there 20 years later and having made different choices obviously, but the original java was not so different).
That's actually a very good point. I think a lot of people forgot about it (I did).
Java started very simple and then it just got enterprisy frameworks and best practices. I'm wondering how Go will look in 20 years.
> Go's designers misleadingly called Go it a systems language.
I think one definition of what a systems language is one that you would use to write operating systems. I'd also call K8ts an distributed operating system and Hashicorp tools as components of one. Doesn't seem a huge stretch to call Go a modern systems language.
As someone who recently learned Go as well as Rust, I would definitely say they are very different (but both great!)
Go is way more minimalist and easy to quickly get some code going.
Rust has a lot more moving parts when writing, so it takes more thought to write, but it’s great for large projects because it’s fast and its features make it scalable (with a lot less worry about bugs).
From personal experience learning the language - despite its syntax, Rust inherits a lot of its concepts from OCaml and Haskell rather than C++ and Java. If you program stuff in Rust the same way that you would program it in C++, you're going to find yourself constantly fighting the borrow checker and having a rough time of it.
I came from Go and found it to be reasonably straightforward to learn Rust. I'm definitely not a Rust expert but I found it to be fairly similar. Structs and no classes, defining methods on structs, lots of the stdlib (like IO) uses reader and writer interfaces, etc.
As an imperative, stateful and even sometimes OOP developer, always finding functional programming very elegant but never really using it for real, Racket was the Lisp dialect that finally hooked me in.
I think the reason was because it came with batteries included and I could create complex applications using only the standard library or very few packages.
I know some Lisp/Scheme, but never really did any projects in it. What did you use to learn Racket (both the language and the ecosystem)? If I had to read a single book/tutorial, what will give me the most bang for my time?
I tried reading the official docs, but while they're great for reference, probably not the best in terms of tutorials/learning.
Complex applications was probably an overstatement but I've created featureful IRC and Discord bots, a database management application and right now I'm creating a graphical browser for the Gemini protocol.
All my other previous attempts at using functional languages, like for instance Haskell, ended up in trivial applications, usually based in numerical analysis.
It's in a very early stage, because I'm porting it from a previous Python code base, so it's not yet available. That said, I'll leave here two links for Racket software that inspire me.
1. Gemini server with tons of features, that I use personally:
My latest project was: Get some emails using IMAP, login to my site, find and scrap some data related to the sender of the email, and send a reply using SMTP. The logic is not very complicated, it uses 4 or 5 of the standard libraries and I avoid writing a hundred emails per day.
Python has described itself as a "batteries included" language for many years -- Python was the language that popularized that term for describing programming languages. So I don't think your personal definition of that term (easy executables) is universal. Everything I can find online indicates that it refers to the wide capabilities of the language's standard library.
I don't think parent's definition of "batteries included" is as narrow as you're suggesting, and I also think yours is too narrow.
It's a claim that the standard language distribution is sufficient to accomplish common goals of new users, without hunting down additional libraries or tools.
As you say, the Python community coined the term, but their notion of its meaning perhaps slants a little too far towards their language distribution's strengths (standard library) and maybe suffers from lacunae towards their language distribution's weaknesses (a clearly-articulated way to create a GUI executable using the standard language distribution).
For one, it has a platform-independent GUI library as part of the standard library, which Python (like most other programming languages) hasn't. That makes it interesting for writing GUI applications or using it for experimental programs which might require )or benefit from) a GUI later.
Racket has also a standardized package management, which is much easier to use than the different Python facilities.
Racket has a much better performance compared to Python and that in turn makes it possible to implement many algorithms directly in Racket which would be a C extension in Python, which makes it more complex to use them.
Another thing is that Racket, as a member of the Lisp family, has also a deep low-level support. For example, it supports multi-threading with both green threads and os-level threads, futures, synchronization, making it possible to write parallel algorithms, which isn't practically possible in standard Python.
> The Python source distribution has long maintained the philosophy of "batteries included" -- having a rich and versatile standard library which is immediately available, without making the user download separate packages. This gives the Python language a head start in many projects.
I scripted in C for the longest time, after thousands of lines it was in muscle memory, and I could reuse boilerplate. I was profoundly embarrassed to then discover Perl; I felt late to the party, like I'd thawed out of a glacier.
Then Python, which stuck. I tried various lisps, Haskell, Ruby, Lua for scripting, and kept returning to Python.
I realized Python was truly boring, and I needed scripting to be fun, to keep my interest up. I relearned Ruby. Ruby is fun.
I had three worksites and I also had a few pet projects that would go on 100 computers. Python failed at every level (So did Haskell). I learned Racket just to improve my programming (It did) I then was like let's see how Racket works and it worked perfectly. I was able to deploy my programs and I never had an issue.
I'm a programmer. I also enjoy occasionally producing electronic music, usually within the trance genre. Nevertheless as a good programmer I'm lazy and that reflects in my music creation. I'm a minimalist, but minimalist trance doesn't sound so good in my opinion. Many layers are often needed, with complex melodies, if you want it to sound professional.
On the other hand, acid techno seems to be minimalist by design, I love it. If I can create it programmatically even better. Mixing automation with some human interaction seems to be the best of both worlds. I'm in love with this and feeling like creating my own acid techno production tool, with a mix of automation and interaction.
I have no idea when or if they'll do another batch, but at the very least a bunch more being in the world should hopefully make them less scarce and expensive on eBay, etc.
I missed both kickstarters, but their "shop" still had both models until early January 2021. I ordered one in October, but won't get it until August. I do enjoy these old retro computers and some games.
I find most of the original games to be unbearable (I didn't play games during that era so there isn't even nostalgia for me), but the new games people are building for the Spectrum and Commodore 64 are fun and a bit more modern in some respects. Ex: I recently bought Attack of the Petscii Robots and the graphics/music/gameplay/manual... everything is great. They're also more amenable to the very limited time I have in adulthood. I doubt I'll play another MMO until I retire.
Nonetheless, the fact that it works in browsers as old as IE6 (haven't tried anything before that) is living proof of the fact that dogmatic "best practices" cargo-culting is, practically speaking, of zero or even negative value.
reply