主要观点：

• Diego 写了关于不喜欢 Advent of Code 的文章，促使作者回顾 2023 年的经历，最终决定写下一些想法。
• 作者多次尝试 Advent of Code，2023 年更努力尝试完成挑战但未全部完成。
• 选择 Rust 语言用于解决问题，设定只用纯 Rust 且不用 cargo 的挑战，遇到一些问题如更紧类型的错误处理、默认大量调试输出等。
• 喜欢 Rust 的丰富数据类型、impl为结构添加方法等，也指出其语法对非 C++程序员较难理解、借用检查器增加思考负担等。
• 阐述 Advent of Code 的格式和每天的挑战，觉得部分问题规格不清晰，短示例输入有时帮助不大，有时暴力解法不适用，整体虽有吸引力但因日常工作写代码等原因感觉像负担而非有趣练习，决定不再参与今年的 Advent of Code 但会继续使用 Rust。

关键信息：

• Diego 的相关文章链接：https://flameeyes.blog/2024/0...
• Advent of Code 2023 链接：https://adventofcode.com/2023
• Rust 相关链接：https://www.rust-lang.org/、https://docs.rs/anyhow/latest...、https://doc.rust-lang.org/std...
• 作者 2021 年有短暂尝试，2022 年完成 4 天，2023 年大部分时间在尝试完成挑战但未完成 12 月 24 日和 25 日的部分
• 作者认为 Rust 语法难理解，借用检查器增加负担，喜欢其丰富数据类型和impl，但对外部 crate 生态有不满
• Advent of Code 格式为 12 月 1 日至 25 日每天发布问题，分两部分，第二部分需先答对第一部分，有排行榜，谜题发布时间为 UTC-5 午夜，作者常错过一两天后需追赶
• 部分问题规格不清晰，短示例输入有时无用，暴力解法有时不适用，作者认为不是所有问题都能提前准备好通用解法，且 Advent of Code 环境不鼓励优化通用解

重要细节：

• 作者用unwrap()较多，认为若有更通用错误处理可用?
• 用rustc -O -C target-cpu=native source.rs得到更好的一些解决方案
• 作者觉得 Go 语法简单易学习，Rust 语法更复杂
• 作者在一个解决方案中使用了RefCell，在循环中使用.iter()而非显式迭代器，常忘记显式标记变量为可变
• 作者认为 Advent of Code 整体有吸引力但因日常工作等原因感觉像负担，不打算再参与今年的活动但会继续使用 Rust