"Cloud-native" is a catch-all term for widely adopted shitty technology, such as Go and YAML
💯14🌚3👍1
#prog #c #article
You (probably) don’t need to learn C
You (probably) don’t need to learn C
I’m all for learning C if it will be useful for the job at hand, but you can write lots of great software without knowing C. [выделение моё]
A few people repeated the idea that C teaches you how code “really” executes. But C is an abstract model of a computer, and modern CPUs do all kinds of things that C doesn’t show you or explain. Pipelining, cache misses, branch prediction, speculative execution, multiple cores, even virtual memory are all completely invisible to C programs.
C is an abstraction of how a computer works, and chip makers work hard to implement that abstraction, but they do it on top of much more complicated machinery.
Nedbatchelder
You (probably) don’t need to learn C
I’m tired of this: “You have to learn C so you can understand how a computer really works.”
❤5💩3👍2😁1
Блог*
В этом случае достаточно поменять тип поля irrelevant на UnconditionallyEqual<String> — и можно будет использовать стандартный #[derive(PartialEq)] для достижения требуемого функционала.
#prog #rust
Кое-что я при написании этого поста упустил. Именно, к хэшированию предъявляется логичное требование: если два значения равны, то их хэши также равны.
Кое-что я при написании этого поста упустил. Именно, к хэшированию предъявляется логичное требование: если два значения равны, то их хэши также равны.
UnconditionallyEqual в том виде, как я написал, не реализовывает Hash, поэтому #[derive(Hash)] работать не будет. Тем не менее, заставлять программиста вручную писать реализацию Hash из-за наличия одного такого поля — не лучший UX. Поэтому стоит написать реализацию Hash для UnconditionallyEqual. Из-за изложенного выше требования и того факта, что UnconditionallyEqual не влияет на операцию равенства, корректной реализацией будет noop:impl<T> Hash for UnconditionallyEqual<T> {
fn hash<H: Hasher>(&self, _state: &mut H) {}
}🍌2
#math #article
Hobby’s algorithm for aesthetic Bézier splines
Разновидность сплайнов для "гладкой" интерполяции точек, которая быстро работает (пропорционально числу точек) и зачастую даёт эстетически приятные результаты. Из недостатков: передвижение опорных точек меняет форму всей кривой, и малое передвижение опорной точки может привести к радикальной смене формы кривой в районе этой точки.
В самом начале есть интерактивная демонстрация.
Hobby’s algorithm for aesthetic Bézier splines
Разновидность сплайнов для "гладкой" интерполяции точек, которая быстро работает (пропорционально числу точек) и зачастую даёт эстетически приятные результаты. Из недостатков: передвижение опорных точек меняет форму всей кривой, и малое передвижение опорной точки может привести к радикальной смене формы кривой в районе этой точки.
В самом начале есть интерактивная демонстрация.
🤔2
#prog #rust
Одна из клёвых вещей, которые есть в #zig — это синтаксис для многострочных строковых литералов:
Большим преимуществом этого синтаксиса является тот факт, что он позволяет с лёгкостью сделать отступ для литерала целиком и при этом не добавлять этот отступ в сам литерал, а также требует минимального экранирования (всё до перевода строки — содержимое строки). Аналогичный код в, скажем, Rust, требует такой неприятной вещи:
и поддержки со стороны компилятора для того, чтобы экранирование перевода строки убирало не только сам перевод строки, но и предшествующие пробельные символы. Обратите внимание на то, что мне также пришлось экранировать кавычки и
Именно по этой причине есть аж два RFC (раз, два), которые добавляют новые виды строковых литералов для подобных целей (включения многострочного кода на другом языке). Тем не менее, в обсуждении второго один человек заметил (и тут дела приобретают #abnormalprogramming оборот), что имитировать многострочные литералы из Zig в Rust в некоторой мере можно уже сейчас. Именно, doc-комментарии уже на этапе лексирования заменяются на
Одна из клёвых вещей, которые есть в #zig — это синтаксис для многострочных строковых литералов:
const hello_world_in_c =
\\#include <stdio.h>
\\
\\int main(int argc, char **argv) {
\\ printf("hello world\n");
\\ return 0;
\\}
;
Большим преимуществом этого синтаксиса является тот факт, что он позволяет с лёгкостью сделать отступ для литерала целиком и при этом не добавлять этот отступ в сам литерал, а также требует минимального экранирования (всё до перевода строки — содержимое строки). Аналогичный код в, скажем, Rust, требует такой неприятной вещи:
let hello_world_in_c = "\
#include <stdio.h>\
\n\
\nint main(int argc, char **argv) {\
\n printf(\"hello world\\n\");\
\n return 0;\
\n}";
и поддержки со стороны компилятора для того, чтобы экранирование перевода строки убирало не только сам перевод строки, но и предшествующие пробельные символы. Обратите внимание на то, что мне также пришлось экранировать кавычки и
\n в коде. Сырые строковые литералы позволяют убрать экранирование, но не лишние отступы:let hello_world_in_c = r#"#include <stdio.h>
int main(int argc, char **argv) {
printf("hello world\n");
return 0;
}"#;
Именно по этой причине есть аж два RFC (раз, два), которые добавляют новые виды строковых литералов для подобных целей (включения многострочного кода на другом языке). Тем не менее, в обсуждении второго один человек заметил (и тут дела приобретают #abnormalprogramming оборот), что имитировать многострочные литералы из Zig в Rust в некоторой мере можно уже сейчас. Именно, doc-комментарии уже на этапе лексирования заменяются на
#[doc]-атрибуты, а потому можно макросом извлечь эти литералы из атрибутов и сконкатенировать:macro_rules! text {
(#[doc=$first_line:literal] $(#[doc=$lines:literal])*) => {
concat!($first_line, $("\n", $lines),*)
};
}
let hello_world_in_c = text! {
///#include <stdio.h>
///
///int main(int argc, char **argv) {
/// printf("hello world\n");
/// return 0;
///}
};GitHub
Propose code string literals by Diggsey · Pull Request #3450 · rust-lang/rfcs
Add a new syntax for multi-line string literals designed to contain code and play nicely with rustfmt.
Rendered
Rendered
🥴19❤2🤔2
Forwarded from Технологический Болт Генона
Я тут с оказией фаззил один из npm-модулей, который парсит YAML и узнал, что в YAML есть конструкция в виде трёх точек -
... doc-end Explicit marker for the end of a document.
https://github.com/eemeli/yaml/blob/main/docs/07_parsing_yaml.md#lexsource-string-string
И реально в спеке такое есть (было бы удивительно, если бы не было, конечно 🌝)
Three dots ( “...”) indicate the end of a document without starting a new one, for use in communication channels.
https://yaml.org/spec/1.2.2/
Я просмотрел и написал какое-то бесчисленное количество YAML-файлов и не видел ни в одном из них этой конструкции.
...... doc-end Explicit marker for the end of a document.
https://github.com/eemeli/yaml/blob/main/docs/07_parsing_yaml.md#lexsource-string-string
И реально в спеке такое есть (было бы удивительно, если бы не было, конечно 🌝)
Three dots ( “...”) indicate the end of a document without starting a new one, for use in communication channels.
https://yaml.org/spec/1.2.2/
---
time: 20:03:20
player: Sammy Sosa
action: strike (miss)
...
---
time: 20:03:47
player: Sammy Sosa
action: grand slam
...
Я просмотрел и написал какое-то бесчисленное количество YAML-файлов и не видел ни в одном из них этой конструкции.
🤷4🤔2👍1