this post was submitted on 12 Feb 2026
59 points (100.0% liked)

Learn Programming

2087 readers
23 users here now

Posting Etiquette

  1. Ask the main part of your question in the title. This should be concise but informative.

  2. Provide everything up front. Don't make people fish for more details in the comments. Provide background information and examples.

  3. Be present for follow up questions. Don't ask for help and run away. Stick around to answer questions and provide more details.

  4. Ask about the problem you're trying to solve. Don't focus too much on debugging your exact solution, as you may be going down the wrong path. Include as much information as you can about what you ultimately are trying to achieve. See more on this here: https://xyproblem.info/

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 2 years ago
MODERATORS
 

I don't need something practical. I just need something fun to keep me motivated.

you are viewing a single comment's thread
view the rest of the comments
[–] orclev@lemmy.world 8 points 2 days ago (6 children)

So, I can't answer the question of "what's the most fun language to learn" because that's highly subjective and my answer almost certainly wouldn't align with your experience. What I can do though is share my thoughts about different languages I've used over the years (in no particular order).

  • Assembly: the bedrock upon which all other languages are built. If you want to understand how a computer really works, this is a great language to learn, and it's honestly not that hard to learn. Writing something in assembly much more complicated than hello world is incredibly painful because of just how much you need to do and really makes you appreciate how much you get out of the box with other languages, but it's not hard in the "I don't get it" way, so much as "oh god, that's only 1% of what I need to do and it took me an entire day". This is also a great way to develop a deeper understanding of pointers and memory management.
  • C: assembly on steroids. Not quite as painful as assembly because you get a lot of libraries that take care of things for you, but still quite tedious compared to most other languages. The type system such as it is is practically nonexistent so your ability to design APIs is highly limited, and it's incredibly easy to introduce subtle and hard to find bugs. Relatively easy to learn, hard to master, and an act of masochism to use for large projects. At a minimum probably worth learning because C is the de facto interop language any time you want to interface two different languages together.
  • C++: C with the entire kitchen sink of comp. sci bolted on top of it. There's a good language in there somewhere, it's just buried under decades of terrible ideas and half baked experiments. If you know which are the "good parts" and which are the parts to ignore it's not bad, but figuring that out is far from a trivial task and everyone you ask is going to have a slightly different answer. I'd honestly say avoid this one unless you want to spend a couple years exploring all its dark corners and forgotten nooks.
  • LISP (and derivatives like Scheme): ye old functional language. This is basically the assembly of functional programming. It's "simple" to learn, but the lack of features is going to start to grate on you after a while, and the syntax is just horrible. Absolutely worth learning to learn to think functionally, but once you do I'd move to a better language.
  • Haskell: Like LISP but with a masters degree in set theory, a MUCH better syntax, and one of the absolute best type systems ever created. Amazing language that will expand your mind just from learning it but might kill you from a brain aneurysm in the process. To abuse a meme, this is the dark souls of functional programming.
  • JavaScript: A badly designed scripting language that was thrown together from a box of scraps in a cave, but rather than making it better over the years everyone just said "eh, good enough". Its original sin was that in an attempt to make it "beginner friendly" they made the syntax incredibly sloppy which means it's very easy to introduce bugs on accident and then very hard to actually find them because they don't error, they just silently do the wrong thing.
  • Typescript: A better JavaScript in every metric. At the end of the day under the hood it's still JavaScript at runtime so it can only do so much, but the addition of a real type system goes a LONG way towards making JavaScript more bearable to work in and helps eliminate a ton of bugs.
  • Perl: What LISP is to functional programming, Perl is to basic collection types. Scalars (single values), Lists, and Maps are your building blocks in Perl. It's not a bad language exactly, but these days other languages do almost everything it does but better. If there's one significant criticism you could level on Perl it's that the syntax is really easy to abuse to write some truly obtuse code. This is effectively a dead language these days, but it does live on a little bit by being the gold standard in regular expression design that everyone else just copied.
  • Lua: One of if not the best scripting languages currently out there. It's very similar to Perl except it went all in on Maps. It's simple to learn, and simple to master, although that comes with the downside that it's nowhere near as powerful as other languages. Out of the box you don't really get much with it, but since it's designed to be embedded it's really easy to extend and there are versions of it that come with all the bells an whistles you need to use it directly for writing apps. I'm not sure I'd recommend it over another language in general, but if you're looking for a scripting language to embed in something else it's my top pick. The web ecosystem would be a lot less of a mess if Lua had been the language picked at the dawn of the internet instead of JavaScript (to be fair I'm like 99.9% sure Lua didn't exist back then but I'm too lazy to verify that).
  • Python: A competent language. It's not a particularly great language and definitely has some warts, but there's not really anything in the language that makes me go "ewwww" except maybe the significant whitespace, although Haskell does the same thing so it would be hypocritical of me to ding Python for that. It's a solid middle of the road language, nothing really amazing about it, but nothing really bad either. It's biggest flaw is its duck typing system which really limits your ability to write APIs in it. If you want to crunch some numbers it has some really great data analysis libraries and frameworks, although performance isn't anything to write home about either.
  • Ruby: The train wreck that happens when Perl crashes into Python and the mangled remains crawl from the wreckage. It's the terrible syntax of Perl crossed with the middling type system of Python with a sprinkling of bad choices all its own. Performance is horrible and the language has a lot of features that make it easy to write obtuse code. Like Perl this is an effectively dead language. Just use Python or something better.
  • Go: Created in part by one of the guys involved in the creation of C and set out to be a "simple" language that anyone could learn. It does succeed in being simple, but the tradeoff is that it pushes all the complexity that most other languages handle for you onto the programmer to handle. Go programs are going to end up being a lot more verbose and filled with boilerplate than they would be in another language. It also still suffers from an early decision related to its generics system that leads to them being largely useless. Not unsurprisingly working in Go feels a lot like working in C, you often find yourself wishing the language handled a bunch of things for you or at least gave you some syntactic sugar to handle them more concisely yourself.
  • Java: Has a reputation for being verbose but that's more to do with the community than the language itself. Also has a reputation for being slow, and while startup times are certainly a problem at runtime it's surprisingly fast these days. Not a great language, but nowhere near as terrible as its reputation would make you think.
  • Kotlin: Java alternative. Solves some of Javas problems, introduces some of its own. At one point it was the clearly superior choice compared to Java, but since then Java has closed the distance and honestly it's a coin flip as to which is the better language between the two.
  • C#: Microsoft Java. Seriously, everything you can say about Java applies equally to C# and vice versa. It's not a better or worse language, it's just different. Criticisms of C# are less about the language and more about the company behind it.
  • Rust: A type system nearly as powerful as Haskell's, low level primitives that let you write bare metal code, but advanced abstractions that let you write high level code as well, and a truly unique approach to addressing concurrency and memory safety by way of the ownership system. One of the more interesting languages out there and my personal pick for "best" language because it gives you tools to solve some of the hardest problems to deal with in programming.
  • Zig: A better C. Has a somewhat powerful type system a bit like Rust or Haskell as well as a pretty unique and interesting macro system, but ultimately lacks some of the higher level features that something like Rust would give you. It's similar to C in that it it can be somewhat tedious to work with but on the whole not a bad language.
[–] ulterno@programming.dev 4 points 2 days ago* (last edited 2 days ago) (4 children)

Assembly: ... but it’s not hard in the “I don’t get it” way, so much as “oh god, that’s only 1% of what I need to do and it took me an entire day”. This is also a great way to develop a deeper understanding of pointers and memory management.

Well explained.
Although I understood memory beforehand, I found the little bit of Assembly I did pretty useful in getting a better understanding. This also ended up opening me to think of how multithreading worked underneath.


I found C pretty fun, but that might be my bias.
It was fun because it felt pretty close to hardware and let me understand how stuff can go wrong, without tripping me into it (the last part is subjective. I suppose most people would feel having been tripped, when using C).

C++ was fun and useful as long as I thought of it like C. Once I went into software development and had to make sure stuff worked out well on top of mistakes that might come out of collaboration, I had to start considering things like smart pointers almost all the time and it was no longer as much fun.

Rust is definitely not going to give the fun of C. Although it is more desirable for Software Development, when you start learning it, you will find quite a few blockers, that you might feel unreasonable. Me, even after having used C and C++ and realising the problems faced when making software and then having seen proper explanations of the features of Rust, still have a problem with the feeling of it.

Python: if you just want to do some mathematics on computers, this will be more desirable. The "fun" for this one is that you don't need to worry as much when doing some scratchpad stuff. Start going big though and it stops getting any fun, pretty fast.

[–] ageedizzle@piefed.ca 1 points 1 day ago (2 children)

Whats a good way to start learning assembly?

[–] orclev@lemmy.world 2 points 1 day ago (1 children)

So, there's not a great answer to that. The big problem is that x86 assembly is painful because the x86 instruction set is a weedy overgrown mess due to being built on top of literal decades of cruft. Even a CPU made today starts off by booting up pretending to be an 8086 processor, a 16 bit CPU from 1978. To get to a "modern" operating mode you need to walk through a series of configuration steps to get the CPU into the correct mode, but all those modes and configs add a lot of noise when trying to understand x86 assembly. For that reason it's probably a good idea to start by not learning x86, but instead the far more minimal and sane ARM assembly.

The problem of course is that there's like a 99% chance that the system you're going to be working on when learning assembly is an x86 system not an ARM one. So now you need two more things, you need an assembly cross-compiler to use your x86 system to build an ARM executable, and you need an ARM emulator to run it. Personally I'd install LLVM (specifically clang) and start by writing a small C wrapper with some inline assembly in it. For running it I'd use QEMU and a Linux ARM image (maybe one of the raspberry pi distros).

Finally allow me to introduce you to one of the absolute coolest tools out there godbolt compiler explorer. Godbolt allows you to take a snippet of code written in one of dozens of supported languages and see the assembly instructions that various compilers would produce from that code. This is a great way to learn more about not just assembly, but any of the supported languages and is also an invaluable tool for doing fine grained optimizations.

[–] ageedizzle@piefed.ca 1 points 19 hours ago

Even a CPU made today starts off by booting up pretending to be an 8086 processor, a 16 bit CPU from 1978.

That's fascinating.

The godbolt compiler looks like it would be very useful for learning programming. Reminds me of this website even though it's not quite the same because it's a game.

Thanks!

[–] ulterno@programming.dev 3 points 1 day ago* (last edited 1 day ago)

IDK really, perhaps you can use a book.
I mainly did it in the 8085 practicals during B.Tech and they had a handy learning kit with a HEX keyboard so we could Assemble it manually on paper, write the program directly to a given RAM address and then run it from there. For ARM, we just used Keil µVision.
Now I just download an x64 instruction manual or just look up the instructions on the web, on the occasional requirement of reading disassembly.

I don't recommend starting with x86_64 reference. While it can be used just fine, it has lots of instructions and and you instead want a very small subset of them.


Also, there will be a great difference between using an OS and not doing so, as going with one, then includes a lot of potential boilerplate.

load more comments (1 replies)
load more comments (2 replies)