Flexible array members don’t allocate a dynamic amount of memory on the stack.

Another related nice property that UTF-8 has: substring search reduces to bytestring substring search. I.e. given two Unicode strings in UTF-8 encoding, you can check if one is a substring of the other by just treating them as bytestrings and checking if one bytestring is a substring of the other bytestring. This is a stronger property than self-synchronization: UTF-8 has it, but UTF-8000 doesn’t.

I think a sinking ship is a reasonably good metaphor though. A sunken ship is a horrible, terrible outcome.

In the metaphor, a codebase is sunken when it’s unviable to continue using it. The organization stops working on it and no longer runs it. At this point, the code is completely worthless to the business, like a ship at the bottom of the ocean. True, you could imagine the code getting worse theoretically. But in reality, it will just sit there and rot.[0] The business might attempt a rewrite or just discontinue the product.

It’s possible, but not a given, that a business sinks with one of its codebases. This can happen with a ship too, if a business relies heavily on it.

[0] https://en.wikipedia.org/wiki/Software_rot

Comments URL: https://news.ycombinator.com/item?id=49573279

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49563768

Points: 5

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49438560

Points: 8

# Comments: 4

Comments URL: https://news.ycombinator.com/item?id=49433816

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49358515

Points: 3

# Comments: 0

What I should have said is that in the case of İ/i/I/ı, using str::to_lowercase for string matching wouldn’t be any less correct than using their locale-independent casefold.

The third character in the list, final sigma, is a good example that illustrates why using str::to_lowercase for string matching isn’t good.

> “Suppose […] they type straße and you’ve stored STRASSE. To make these count as matches, you need […]”

Really bad example, because as the article says later on, this casefold crate won’t match those two strings because the ß → ss conversion isn’t done.

> “[str::to_lowercase and case folding] diverge on real characters—ß, İ, final sigma”

The main point is true (case folding is different from lowercasing), but two of the three examples are wrong. The casefold operation that they use maps ß to itself, as does str::to_lowercase. The casefold operation maps İ to U+0069 U+0307 regardless of locale, as does str::to_lowercase.

When I’m reading an article, these kind of mistakes in the introduction make me doubt the accuracy of the whole article. Which is a shame, because again, it’s an interesting write-up. The mistakes also make the article harder to follow, since the examples imply ß is folded to ss.

  Location: Europe (UTC+2)
  Remote: yes
  Willing to relocate: no
  Technologies: Python, SQL, C, Java, Go, PHP, JavaScript, Typescript, Claude Code, Analytics, Git
  LinkedIn: https://linkedin.com/in/lukas-gelbmann
  Email: me@lukasgelbmann.com

You comparing arsonists/pop with firefighter-arsonists/arsonists. That’s the wrong comparison. You should be comparing arsonists/pop with firefighter-arsonists/firefighters. Or firefighters/pop with firefighter-arsonists/arsonists.

(On top of that, mixing numbers from different sources can be problematic. For example, how are repeat convictions treated in the different sources? Who counts as a firefighter?)

Our aim isn’t to try and line up with the calendar that was in use at the time, 2026 years ago.

Instead, the aim (for 28times) is to implement the rules of the proleptic Gregorian calendar[0] correctly. The bug was that those rules weren’t followed for some rare values.

But to address your comment properly, I think I should justify why on Earth someone would want to use the proleptic Gregorian calendar for year 0 and before. In short, because it’s a useful fiction.

The biggest reason is interoperability: a lot of software follows proleptic Gregorian rules, aligning around ISO 8601. Probably a clear majority of date/time software. We want to line up with all that existing software that assigns a specific meaning to a string like "0000-02-01". That’s the first of February in the proleptic Gregorian calendar, even though it was a different date in the ancient Romans’ calendar.

The other reason is to keep it simple: since most people use the Gregorian calendar in present times, it’s simplest (for us as implementors, but also for users) to extend its rules into the distant past and distant future. The alternative for be to have multiple sets of rules, e.g. Julian and Gregorian calendar. (You might say it would be even simpler to just not allow timestamps before 1582. But there are use cases, e.g. in astronomy or history, where people want to work with timestamps before 1582, and even before 1 AD.)

[0] https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar

Comments URL: https://news.ycombinator.com/item?id=48688275

Points: 22

# Comments: 25

https://28times.com

Instead of running `git log -n1` on every file, I think you can walk through the commits backwards, skipping any files that have been seen. Something like this (these two commands could be followed by bttf commands):

  git log --pretty=format:"DATE:%aI" --name-only |
  awk '/^DATE:/ {date=substr($0, 6); next} $0!="" && !seen[$0]++ {print date, $0}'

  git ls-files |
  awk '
    # Read all existing files from git ls-files into an array
    NR==FNR { lsfiles[$0]; next }

    # Process the git log stream
    /^DATE:/ { date=substr($0, 6); next }
    $0!="" && ($0 in lsfiles) && !seen[$0]++ { print date, $0 }
  ' - <(git log --pretty=format:"DATE:%aI" --name-only)

Comments URL: https://news.ycombinator.com/item?id=48310337

Points: 3

# Comments: 0