Как раз наоборот, Rust в полной мере раскрывается в больших, сложных или долгих проектах! Как раз основная мысль статьи в том, что Rust намного проще рефакторить, что наиболее важно как раз в больших проектах. В Rust компилятор не враг, чтобы с ним бороться, это лучший друг, которых покажет на ошибку на самом раннем этапе разработки.
Лично я для большого проекта брал бы язык с более очевидным синтаксисом
Выше я уже отвечал, для меня синтаксис не играет большой роли. Rust позволяет мне выражать мои идеи в коде без необходимости неделю думать о UB, том, что надо создать тип Nothing чтобы отделять разные типы пустых значений и т.д.
Да, статью "что не так с Golang" я бы почитал.
Это скорее шутка, у меня, все же, слишком мало опыта в Golang, буквально 2 недели попытки его выучить и пара месяцев обсуждений с друзьями "как так оказалось, что в Golang все настолько плохо". Просто когда в официальном курсе на официальном сайте Golang я умудрился задуматься "хм, кажется это какой-то бред" (и при этом я оказывался прав) раза 4.
Для примера добавлю сюда примеры кода, который вызывает у меня вопросы в духе "а хоть кто-то при разработке над чем-то кроме GC и async рантайма думал вообще?":
Заголовок спойлера
package main
import "fmt"
func main() {
s := []int{2, 3, 5, 7, 11, 13}
printSlice(s)
// Slice the slice to give it zero length.
s= s[:0]
printSlice(s)
// Extend its length.
s = s[:6]
printSlice(s)
s= append(s, 7)
printSlice(s)
// Works just fine
d := s[0:cap(s)][11]
fmt.Printf("len=%d cap=%d d=%v\n", len(s), cap(s), d)
// Obviously this panics
g := s[11]
fmt.Println(g)
}
func printSlice(s []int) {
fmt.Printf("len=%d cap=%d %v\n", len(s), cap(s), s[0:cap(s)])
}
package main
import (
"fmt"
"math/rand/v2"
)
type SlidingWindow struct {
s []int
offset int
size int
}
func (w *SlidingWindow) next() []int {
if w.offset > (len(w.s) - w.size + 1) {
return nil
}
t := w.s[w.offset : w.offset+w.size]
w.offset += 1
return t
}
func sliding_window(s []int, offset int, size int) []int {
return s[offset : offset+size]
}
func main() {
s2 := []int{1, 2, 3, 4, 5, 6}
if rand.IntN(10) > 5 {
s2 = append(s2, 7) // panics without append
}
sw := SlidingWindow{s2, 0, 3}
for w := sw.next(); w != nil; w = sw.next() {
fmt.Println(w)
}
}
package main
import (
"fmt"
"math/rand/v2"
)
func really_big_func() (a, b bool) {
// a lot of code
// Happy debugging, suckers
true := rand.IntN(10) > 5
false := rand.IntN(10) > 3
fmt.Println(true)
fmt.Println(false)
// a lot of code
return true, false
}
func main() {
fmt.Println(really_big_func())
}
package main
type Container struct {
a int // old field
Items map[string]int32 // new field
}
func (c *Container) Insert(key string, value int32) {
c.Items[key] = value
}
func main() {
c := Container{a: 2}
c.Insert("number", 32)
}
Меня не особо волнует синтаксис как таковой, не Brainfuck и ладно. К любому синтаксису привыкаешь за 2 недели. Мне гораздо важнее то, что с помощью этого синтаксиса можно сделать.
Не могу говорить за все Rust сообщество, люди там разные и бывает всякое, я точно помню как минимум несколько довольно крупных скандала в Rust комьюнити, но с другой стороны я не знаю ни одного сообщества, где не было бы ни одного скандала вообще.
Обычно, если нужна какая-то помощь, то тут и помогут, и объяснят разные варианты с их плюсами и минусами или почему это плохая идея. В обычном общении я не видел примеров токсичного поведения.
Кроме того, что уже сказано выше про неинициализированные поля мне добавить нечего. Добавить я могу только то, что, по моему мнению, zero values в Golang это ошибка сама по себе. Это заставляет все типы иметь какое-то значение по умолчанию, хотя для типа может просто не быть такого значения.
Каналы хороший пример такого, в nil канале нет никакого смысла, у него нет и не может быть какого-то логичного поведения. Из-за этого теперь у nil канала есть очень странное поведение - создание дедлоков. Зачем вообще иметь возможность создать, по сути, невалидный объект, который при любом обращении вызывает баг?
Или разница в поведении слайсов и мап. Nil слайс на практике от слайса нулевой длины ничего не отличается. Nil мапа же почему-то не может при записи аллоцировать память и теперь у такой мапы есть 2 возможных использования: 1) узнать, что ключа (любого) в этой мапе нет; 2) получить панику при попытке ключ записать. И такой потрясающий объект можно вернуть из функции ничего не подозревающему пользователю, вот он то обрадуется.
В safe Rust UB нет (точнее, если оно есть то это баг компилятора, который надо исправить), так что мне с практической точки зрения сказать нечего. Из моего теоретического опыта UB действительно очень плохо.
Насколько я понимаю, UB - это когда компилятор считает, что у него есть какие-то гарантии, которые в реальности не выполняются. С UB компилятор может сделать все что угодно, т.к. он будет оптимизировать код исходя из неверных предпосылок. Из-за этого компилятор может, например, просто скомпилировать программу, которая делает не то, что написано в коде или удалить кусок кода с UB, т.к. в правильной программе UB быть не может, а значит этот код недостижим.
UB одновременно зависит от всего вокруг (от кода вокруг, от компилятора, от версии компилятора, от багов в компиляторе, от фазы луны и т.д.), а в другой стороны, если в коде есть UB то эта программа - не программа. Компилятор имеет право сделать абсолютно что угодно со всем кодом т.к. код просто невалиден. Вот статья с примерами UB. Я после этого даже смотреть на языки с UB не могу, там надо прикладывать какие-то невероятные усилия для правильной работы конечного продукта.
В планах на изучить Haskell есть (может еще F#), но скорее для того, чтобы посмотреть ~~есть ли жизнь на марсе~~ как живется в полностью функциональном языке без доступа к мутабельности, может быть позаимствовать какие-нибудь подходы.
Вот никогда не понимал этот аргумент. Автор библиотеки может жить в Х, автор кода в стандартной библиотеке может жить в Х, автор компилятора\интерпретатора может жить в Х, автор виртуальной машины\контейнера, в котором код запускается может жить в Х, автор кода TCP/IP используемой ОС может жить в Х, автор драйверов сетевой карты может жить в Х, дизайнер железа этой сетевой карты может жить в Х, дизайнер чипов, используемых в этой сетевой карте может жить в Х, автор чего угодно может жить в Х.
Для очень серьезных вещей используется собственный package registry, только вместо обычного кеширующего прокси он только хранит проверенные пакеты проверенных версий.
Если вам кто-то угрожает и заставляет использовать внешние зависимости вы моргните 2 раза и мы все поймем.
Вероятно вы не понимаете во что данный код компилятором оптимизируется
Это даже немного иронично, но я как раз прекрасно это понимаю. Потому, что black_box это не "функцию возвращающую 1", а хинт компилятору как раз чтобы все это не соптимизировалось в
playground::regular_counter:
mov eax, 1000000
ret
regular_counter как раз так и оптимизируется.
даже близко не отражает никакой реальный паттерн использования таких указателей
Согласен. Но я на это и не претендовал. Это просто 1кк клонов с какой-то самой минимальной работой для того, чтобы её как раз нельзя было в 0 соптимизировать. И как я же и сказал, это не имеет значения в большинстве случаев, но 1) разница в скорости от этого никуда не денется; 2) возможность выбрать лучше, чем её отсутствие. Потому что иногда эта разница очень даже может иметь значение.
Edit: "Результаты" без black_box:
testing regular_counter, min time = 0 microseconds
testing indirect_counter, min time = 0 microseconds
testing boxed_counter, min time = 0 microseconds
testing boxed_indirect_counter, min time = 0 microseconds
testing atomic_counter, min time = 5406 microseconds
testing rc_counter, min time = 0 microseconds
testing arc_counter, min time = 11036 microseconds
Ради интереса сделал простенький бенчмарк между Rc и Arc. Разница почти в 3 раза. Да, в большинстве случаев это не важно, но лучше иметь выбор, чем не иметь кмк.
testing regular_counter, min time = 0 microseconds
testing indirect_counter, min time = 338 microseconds
testing boxed_counter, min time = 2280 microseconds
testing boxed_indirect_counter, min time = 2137 microseconds
testing atomic_counter, min time = 5401 microseconds
testing rc_counter, min time = 4620 microseconds
testing arc_counter, min time = 11031 microseconds
Мне тоже кажется, что если злоумышленник владеет достаточно большим кол-вом номером то тогда это только вопрос вероятности пройдет через него смс с кодом или нет. В пределе, если все телефоны из этой программы под контролем одного человека (или организации) то тогда все коды будут проходить через эту ферму и можно легко самому инициировать логин, самому получить код и жертва даже не узнает т.к. злоумышленник может просто не отправлять смс жертве. Не знаю существуют ли подобные фермы и не знаю насколько сложно из сделать, но выглядит очень сомнительно.
Вот только размеры бинарников к этим 100-150ГБ имеет примерно никакого отношения, это текстуры, видео и аудио. Ради интереса даже проверил на своей текущей стимовской библиотеке, 0.6% приходится на .exe, 1.6% на dll. Еще лет 10 назад шутки про мыльные текстуры были актуальны, даже не вспоминая что до этого было. И единственное реалистичное решение (бесплатное dlc для UHD текстур и прочего) не то, чтобы без минусов, уверен куча людей не заметит и будет в отзывах писать про мыло в глазах и прочие шутки.
Потому, что она не якобы очищает ресурсы. Например вот из стандартной библиотеки пример, пытаемся записать буфер в дропе (если не сам писатель эту панику кинул). И для этого не нужно эту панику никак специально обрабатывать, скорее возможность эту панику перехватить . По моему мнению лучше по умолчанию все же хотя бы пытаться все нормально закрыть, а не просто умирать.
Если рассматривать клавиатуру только для игр то можно просто купить отдельную игровую клаву типа Logitech G13 (конкретно её не пробовал, но подобными уже лет 10 пользуюсь). Для практически всего, где управление одновременно и с клавы, и с мыши с такой клавой удобнее, только надо всякие i, j, m и прочие штуки с правой половины клавиатуры куда-нибудь на левую забиндить и отлично играется. Вот в условный starcraft на +- серьезном уровне с кучей хоткеев по всей клавиатуре наверно будет не очень удобно, но сам не проверял.
Ergodox в руках не держал, но этот комментарий пишу с moonander'а и могу сказать, что у меня большой палец в полностью расслабленной позиции ложится ровно ни ближайшую кнопку thumb cluster и "дотянуться" до самой дальней (не большой красной, как её предполагается нажимать не отрывая руку я не представляю) легче, чем мизинцем до ctrl'а. Размер перчаток L, thumb cluster еще и вниз опущен т.к. было слишком близко. С учетом того, что его можно и ближе к руке наклонить совсем не понятно, насколько маленькие должны быть руки.
Часто используемые горячие клавиши я просто вынес на отдельный слой и теперь для них мне вообще все равно что там нажимать надо. Для редких вещей у меня 2 пути: 1) у меня отдельный слой, на котором есть все F-клавиши + на +- обычных местах модификаторы (Ctrl, Shift, Alt и Win); 2) на основном слое у меня при зажатии цифр отправляется соответствующая F-клавиша (F11 и F12 тоже недалеко есть).
Мне кажется, что слои не просто раскрывают себя на более компактных клавиатурах, а просто делают полноразмерные ненужными. Зачем нужен numpad, стрелки, F-блок, home/end и т.д. в качестве физических блоков, которые занимают место и добавляют веса когда можно использовать слои, что еще и удобнее т.к. рука всегда на одном месте. Перед moonlander я купил себе полноразмерную HyperX Alloy FPS с numpad'ом и я так и не смог расположить её так, чтобы и левой руке было удобно, и было достаточно места для мышки с правой стороны. Со слоями таких проблем в принципе нет, любые клавиши при любом размере (это даже не говоря о таких клавишах, которых в принципе на клавиатурах обычно нет, вроде F13-F24, lang, international и т.д., на которые тоже можно что-нибудь добавить).
Хочу дополнительно рассказать о возможностях QMK т.к. по моему мнению именно это то, что может реально увеличить удобство (а может и производительность) работы с клавиатурой гораздо сильнее, чем тот факт, что это механика.
После того, как я купил и попробовал moonlander (механическая split клавиатура с QMK) мои приоритеты с
split клавиатура - можно поставить её на нормальное растояние (причем можно и не семмитрично) и больше не надо искривлять запястья с плечи;
механика - все же если найти нравящиеся по ощущениям свитчи то печатается легче и приятнее;
QMK - надо попробовать что там за слои такие;
поменялись на
QMK - СЛОИ!, возможность программировать свою логику, просто невероятное количество возможностей для любых задач, которые хоть как-то связанны с клавиатурой, больше без QMK я себе клавиатуру не куплю никогда;
Split клавиатура - реально помогает избавиться от болей в плечах и запястьях, ни одна эргономичная клавиатура и рядом не стоит по удобству;
Механика - все еще приятно если свитчи подобрать;
Почему по моему мнению QMK настолько крутая вещь:
Слои - после того, как начинаешь их использовать необходимость отрывать руки для того, чтобы дотянуться до какой-либо клавиши пропадает навсегда. Сейчас у меня более-менее активно используются только около 50 клавиш и где-то треть клавиш я практически не использую потому, что если использовать слои, то оказывается, что все нужные функции могут быть всегда прямо под рукой (буквально, на home row). Так у меня всегда буквально под руками numpad, f-клавиши, стрелки и home, end и т.д., самые полезные горячие клавиши, знаки пунктуации. После этого даже думать не хочется о том, что к numpad'у нужно было бы тянуться и ему надо занимать собой место. Как оказалось ни то, ни то не обязательно!
Tap dance - можно делать совсем простые вещи, вроде ввода ъ при зажатиии ь, илив. например, сделать home row mode (https://precondition.github.io/home-row-mods тут объясняется гораздо более подробно), что позволяет даже за клавишами-модификаторами не тянуться, они тоже всегда под рукой.
Возможность кастомизации - все вышеперечисленное более-менее можно сделать с помощью графических интерфейсов (что гораздо удобнее и быстрее), но QMK это полноценная прошивка в которой можно делать какое-то невероятное количество вещей. Вот список того, что необычного может моя клавиатура:
При переключении на слой с русской раскладкой так же автоматически отсылается Ctrl-Shift-Alt-Win-F2 (комбинация, на которую никто в своем уме ничего не повесит) и по этой комбинации меняется раскладка ОС (причем и в windows (просто так можно использовать только Ctrl-Shift - "кнопка", но я все равно использовал keyla для глобального переключения раскладки, а там можно забить любой хоткей) и в linux (например, в virtualbox тоже)). Так же у слоев с русской и английской раскладкой разная подсветка и боковым зрением всегда понимаешь, какая сейчас раскладка, что удобно;
Я могу вводить любые знаки (вроде []<>$& и т.д.), а на самом деле и любой юникод из любой раскладки. Т.к. у меня есть отдельный слой для символов меня очень раздражала невозможность ввести, например, @ в русской раскладке, особенно когда нужен только 1 символ приходится дополнительно переключать раскладку 2 раза. Но, как оказалось, можно это обойти и вместо самих символов выводить юникодные номер символа (на самом деле U + "номер симвода") и с помощью .xcompose выводить по этому вводу уже нужные мне символы. Пришлось помучиться как в linux, так и в windows (есть улитита WinCompose для этого) чтобы это универсально заработало и там, и там, но в конечном итоге все получилось;
Если подключена только левая половина клавиатуры, то автоматически влючается слой с qwerty раскладкой для игр;
Еще думаю над тем, как сделать так, чтобы можно было изменять раскладку последнего введенного слова, пока у меня ощущение что это возможно;
После такого многообразия весь софт для игровых клавиатур кажется невероятно примитивным. Так что для тех, у кого клавиатура это просто инструмент я хочу посоветовать посмотреть именно в эту сторону, QMK действительно позволяет сделать клавиатуру гораздо более интересным и полезным инструментом, чем обычная клавиатура.
Как раз наоборот, Rust в полной мере раскрывается в больших, сложных или долгих проектах! Как раз основная мысль статьи в том, что Rust намного проще рефакторить, что наиболее важно как раз в больших проектах. В Rust компилятор не враг, чтобы с ним бороться, это лучший друг, которых покажет на ошибку на самом раннем этапе разработки.
К сожалению, у меня нет личного опыта подобных проектов в Rust. Мое мнение о Rust основано на опыте больших проектов в других языков, но о больших проектах говорят в Fast Development In Rust, Part One, Beyond Safety and Speed: How Rust Fuels Team Productivity, Grading on a Curve: How Rust can Facilitate New Contributors while Decreasing Vulnerabilities и нескольких реддит постах из начала статьи, так что мне кажется, что моя экстраполяция вполне валидна.
Выше я уже отвечал, для меня синтаксис не играет большой роли. Rust позволяет мне выражать мои идеи в коде без необходимости неделю думать о UB, том, что надо создать тип Nothing чтобы отделять разные типы пустых значений и т.д.
Это скорее шутка, у меня, все же, слишком мало опыта в Golang, буквально 2 недели попытки его выучить и пара месяцев обсуждений с друзьями "как так оказалось, что в Golang все настолько плохо". Просто когда в официальном курсе на официальном сайте Golang я умудрился задуматься "хм, кажется это какой-то бред" (и при этом я оказывался прав) раза 4.
Но уже много кто написал такие статьи, я рекомендую I want off Mr. Golang's Wild Ride, Lies we tell ourselves to keep using Golang, They're called Slices because they have Sharp Edges: Even More Go Pitfalls, Golang is not a good language.
Для примера добавлю сюда примеры кода, который вызывает у меня вопросы в духе "а хоть кто-то при разработке над чем-то кроме GC и async рантайма думал вообще?":
Заголовок спойлера
Меня не особо волнует синтаксис как таковой, не Brainfuck и ладно. К любому синтаксису привыкаешь за 2 недели. Мне гораздо важнее то, что с помощью этого синтаксиса можно сделать.
Не могу говорить за все Rust сообщество, люди там разные и бывает всякое, я точно помню как минимум несколько довольно крупных скандала в Rust комьюнити, но с другой стороны я не знаю ни одного сообщества, где не было бы ни одного скандала вообще.
Обычно, если нужна какая-то помощь, то тут и помогут, и объяснят разные варианты с их плюсами и минусами или почему это плохая идея. В обычном общении я не видел примеров токсичного поведения.
Кроме того, что уже сказано выше про неинициализированные поля мне добавить нечего. Добавить я могу только то, что, по моему мнению, zero values в Golang это ошибка сама по себе. Это заставляет все типы иметь какое-то значение по умолчанию, хотя для типа может просто не быть такого значения.
Каналы хороший пример такого, в nil канале нет никакого смысла, у него нет и не может быть какого-то логичного поведения. Из-за этого теперь у nil канала есть очень странное поведение - создание дедлоков. Зачем вообще иметь возможность создать, по сути, невалидный объект, который при любом обращении вызывает баг?
Или разница в поведении слайсов и мап. Nil слайс на практике от слайса нулевой длины ничего не отличается. Nil мапа же почему-то не может при записи аллоцировать память и теперь у такой мапы есть 2 возможных использования: 1) узнать, что ключа (любого) в этой мапе нет; 2) получить панику при попытке ключ записать. И такой потрясающий объект можно вернуть из функции ничего не подозревающему пользователю, вот он то обрадуется.
Можете привести какой-нибудь пример? Потому, что пока не очень понятно о чем вы.
В safe Rust UB нет (точнее, если оно есть то это баг компилятора, который надо исправить), так что мне с практической точки зрения сказать нечего. Из моего теоретического опыта UB действительно очень плохо.
Насколько я понимаю, UB - это когда компилятор считает, что у него есть какие-то гарантии, которые в реальности не выполняются. С UB компилятор может сделать все что угодно, т.к. он будет оптимизировать код исходя из неверных предпосылок. Из-за этого компилятор может, например, просто скомпилировать программу, которая делает не то, что написано в коде или удалить кусок кода с UB, т.к. в правильной программе UB быть не может, а значит этот код недостижим.
UB одновременно зависит от всего вокруг (от кода вокруг, от компилятора, от версии компилятора, от багов в компиляторе, от фазы луны и т.д.), а в другой стороны, если в коде есть UB то эта программа - не программа. Компилятор имеет право сделать абсолютно что угодно со всем кодом т.к. код просто невалиден. Вот статья с примерами UB. Я после этого даже смотреть на языки с UB не могу, там надо прикладывать какие-то невероятные усилия для правильной работы конечного продукта.
В планах на изучить Haskell есть (может еще F#), но скорее для того, чтобы посмотреть ~~есть ли жизнь на марсе~~ как живется в полностью функциональном языке без доступа к мутабельности, может быть позаимствовать какие-нибудь подходы.
Вот никогда не понимал этот аргумент. Автор библиотеки может жить в Х, автор кода в стандартной библиотеке может жить в Х, автор компилятора\интерпретатора может жить в Х, автор виртуальной машины\контейнера, в котором код запускается может жить в Х, автор кода TCP/IP используемой ОС может жить в Х, автор драйверов сетевой карты может жить в Х, дизайнер железа этой сетевой карты может жить в Х, дизайнер чипов, используемых в этой сетевой карте может жить в Х, автор чего угодно может жить в Х.
Для очень серьезных вещей используется собственный package registry, только вместо обычного кеширующего прокси он только хранит проверенные пакеты проверенных версий.
Если вам кто-то угрожает и заставляет использовать внешние зависимости вы моргните 2 раза и мы все поймем.
Это даже немного иронично, но я как раз прекрасно это понимаю. Потому, что black_box это не "функцию возвращающую 1", а хинт компилятору как раз чтобы все это не соптимизировалось в
regular_counter как раз так и оптимизируется.
Согласен. Но я на это и не претендовал. Это просто 1кк клонов с какой-то самой минимальной работой для того, чтобы её как раз нельзя было в 0 соптимизировать. И как я же и сказал, это не имеет значения в большинстве случаев, но 1) разница в скорости от этого никуда не денется; 2) возможность выбрать лучше, чем её отсутствие. Потому что иногда эта разница очень даже может иметь значение.
Edit: "Результаты" без black_box:
Ради интереса сделал простенький бенчмарк между Rc и Arc. Разница почти в 3 раза. Да, в большинстве случаев это не важно, но лучше иметь выбор, чем не иметь кмк.
Речь про эту статью. Еще рекомендую вот это видео.
Мне тоже кажется, что если злоумышленник владеет достаточно большим кол-вом номером то тогда это только вопрос вероятности пройдет через него смс с кодом или нет. В пределе, если все телефоны из этой программы под контролем одного человека (или организации) то тогда все коды будут проходить через эту ферму и можно легко самому инициировать логин, самому получить код и жертва даже не узнает т.к. злоумышленник может просто не отправлять смс жертве. Не знаю существуют ли подобные фермы и не знаю насколько сложно из сделать, но выглядит очень сомнительно.
Вот только размеры бинарников к этим 100-150ГБ имеет примерно никакого отношения, это текстуры, видео и аудио. Ради интереса даже проверил на своей текущей стимовской библиотеке, 0.6% приходится на .exe, 1.6% на dll. Еще лет 10 назад шутки про мыльные текстуры были актуальны, даже не вспоминая что до этого было. И единственное реалистичное решение (бесплатное dlc для UHD текстур и прочего) не то, чтобы без минусов, уверен куча людей не заметит и будет в отзывах писать про мыло в глазах и прочие шутки.
Потому, что она не якобы очищает ресурсы. Например вот из стандартной библиотеки пример, пытаемся записать буфер в дропе (если не сам писатель эту панику кинул). И для этого не нужно эту панику никак специально обрабатывать, скорее возможность эту панику перехватить . По моему мнению лучше по умолчанию все же хотя бы пытаться все нормально закрыть, а не просто умирать.
Вот мой ответ на этот вопрос, ссылкой чтобы не копипастить из другой статьи.
Если рассматривать клавиатуру только для игр то можно просто купить отдельную игровую клаву типа Logitech G13 (конкретно её не пробовал, но подобными уже лет 10 пользуюсь). Для практически всего, где управление одновременно и с клавы, и с мыши с такой клавой удобнее, только надо всякие i, j, m и прочие штуки с правой половины клавиатуры куда-нибудь на левую забиндить и отлично играется. Вот в условный starcraft на +- серьезном уровне с кучей хоткеев по всей клавиатуре наверно будет не очень удобно, но сам не проверял.
Ergodox в руках не держал, но этот комментарий пишу с moonander'а и могу сказать, что у меня большой палец в полностью расслабленной позиции ложится ровно ни ближайшую кнопку thumb cluster и "дотянуться" до самой дальней (не большой красной, как её предполагается нажимать не отрывая руку я не представляю) легче, чем мизинцем до ctrl'а. Размер перчаток L, thumb cluster еще и вниз опущен т.к. было слишком близко. С учетом того, что его можно и ближе к руке наклонить совсем не понятно, насколько маленькие должны быть руки.
Часто используемые горячие клавиши я просто вынес на отдельный слой и теперь для них мне вообще все равно что там нажимать надо. Для редких вещей у меня 2 пути: 1) у меня отдельный слой, на котором есть все F-клавиши + на +- обычных местах модификаторы (Ctrl, Shift, Alt и Win); 2) на основном слое у меня при зажатии цифр отправляется соответствующая F-клавиша (F11 и F12 тоже недалеко есть).
Вот скриншоты моей раскладки
Полностью можно посмотреть тут
Мне кажется, что слои не просто раскрывают себя на более компактных клавиатурах, а просто делают полноразмерные ненужными. Зачем нужен numpad, стрелки, F-блок, home/end и т.д. в качестве физических блоков, которые занимают место и добавляют веса когда можно использовать слои, что еще и удобнее т.к. рука всегда на одном месте. Перед moonlander я купил себе полноразмерную HyperX Alloy FPS с numpad'ом и я так и не смог расположить её так, чтобы и левой руке было удобно, и было достаточно места для мышки с правой стороны. Со слоями таких проблем в принципе нет, любые клавиши при любом размере (это даже не говоря о таких клавишах, которых в принципе на клавиатурах обычно нет, вроде F13-F24, lang, international и т.д., на которые тоже можно что-нибудь добавить).
Хочу дополнительно рассказать о возможностях QMK т.к. по моему мнению именно это то, что может реально увеличить удобство (а может и производительность) работы с клавиатурой гораздо сильнее, чем тот факт, что это механика.
После того, как я купил и попробовал moonlander (механическая split клавиатура с QMK) мои приоритеты с
split клавиатура - можно поставить её на нормальное растояние (причем можно и не семмитрично) и больше не надо искривлять запястья с плечи;
механика - все же если найти нравящиеся по ощущениям свитчи то печатается легче и приятнее;
QMK - надо попробовать что там за слои такие;
поменялись на
QMK - СЛОИ!, возможность программировать свою логику, просто невероятное количество возможностей для любых задач, которые хоть как-то связанны с клавиатурой, больше без QMK я себе клавиатуру не куплю никогда;
Split клавиатура - реально помогает избавиться от болей в плечах и запястьях, ни одна эргономичная клавиатура и рядом не стоит по удобству;
Механика - все еще приятно если свитчи подобрать;
Почему по моему мнению QMK настолько крутая вещь:
Слои - после того, как начинаешь их использовать необходимость отрывать руки для того, чтобы дотянуться до какой-либо клавиши пропадает навсегда. Сейчас у меня более-менее активно используются только около 50 клавиш и где-то треть клавиш я практически не использую потому, что если использовать слои, то оказывается, что все нужные функции могут быть всегда прямо под рукой (буквально, на home row). Так у меня всегда буквально под руками numpad, f-клавиши, стрелки и home, end и т.д., самые полезные горячие клавиши, знаки пунктуации. После этого даже думать не хочется о том, что к numpad'у нужно было бы тянуться и ему надо занимать собой место. Как оказалось ни то, ни то не обязательно!
Tap dance - можно делать совсем простые вещи, вроде ввода ъ при зажатиии ь, илив. например, сделать home row mode (https://precondition.github.io/home-row-mods тут объясняется гораздо более подробно), что позволяет даже за клавишами-модификаторами не тянуться, они тоже всегда под рукой.
Возможность кастомизации - все вышеперечисленное более-менее можно сделать с помощью графических интерфейсов (что гораздо удобнее и быстрее), но QMK это полноценная прошивка в которой можно делать какое-то невероятное количество вещей. Вот список того, что необычного может моя клавиатура:
При переключении на слой с русской раскладкой так же автоматически отсылается Ctrl-Shift-Alt-Win-F2 (комбинация, на которую никто в своем уме ничего не повесит) и по этой комбинации меняется раскладка ОС (причем и в windows (просто так можно использовать только Ctrl-Shift - "кнопка", но я все равно использовал keyla для глобального переключения раскладки, а там можно забить любой хоткей) и в linux (например, в virtualbox тоже)). Так же у слоев с русской и английской раскладкой разная подсветка и боковым зрением всегда понимаешь, какая сейчас раскладка, что удобно;
Я могу вводить любые знаки (вроде []<>$& и т.д.), а на самом деле и любой юникод из любой раскладки. Т.к. у меня есть отдельный слой для символов меня очень раздражала невозможность ввести, например, @ в русской раскладке, особенно когда нужен только 1 символ приходится дополнительно переключать раскладку 2 раза. Но, как оказалось, можно это обойти и вместо самих символов выводить юникодные номер символа (на самом деле U + "номер симвода") и с помощью .xcompose выводить по этому вводу уже нужные мне символы. Пришлось помучиться как в linux, так и в windows (есть улитита WinCompose для этого) чтобы это универсально заработало и там, и там, но в конечном итоге все получилось;
Если подключена только левая половина клавиатуры, то автоматически влючается слой с qwerty раскладкой для игр;
Еще думаю над тем, как сделать так, чтобы можно было изменять раскладку последнего введенного слова, пока у меня ощущение что это возможно;
После такого многообразия весь софт для игровых клавиатур кажется невероятно примитивным. Так что для тех, у кого клавиатура это просто инструмент я хочу посоветовать посмотреть именно в эту сторону, QMK действительно позволяет сделать клавиатуру гораздо более интересным и полезным инструментом, чем обычная клавиатура.