Recent submissions

Comment · 2 years ago
Keep in mind that "one zone" has durability implications:

> In the unlikely case of the loss or damage to all or part of an AWS Availability Zone, data in a One Zone storage class may be lost. For example, events like fire and water damage could result in data loss.

Comment · 4 years ago
Not to mention large parts of the community using a pointfree, single character variable naming style that's hard to read. If Haskell could consistently be written in a more predictable style, that would be much more suited to collaboration IMO.
Comment · 4 years ago
This idea of missing something simple really speaks to me.

I remember “factorization” not clicking for me for the longest time in public school. My grades slowly got worse, until the right teacher came along and explained it in a way that clicked. I proceeded to have a successful math focused education in high school and university.

I wonder if part of it is that kids are at the mercy of what their teachers want to teach / the curriculum. I think kids often know which things they struggle with… they need help articulating it, and then someone to work with them through it.

Comment · 5 years ago
Quality isn't only sacrificed due to mismanaged loss in the pipeline. It's also at odds with delivery speed, feature breadth, cost, and itself. Quality is at odds with quality, because quality is not single dimensional!
Comment · 5 years ago
I once plugged my Linux thinkpad into a projector via HDMI during a programming interview, and my laptop started smelling like it was burning. Never again!
Comment · 6 years ago
Is Elixir really the general purpose productivity tool that comments here (and on other HN posts) make it out to be?

I've loved playing with Erlang and Elixir. The concurrency model and approach to failure are fascinating and clearly powerful for certain problems. Elixir's Pheonix feels as productive as Rails. I've read most of Joe Armstrong's books and watched most of his talks.

However, I feel like I can throw my daily driver programming languages including Go, Ruby, Rust... even Haskell at any problem and give or take performance, come out the other end with high quality software at scale.

When I last wrote Elixir, it felt great when I was doing basic Rails shaped work or lower level concurrency heavy networking (I was playing with TUN/TAP interfaces), but I really can't imagine it as a general purpose programming language.

For example I can't imagine scripting in Elixir, but I can and do in the other languages mentioned above. Also I remember trying to write a parser library and it felt way more verbose and unmaintainable than the equivalent Haskell or Rust.

This is hand wavy, but does anyone feel what I'm getting at? Any thoughts?

Comment · 6 years ago
Hey antirez,

Your work that’s had the most impact on me isn’t Redis but kilo! It taught me how to have fun hacking on C back in university. Me and a couple friends cloned the repo and started adding fun features.

Here’s to more 1000 line whatevers! <3

Comment · 7 years ago
Which means “bag” in French
Comment · 7 years ago
I interpreted it more as a story about aging. I guess both!
Comment · 7 years ago
Comment · 7 years ago
To add to this, editor commands to quickly switch to your test file, auto generate test boilerplate and run the currently highlighted test are super helpful to speed up this loop.
Comment · 7 years ago
I’ve often had similar feelings to you.

Something that blew my mind recently was using a Lisp repl which was integrated with my text editor.

I just wrote out the code I wanted to toy with in my text editor buffer, and then highlighted it and hit a key command to evaluate it at the repl without even needing to switch over to the repl window.

It would be so cool if we had great support for something similar in non Lisp languages.

Comment · 7 years ago
Yup. I misspoke. We’re both right.
Comment · 7 years ago
Having unwrap() in your Rust code is like littering your code base with panic(). It’s not appropriate to use in most production code, but is convenient in prototypes, examples and tests.

Your example re Go errors is incorrect. The go compiler allows you to ignore errors in returns without any compiler error.

For example

err := doThingThatErrs()

and

doThingThatErrs()

are both valid Go code.

Comment · 7 years ago
> I typically find it very difficult to understand complex functions

It seems to me like "complex" and "ability to understand" mean the same thing, so this phrase doesn't have much meaning.

It's difficult to define "ability to understand" / "complex" without using either of those words in the definition. For example, you mention lines of code, nesting and multiple concepts.

I tend to agree with your examples, however not necessarily the lines of code. I've seen single large functions that represent an algorithm in a way that's easier to understand than the implementation that breaks it up into tens of little functions. It made liberal use of comments to explain each section of code in the function. I believe its advantage was that when reading, you could simply scroll down the function line by line rather than having to jump all over the file.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton