This is being too generous to Swift's poorly designed String API. The author gets into it immediately after the quote with an Array<Character> workaround, regex issues, and later Substring pain. It's not a fatal flaw, a language backed by one of the richest companies in the world can have few fatal flaws, but AoC in particular shines a light on it.

I really like Swift as an application/games language but I think it unlikely it can ever escape that domain.

I wholeheartedly disagree and counterpoint that all other String APIs are wrong (bold statement, I know). Accessing a random index of a String is a complex (slow) operation, and as such, should be reflected as complex in the code, especially since people usually think it is not complex.

If you want an array of UInt8, just use that.

The part about the regex I agree with. They are slow and that’s a shame. I do not personally use regex much though, and don’t think it should be done much in prod either, unless there are no other options, but that does not excuse a poor implementation.

Regarding the domain, I recognize it seems to have difficulties escaping the “native iOS/macOS apps,” but IMHO it should not. It is a language that is simple to use, with a reasonable memory handling default (ARC), though it can also use the memory ownership model of rust. Generally speaking using Swift is possible everywhere. I use it personally for an app (native and web front, and back), and it is extremely cool.

Its ecosystem is also becoming quite interesting. Most of the libs are from Apple, yes, but they are also very qualitative.

All in all I think it’s shame Swift is not more used overall in the industry.

The AoC format goes out of its way to express all problem inputs and outputs in simple strings with only basic ASCII text, just for compatibility with the most programming environments. This is very different from almost all real-world problem, where the complexities of human language are huge.

Nope nope nope.

I have to agree strongly with my sibling commenter. Every other language gets it horribly wrong.

In app dev (Swift's primary use case), strings are most often semantically sequences of graphemes. And, if you at all care about computer science, array subscripting must be O(1).

Swift does the right thing for both requirements. Beautiful.

OK, yes, maybe they should add a native `nthCharacter(n:)`, but that's nitpicking. It's a one-liner to add yourself.

In Rust "AbcdeF"[1] isn't a thing, it won't compile, but "AbcdeF"[1..=1] says we want the UTF-8 substring starting from byte 1 through to byte 1 and that compiles, and it'll work because that string does have a valid UTF-8 substring there, it's "b" -- However it'll panic if we try to "€300"[1..=1] because that's no longer a valid UTF-8 substring, that's nonsense.

For app dev this is too low level, but it's nice to have a string abstraction that's at home on a small embedded device where it doesn't matter that I can interpret flags, or an emoji with appropriate skin tones, or whatever else as a distinct single grapheme in Unicode, but we would like to do a bit better than "Only ASCII works in this device" in 2025.

> In Rust "AbcdeF"[1] isn't a thing, it won't compile, but "AbcdeF"[1..=1] says we want the UTF-8 substring starting from byte 1 through to byte 1 and that compiles, and it'll work because that string does have a valid UTF-8 substring there, it's "b" -- However it'll panic if we try to "€300"[1..=1]

I disagree. IMO, an API that uses byte offsets to substring on Unicode code points (or even larger units?) already is a bad idea, but then, having it panic when the byte offsets do not happen to be code point/(extended) grapheme cluster boundaries?

How are you supposed to use that when, as you say ”we would like to do a bit better than "Only ASCII works in this device" in 2025”?

I see there’s a better API that doesn’t throw (https://doc.rust-lang.org/std/primitive.str.html#method.get), but that IMO, still isn’t as nice as Swift’s choice because it still uses byte offsets

It's often the case that we know where a substring we want starts and ends, so this operation makes sense - because we know there's a valid substring this won't panic. For example if we know there's a literal colon at bytes 17 and 39 in our string foo, foo[18..39] is the UTF-8 text from bytes 18 to 38 inclusive, representing the string between those colons.

One source of confusion here, is not realising that UTF-8 is a self-synchronising encoding. There are a lot of tricks that are correct and fast with UTF-8 but would be a disaster in the other multi-byte encodings or if (which is never the case in Rust) this isn't actually a UTF-8 string.

In 2005 it's rather old-fashioned. There's lots of 8859-1 and cp1252 out there but people aren't making so much of it, and Unicode aka 10646 is clearly the future.

In 2015 it's a done deal.

Here we are in 2025. Stop treating non-Unicode text as anything other than an aberration.

You don't need checks "for every string operation". You need a properly designed string type.

Like I said, you can easily extend String to look up graphemes by integer index, but you should define it as a function, not a subscript, to honor the convention of using subscripts only for constant-time access.

It's also just not a normal use case. In ten years of exclusive Swift usage, I've never had to get a string's nth grapheme, except for toy problems like Advent of Code.

If you know it's safe to do you can get a representation as a list of UInt8 and then index into that.

We don't care that it takes longer, we all know that, we still need to do a bunch of string operations anyway, and it's way worse with swift than to do an equivalent thing than it is than pretty much any other language.

The likelihood is low that Jon has spoken to any meaningful number of civil engineers in making his comparison to the software engineering field. Rather, he reasons from some idealized version of what he believes civil engineering to be.

Beyond that, I think the survey would need to expand the pool to a representative group working in software. Possibly those who studied CS, those who studied other fields, self-taught without formal higher education, and include people who studied (and possibly are licensed) software engineering, to provide a control group.

Even within the engineering field, not everyone is an engineer or practicing engineering. There are different levels of education and credentialing and those people fill useful positions. For some reason everyone in software insists that they are doing engineering and are an engineer without having studied any engineering topics. (I’m not talking about having to cover the chemistry, physics, differential equations and other topics that aren’t core to software.)

1. The study is comparative in that it answers the question do engineers from other fields consider software engineering “real”. The interviewees answer more than whether they apply their an engineering design process, they comment on what they see in the industry from others, and resoundingly agree that software engineers are abundant and no different than “real” engineers.

2. We agree, aspects of the study could be improved. Nonetheless, I think Hillel’s analysis serves its purpose in leading the discussion forward on whether software engineering is “real” in a more productive direction than Jon Blow’s comments do, necessarily, as the topic of this HN thread.

3. Part 1 of Hillel’s article, linked above, addresses and agrees with your point directly. Suggesting that we don’t have a vocabulary vibrant enough to describe all aspects of the work people do with and on software yet.

I think the video opens up more interesting lines of discussion. There are two points I think the video has that are relevant. One is the discussion on deep knowledge (there is a body of knowledge to learn about software engineering including fundamentals of the discipline). The other is really about the engineering design process (there are domain specific techniques for software that can be used, but it's common to all engineering disciplines).

As other commenters mentioned, the fundamentals are probably more accessible and more known now than at any other time. The minimum bar to enter the field has probably gone down substantially because of all of the abstraction and tooling that exists, and because there is no standards to what job titles are, everyone wants to be called an engineer.

The software PE was removed in the US, but the fundamentals are probably pretty similar in Canada. https://www.egbc.ca/registration/individual-registrants/how-...

Sure, this is probably a little much and there are plenty of people working in the field that don't need to know much of it. That brings us to the vocabulary, which is already in place! Engineer, technologist, technician, skilled trades, and unskilled labor are different categories of jobs within the existing fields of engineering. These range from requiring no formal education to requiring years of formal education. Again, everyone wants to be an engineer and there is nothing in America stopping them from calling themselves one.

TFA is about non urgent important tasks that you want to show incremental progress on. If there are multiple of those then those short bursts of works actual work can be eaten up by context switching, reprioritization, scheduling, etc.

you can basically count on one hand how many anime style or Japanese gaming properties don't go off the rails and finish the initial story.

Final Fantasy VII is a prime example, the world building at the beginning of the first game in the “VII” franchise is fantastic. In such an arduous funnel, most people see that. But then there’s vampires, dueling identities, ridiculous backstories that cause continuity issues and separate subsequently released games for each, pretty much just ignore the final boss in the first game and the resolution in the post cut scenes, because now there’s multiple universes for no reason with no foreshadowing whatsoever. like. stop. there was no cliffhanger or loose ends.

they even got fans jumping through mental hoops about the definition of “remake” to rationalize the unnecessary ridiculousness of breaking the story even further for no benefit, but in 4k. they could have just done the exact same story without the kingdom hearts nonsense but its like someone at Square can’t be fired for some dumb distinctly Japanese reason.

The original didn’t have a lot of the bits you are calling out because it wasn’t trying to retcon in 20+ years worth of story buildup, and is a much simpler story.

That’s not to justify the complexity of the FF7 lore. I think it and Kingdom Hearts are both ridiculously over complex now, but that people delineate between Remake and the original because of that huge divergence in story.

The article and rest of the comments are about the original game.

I find the first game charming and evocative, while acknowledging there were some parts to expand upon, loose ends even, but the way they did that definitely jumped the shark.

I used the hex edit cheats to max out my characters, and breezed through it in 23 hours. A great decision. I got to experience all that plot, all the mini games, and only compromised the combat build aspect of it. The last battle, even at max stats, was not a cakewalk. There were weapons I still have not defeated.

Personally I'm the delayed gratification type where I'll level up to a point where I steamroll all the bad guys in the main storyline. Even high encounter rate areas aren't bad when it's a one hit kill.

    fn add(x: Option<i32>, y: Option<i32>) -> Option<i32> {
        if x.is_none() || y.is_none() {
            return None;
        }
        return Some(x.unwrap() + y.unwrap());
    }
    The above looks kind of clunky because of the none checks it needs to perform, and it also sucks that we have to extract values out of both options and construct a new option out of that. However, we can much better than this thanks to Option’s special properties! Here’s what we could do

    fn add(x: Option<i32>, y: Option<i32>) -> Option<i32> {
        x.zip(y).map(|(a, b)| a+b)
    }

    fn add2(x: Option<i32>, y: Option<i32>) -> Option<i32> {
        Some(x? + y?)
    }

  fn can_use_question_mark_on_option() -> Option<i32> {

  fn can_use_question_mark_on_result() -> Result<i32, ()> {

I prefer the latter now that I understand how all the Result/Option transformations work. As a beginner this would be hard to read but the former looks clunky.

Clippy also got pretty good lately at suggesting such transformations instead of if... blocks. I.e. I guess that means they are considered canonical.

In general I find canonical Rust often more concise than what a beginner would come up with but it does require deeper understanding. I guess this is one of the reasons why Rust is considered 'hard to learn' by many people.

You could actually teach Rust using pretty verbose code that would work but it wouldn't be canonical (and often also not efficient, e.g. the classic for... loop that pushes onto a Vec vs something that uses collect()).

(This is one reason why I'm glad other people are also writing books! Not everyone likes my style!)

It's tough :)

    fn add(x: Option<i32>, y: Option<i32>) -> Option<i32> {
        match (x, y) {
            (Some(x), Some(y)) => Some(x + y),
            _ => None,
        }
    }

We should not avoid language features that reduce boilerplate and drastically increase comprehension for for people who have experience in a language in order to cater to people who have minimal or no experience in that language.

Should we not use `?` in Rust because it might be obscure to someone who's never used the language? Should we not use any of the `Iterator` functions (including `zip` and `map`) because they might be confusing to C programmers who only know `for` loops?

Functional concepts are everywhere these days. Most of them are not hard. `zip` and `map` do not require understanding of homotopy type theory to understand, they are essentially trivial functions. They are available across every type you could possibly iterate over in Rust, and if you understand what they do on one of those you essentially understand what they do on all of them.

This is a toy example, but virtually every piece of hard evidence we have in this field shows that—within reason—more concise code has fewer bugs and is easier to comprehend than longer, more verbose equivalents. Writ large across a project, doubling or tripling the amount of code to bend over backwards accommodating complete novices is lunacy.

If the zip/map version is more common then I take everything back. But it seems less malleable and clear than the pattern matching examples. I had to stop and think for a second to get it. I find pattern matching in general more declarative for small amounts of items.

---

In terms of preferring clearer and simpler code: Absolutely yes. I avoid unnecessary abstractions, especially if the gains are so minor or questionable. It's a matter of empathy and foresight.

Whether that's the case here: I don't know. It might very well be that this is common and clear in the Rust world.

C-style `for` loops were the norm for decades. Now virtually every language gives you some ability to iterate directly over every element in a collection. Replacing a `for` loop with an iterator over each element is never necessary. The old way worked for decades. The gains are minor. Should we go back to C-style `for` loops? If not, why not?

When you understand the answer to that, you’ll understand why that same logic applies to trivial functions like `zip` and `map` that simply take the idea one minor step further.

All the time I see people argue against “unnecessary” abstractions. But this almost always comes from the perspective of “I don’t personally understand it yet” which is just not a reasonable bar for anything to have to clear. Second most frequently it’s “less clear” which often just means “I haven’t internalized it yet” which is likewise a terrible evaluation method for something like functional iteration methods that have the possibility of being used virtually everywhere. And almost equally as often, the underlying objection is that it isn’t useful because the old way is just fine thanks, which is typically a perspective that has completely forgotten about all of the sharp edges and bugs that we all just grew to accept from the preexisting approach.

All of these types of objections are knee-jerk reactions. There are good arguments against bad abstractions, leaky abstractions, infrequently-used abstractions, overly-complex abstractions, and all sorts of other failures to abstract well. But people are so used to these that they reflexively oppose any new abstraction as overly complex or unnecessary simply because it’s new to them.

And that’s a terrible perspective to have, because quite literally all of the progress that has ever been made in the practice of software engineering has been due to abstraction.

I'll also add that option's zip and map are also implemented with a pattern match, like above.

One error and one deviation from the established norm for a toy example is a lot. At the scale of a codebase it would be a catastrophe.

But if you look closely you'll notice that `zip` and `map` were called directly on an array here and not actually on an iterator. That's a third implementation of the same concepts. If Rust had HKTs they could all be the exact same implementation, but not today.

The important thing, though, is that they all conceptually do the same thing. Understanding one essentially translates to understanding them all. If zip/map are called directly on two Options, you get an Option containing a tuple back out. If they're done on two arrays, you get an array containing tuples back out. If they're done on two iterators, you get an iterator containing tuples back out.

There's nothing to be confused about.

No, I don't think that's true, unless we're talking about two different things. In the article, and in the following post https://news.ycombinator.com/item?id=34428999, zip is user on an Option<i32>, takes another Option<i32>, return an Option<(i32, i32)> (which is a tuple, not an array), on which map is applied to extract the two values and add them.

> If zip/map are called directly on two Options, you get an Option containing a tuple back out. If they're done on two arrays, you get an array containing tuples back out. If they're done on two iterators, you get an iterator containing tuples back out.

But that's my whole point. std::option::map is not the same function as std::array::map, which is not the same function as core::iter::Iterator::map. One big difference, for example, is that core::iter::Iterator::map is lazy, while the others are not, hence the note to try to avoid chaining std::array::map, and being careful around it in performance-critical code: https://doc.rust-lang.org/src/core/array/mod.rs.html#466.

Even with HKTs, while you could share some code, that wouldn't solve the fact that the "direct map" (std::option::map for example) is strict, and the other map (std::option::iter::map) is lazy. Especially in a language often used for performance-sensitive tasks, I can't agree that understanding one map translates to understanding them all, since that would be ignoring part of their ergonomics, and more importantly their performance characteristics.

  fn add(x: Option<i32>, y: Option<i32>) -> Option<i32> {
      Some(x? + y?)
  }

Literally everything in programming is inscrutable until you learn it the first time. The latter should be trivial to understand for anyone who's spent even a little amount of time in a language with functional elements.

A day-one beginner doesn't understand a `for` loop. You probably think they're trivial. Bitwise operations are the same. They might be new to you, but `zip` and `map` frankly don't take much more effort to understand than anything else you probably take for granted. `zip` walks through everything in two separate wrappers and pairs up each element inside. `map` opens up a wrapper, lets you do something with what's inside, and re-wraps the result.

For instance, you can do the exact same thing with arrays. Pair up each element inside (like a zipper on clothing), then for every element inside, add them together:

    [1, 3].zip([4, 1]).map(|(a, b)| a + b ) # [5, 4]

    Some(x? + y?)

    match (x, y) {
        (Some(x), Some(y)) => Some(x + y),
        _ => None,
    }

    (Some(x), Some(y)) => Some(x + y)
    else => None

  _ => None,

(For those that didn't catch it, the parent code is trying to use None, but it's actually a tuple, and there's four different cases here, not two. So the catch-all arm is better than spelling each of them out in this case.)

    if let (Some(x), Some(y)) = (x, y) {
       Some(x + y)
    } else {
       None
    }

    Some(x? + y?)

To try with my own words: programming is about shared understanding of a problem, but also the tools used to solve the problem. Code is text, text has a target audience. When it is experts you can use more complex words, or more domain-specific words. When it's intended for a wider audience, taking the time to explain and properly define things, sometimes multiple times, can be necessary.

According to Rust's documentation of Some:

> zip returns Some((s, o)) if self is Some(s) and the provided Option value is Some(o); otherwise, returns None

> zip_with calls the provided function f and returns Some(f(s, o)) if self is Some(s) and the provided Option value is Some(o); otherwise, returns None

Using zip_with seems more appropriate (x.zip_with(y, +) or something) but zip_with is nightly. I also don't like how object chaining makes so that x seems more "fundamental", or "in another category" than y and +, while really x and y are the same, and + is something else. The if solution shows clearly that x and y are the same, by treating them exactly the same. The second solution also introduces a and b from nowhere, doubling the number of variables used in the function. All small things, but I think it can help put words on why precisely the second isn't as readable as it may seem.

It's interesting how much can be said about a simple "add" function.

In other words:

Y is clear if you already understand X. Like how returning early is simple to understand if you understand if-blocks.

That’s the problem with replying to these kinds of questions: the response is so short and context-dependent that it can look curt.

EDIT: the first code is also inelegant in that it effectively checks if both values are `None` twice in the `Some` case: once in the if-condition and once in `unwrap()` (the check that panics if you try to unwrap a `None`).

And doing so greatly increases the likelihood that the compiler can produce perfectly optimal code around them.

So in this case it’s using that fact to form a tuple of non-null values whenever the option is not null, and then acting on that. I think it’s kinda neat, but I wouldn’t personally use zip in this case, I’d have gone with map or and_then depending on whether the output of my operation is T or Option<T>.

By comparison, the first one is straightforward and obvious. It's certainly kinda "ugly" in that it treats Options as very "dumb" things. But I don't need to read any docs or think about what's actually happening when I read the ugly version.

So TLDR: This reads a bit like "clever" code or code-golfing, which isn't always a bad thing, especially if the codebase is mature and contributors are expected to mentally translate between these versions with ease.

The first example, to me, is the worst of all worlds, if you want to be explicit use `match`. Otherwise, having a condition then using `unwrap` just feels like it's needlessly complicated for no reason... Just adding my subjective assessment to the bikeshed.

In the first example—the longer, tedious one—I have to look at the condition to make sure the resulting `unwrap`s never actually happen, and if I reason about it wrong I get an application panic.

    x.zip(y).map(|(a, b)| a + b )

People act like the above requires a Ph.D. in Haskell when it really requires about fifteen minutes of playing around with basic functional concepts that are in at least half the popular programming languages these days. At which point you realize a ton of annoyingly tedious problems can be solved in one line of code that can be easily comprehended by anyone else who's done the same thing.

It's the same thing as driving on the highway. Anyone driving slower than you is an idiot, anyone driving faster than you is a maniac.

Yes, as of Rust 1.66, this function compiles to

  example::add:
      xor     edi, 1
      xor     edx, 1
      xor     eax, eax
      or      edx, edi
      sete    al
      lea     edx, [rsi + rcx]
      ret

You contradict yourself. You can’t deride it as “clever” (whatever the quotes mean) and then in the next breath say that it might be a practical style.

And yes, Rust code in the wild does look like this.

https://smoldungeon.com/pixel-art