Learn Icon

Learn

Learning to code, leveling up, building your skills. Expand your résumé and pursue a fulfilling developer career.
328 Stories
All Topics

Rust simonwillison.net

Learning Rust with ChatGPT, Copilot and Advent of Code

Simon Willison is using this year’s Advent of Code as an opportunity to learn Rust.

He’s using Copilot to help him with syntax/snippets via comment-driven prompting. He’s using ChatGPT as a study partner by asking it questions about how to do things in Rust. Is it working?

So far I think this is working really well.

I feel like I’m beginning to get a good mental model of how Rust works, and a lot of the basic syntax is beginning to embed itself into my muscle memory.

The real test is going to be if I can first make it to day 25 (with no prior Advent of Code experience I don’t know how much the increasing difficulty level will interfere with my learning) and then if I can actually write a useful Rust program after that without any assistance from these AI models.

And honestly, the other big benefit here is that this is simply a lot of fun. I’m finding interacting with AIs in this way—as an actual exercise, not just to try them out—is deeply satisfying and intellectually stimulating.

This might be an early glimpse into the future of AI-assisted learning…

Adam Gordon Bell earthly.dev

Containers are chroot with a marketing budget

Adam Gordon Bell:

There are many ways to understand how containers work, but most useful explanations are actually simplifications….

But for me, containers are just chrooted processes. Sure, they are more than that: Containers have a nice developer experience, an open-source foundation, and a whole ecosystem of cloud-native companies pushing them forward. But, let me show you why I think chroot is the key.

I like this framing. It makes a lot of sense to me. More than ‘lightweight VM’, which is how I’ve thought about them previously. The rest of this article is Adam stepping through the process of building a container runtime using only the chroot system call.

Lars Wikman underjord.io

Complex systems all the way down

Lars Wikman on what it takes to learn software development and how he responds when people ask him how they should go about it:

At the time I was learning, I didn’t have access to any kind of bigger picture. I had limited resources. Limited documentation. I had so many limitations. I ran into them constantly and eventually found the next thing I could use to do cool stuff. If you try to teach someone to use an HTML form today, you will need to decide if you are talking about the basic idea or reality. Do we need to cover CSRF, captchas and how to do it in React? How about the backend? Starting out, I didn’t hear about half of the things I didn’t know; I think that made things easier.

When it comes to the software industry, this is the best of times. There are amazing learning resources available, a vast repository of free code that you don’t have to write, and lucrative job offers on the other end of the chasm.

When it comes to the software industry, this is the worst of times. There are too many learning resources to choose from, a crippling repository of free code that might stumble you, and overwhelming imposter syndrome on the other end of the chasm.

Lars sums it up nicely:

Hand someone a fish and they’ll never know that the ocean is vast. Teach them how to fish and they’ll be forever lost at sea.

Tomasz Cichociński cichocinski.dev

How trying new programming languages helped me grow as a software engineer

Tomasz Cichociński:

It’s completely fine to deepen one technology or one programming language knowledge. It’s totally fine to just have a 9-5 job that pays the bills. But if you aim to level up, I’m highly recommending trying something new to broaden your perspective.

If you’re writing JavaScript, try some functional language like Elixir or ReScript. If you’re already familiar with high level, garbage collected languages, try something low level like Rust or even C/C++. Play with different concurrency model like coroutines or actor model.

You don’t need to change your job, you don’t need to ship products with it. Try to create something fun. You’ll thank yourself later.

Brandon Willett willett.io

How to build software like an SRE

This is awesome — Brandon, please write down more lessons learned, even if they’re just something for you to reference later on.

I’ve been doing this “reliability” stuff for a little while now (~5 years), at companies ranging from about 20 developers to over 2,000. I’ve always cared primarily about the software elements I describe as living “outside” the application – like, how does it get its configuration? What kinds of instances does it run on, and are those the best kinds to use? What steps does it take on its path from “code in a repository” to “running in production”? And I’ve always kept track of what I liked – which mechanisms allowed fast iteration and which caused frustration, which led to outages and which prevented them.

… So! With that out of the way – this is how I’d rebuild it all from scratch if I could.

Unix punkx.org

The UNIX Pipe Card Game

An actual card game to teach actual kids how to actually combine unix commands with pipes.

task: print the most common line from a file, we need to first cat the file (in our case the file is card 03.txt), then sort it, uniq count it, then do numeric sort, then tail -1:

answer: cat 03.txt | sort | uniq -c | sort -n | tail -1

Print it yourself or… actually it’s sold out for now so you’ll have to print it yourself.

The UNIX Pipe Card Game

Learn github.com

Facts about state machines

Johannes Schuck holds the opinion that state machines are underrated. So he wrote this:

The goal of this list of facts is not to teach you what state machines are or how to use them; there are plenty of other resources for that. Rather, the goal here is to motivate their usage and to highlight things about them that are frequently overlooked, but nonetheless relevant.

Learn the-algorithms.com

Algorithms & data structures implemented in many programming languages

This looks awesome:

We are a group of programmers helping each other build new things, whether it be writing complex encryption programs, or simple ciphers. Our goal is to work together to document and model beautiful, helpful and interesting algorithms using code.

We are an open-source community - anyone can contribute. We check each other’s work, communicate and collaborate to solve problems. We strive to be welcoming, respectful, yet make sure that our code follows the latest programming guidelines.

Paul Graham paulgraham.com

What I've learned from users

Here’s Paul Graham with some wise advice he’s learned from YC’s users — this also tees up a large conversation on this Friday’s episode of The Changelog (talk to your users).

I recently told applicants to Y Combinator that the best advice I could give for getting in, per word, was. Explain what you’ve learned from users.

Here’s why that makes sense.

That tests a lot of things: whether you’re paying attention to users, how well you understand them, and even how much they need what you’re making.

But giving this advice made Paul consider what he has learned from YC’s users (the startups they’ve funded). This one is almost cliché at this point, but still quite true.

Focus is doubly important for early stage startups, because not only do they have a hundred different problems, they don’t have anyone to work on them except the founders. If the founders focus on things that don’t matter, there’s no one focusing on the things that do.

Learn beesbuzz.biz

Falsehoods programmers believe about email

It’s easy to fool ourselves into believing the world is normal, sensible, and without rare-but-undeniably-valid edge and corner cases. Maybe you’ve done this to yourself with email. I’m guilty.

One example, we do email-based authentication (no passwords!) because I believe(d) this particular falsehood:

Emails will be received soon after they’re sent

I wish it were always true! Thankfully, there’s a lot of things on the linked list that I don’t believe. Do you?

Jamie Tanna jvt.me

Learning a new language, or how I gained familiarity with Go

Every so often, engineers need to pick up a new language. After ~6 years of professional development using Java, with a bit of Ruby sprinkled in, coming to Deliveroo meant that I’d be starting to work on some Go codebases.

So when it came to accepting the offer, I ended up thinking about getting started with learning Go, so I could hit the ground running. In this post I share different ways to get practical experience of the language, as well as thoughts on what Go is like to a newbie

Microsoft News Icon Microsoft News

Microsoft's new AI for Beginners course

A 12-week, 24-course curriculum covering:

  • Different approaches to Artificial Intelligence, including the “good old” symbolic approach with Knowledge Representation and reasoning (GOFAI).
  • Neural Networks and Deep Learning, which are at the core of modern AI. We will illustrate the concepts behind these important topics using code in two of the most popular frameworks - TensorFlow and PyTorch.
  • Neural Architectures for working with images and text. We will cover recent models but may lack a little bit on the state-of-the-art.
  • Less popular AI approaches, such as Genetic Algorithms and Multi-Agent Systems.
Microsoft's new AI for Beginners course

Learn notes.volution.ro

The many flavors of hashing

Not every hash algorithm is appropriate in all scenarios, and in fact, very few algorithms are usable in more than a couple of situations. Even worse, using the wrong algorithm will lead in the best case scenario to performance problems, but in the worst case scenario to security issues and even financial loss. Thus, knowing which algorithm to pick for which application is crucial.

Therefore I’ll try to summarize how I approach the topic of hashing, including use-cases, recommended algorithms, and links to other articles.

Chip Huyen huyenchip.com

Introduction to streaming for data scientists

Chip Huyen:

As machine learning moves towards real-time, streaming technology is becoming increasingly important for data scientists. Like many people coming from a machine learning background, I used to dread streaming. In our recent survey, almost half of the data scientists we asked said they would like to move from batch prediction to online prediction but can’t because streaming is hard, both technically and operationally…

Over the last year, working with a co-founder who’s super deep into streaming, I’ve learned that streaming can be quite intuitive. This post is an attempt to rephrase what I’ve learned.

Mahdi Yusuf architecturenotes.co

A deep technical dive into all things Redis

Mahdi Yusuf is back with another set of Architecture Notes, this time covering everyone’s favorite “data structure server”, Redis:

Rather than iterating over, sorting, and ordering rows, what if the data was in data structures you wanted from the ground up? Early on, it was used much like Memcached, but as Redis improved, it became viable for many other use cases, including publish-subscribe mechanisms, streaming, and queues.

A deep technical dive into all things Redis

Hacker News Icon Hacker News

A thread of cool but obscure data structures

User Uptrenda asked HN about their favorite data structures, sharing their own to get it started:

I’ll start: bloom filters. Lets you test if a value is definitely NOT in a list of pre-stored values (or POSSIBLY in a list - with adjustable probability that influences storage of the values.)

Good use-case: routing. Say you have a list of 1 million IPs that are black listed. A trivial algorithm would be to compare every element of the set with a given IP. The time complexity grows with the number of elements. Not so with a bloom filter! A bloom filter is one of the few data structures whose time complexity does not grow with the number of elements due to the ‘keys’ not needing to be stored (‘search’ and ‘insert’ is based on the number of hash functions.)

The responses are numerous with a lot of signal, which is increasingly rare on the orange website these days. Worth a read!

Matt Holt sourcegraph.com

How Caddy 2 works, a deep dive into the source

Matt Holt (creator of Caddy) gives a deep dive into how the web server works and some of the design decisions and patterns that make it reliable, extensible, and delightful.

One of the interesting things about the design of Caddy is that its core is just configuration management. It pushes out all other functionality into modules so that basically the only thing left in core is accepting and reacting to configuration changes.

Data visualization blog.regehr.org

Explaining code using ASCII art

A collection of ASCII data structures, state machines, logical structures, and more.

People tend to be visual: we use pictures to understand problems. Mainstream programming languages, on the other hand, operate in an almost completely different kind of abstract space, leaving a big gap between programs and pictures. This piece is about pictures drawn using a text character set and then embedded in source code.

  0:00 / 0:00