Но раст ведь можно выбирать не только из-за работы с памятью и отсутствию gc. Лично мне он приятен очень хорошей инфраструктурой, простым стартом и нормальной системой типов. Просто приятный язык, который даёт хорошие гарантии для твоего кода. А память и производительность только приятный довесок.
"не больше 1 изменяемой ссылки на объект" - страшная тупость
Это что, вон в хаскеле вообще нет изменяемых переменных в обычном виде. Там для того чтобы завести изменяемое значение люди целые монады городят! Ну тупыыые.
Ну вы обобщаете, про идиотов, сроки и дебаг, я вот тоже обобщаю. Я говорил про конкретную касту "отрицальщиков типов", с которыми я лично работал. Они обычно гордятся своим незнанием, любят делать запутанные штуки, используют динамические возможности JS во зло, скажем так. При этом есть огромная куча хороших проектов на чистом JS, которые понятны и хорошо работают.
я прекрасно вижу какой ценой достигается это "удобство" и "понятность". Код пишется дольше, читается дольше и работает хуже по всем метрикам .
Конечно можно верить во всемирный заговор Microsoft по созданию TS, как инструмента для затягивания сроков и увеличения бюджетов. А можно задуматься, а почему с TS у вас код даже работает хуже, хотя по-факту это надмножество языка. TS создавался с целью помочь программистам. Если же вы с ним боретесь, то вероятно надо повысить экспертизу в команде, например. Know your instrument, как говорится. Причем, в отличие от других языков, тут можно задавать уровень точности компилятора, и в случае затруднений точечно избегать типизации. Можно обходиться только простыми интерфейсами, без дженериков и всяких advaced types, чисто для дополнительной помощи в IDE. А можно проинвестировать в знания и фигачить всё на максималках, с большим трудом, но и с большими гарантиями и большим профитом по итогу.
В конце концов, я предпочту, чтобы за меня всякой рутиной по проверке корректности данных занимались проклятые роботы, а я уж логику буду писать и тестировать именно её, а не писать тесты на то чтобы в функцию какую-то фигню не передали.
Я просто боюсь, что так сильно распущусь, что тоже начну в конструкторе методы объявлять. Это вы свободный человек, а меня за такой код из всех моих галер выкинут(
Я тоже знавал таких разрабов, ярых противников TS. Очень горды тем, что пишут на том самом js. Очень горды тем, что им типы нафиг не нужны. И обычно они работают одни, пилят прототипы, которые не будут поддерживать никто, либо пилят свои проекты в одиночку, потому что уровень велосипедства там такой, что никто больше не разберётся. Не все, конечно, но большинство такие.
Самое смешное, они реально думают, что тайпскриптеры целыми днями сидят и типы свои пишут, вместо работы. Напоминают пожилых людей, которые не разбираются в компухтерах и ругают айтишников в духе "кнопки свои нажимает, штаны просиживает, лучше бы делом занялся".
идиотами которые не могут отдебажить элементарные вещи
Ну я тоже) Я отвечал мистеру @flancer, который как бы доверяет себе и партнёру, но типы всё-равно везде ставит, просто в менее удобном и менее мощном виде.
Вот вам пример кода от адепта типов в JsDoc. В тайпскрипте строчек будет поменьше, если вас так пугает количество букв. Как минимум,/** @type { заменяется на : .
TS не даст скомпилироваться некорректному коду. Когда вся кодовая база на нём надо очень постараться, чтобы скомпилировать код с ошибками. На этом шаге надо призадуматься, а точно ли оно надо? Что нужно сделать, чтобы запустить ломаный код с JSDoc? node index.js и всё.
JSDoc'и лишь помогают IDE помогать вам ориентироваться в вашем коде
А TS позволяет описывать контракты и всякие иварианты. Что позволяет сузить количество проблемных мест.
после проверки на наличие ключа TS должен бы вывести A & { y: unknown }
В этом месте не будет выведения типа, а только сужение из уже имеющегося множества. Изначально у нас тип param равен A | B , так что в дальнейшем он не может вывести в другой тип
Там нежданчик не в месте проверки и вывода типа param , а в месте вызова функции. Странно то, что можно в функцию передать obj, потому что он не соответствует типу A | B, который принимает функция. Тип у obj выводится компилятором как { x: number, y: null }, но функция принимает либо { x: number }, либо { x: number, y: number } . Там на месте y может быть любой тип, и функция всё-равно его схавает. А ты вроде как ждёшь только A или B, в котором y будет number.
Всё-таки важно. Она должна быть удобной (чтобы ты ей пользовался, а не избегал) и обязательной (иначе в один момент просто забудешь запускать проверки).
Создавать модуль, создавать типы с которыми он работает
Так я рефакторю typescript-проект, у меня типы уже есть.
создавать новые интерфейсы для методов, если параметры поменяются
Это не так работает. Меняются параметры функции -> тайпскрипт выводит сигнатуру этой функции -> автоматом проверяет, все ли использования этой функции корректны. Если я где-то забыл перейти на новую сигнатуру у меня просто выскочит ошибка с указанием места.
Теперь перейдём в мир js. Что там будет, если поменять сигнатуру функции? Да ничего, если вы забудете где-то поменять параметры, то об этом узнаете только в рантайме. Повезёт, если сразу станет понятно проблемное место.
Если же меняется структура данных, которыми манипулирует функция, т.е. интерфейсы, то их поправить занимает не так много времени. При этом опять же, тс сразу покажет, где эти типы используются и
Где тут ускорение рефакторинга ?
Рефакторинг - это не только изменение кода, но и проверка на корректность. Изменение кода обычно быстрее, так как я сразу вижу всё что нужно исправить. Проверка тоже быстрее, потому что часть глупых ошибок, типа "забыл изменить имя поля, забыл добавить второй параметр в функцию, опечатался в названии" просто исчезают навсегда. Пример я приводил - поменять поле name в одной структуре, не трогая другую. Простым поиском и заменой тут дело не решишь. Могу ещё примеров накидать
Противники типизации никак не могут понять, что они тоже в конечном итоге работают с типами, потому что данные, которыми манипулируют не рандомные, а имеют какую-то структуру. Только вот типы у них "вылазят" в самый последний момент, когда их уже используют. Но из-за динамичности языка где-то на пути от, условно получения из апи до вывода на экран, какие-то типы могут быть неправильно преобразованы или использованы. Тайпскрипт просто позволяет выявить это раньше, до запуска.
Это как писать программу по ТЗ. JS - это устные договорённости, которые все забывают или искажают, неверно интерпретируют (потому что описано размыто). Поэтому нужный результат долго получается - слишком много доделок. TS - это нормальное ТЗ записанное в условном конфлюенсе, где всё оговорено, где пограничные случаи описаны, так что ты просто читаешь и пишешь. Мне вот по второму способу удобнее и быстрее работать.
Но раст ведь можно выбирать не только из-за работы с памятью и отсутствию gc. Лично мне он приятен очень хорошей инфраструктурой, простым стартом и нормальной системой типов. Просто приятный язык, который даёт хорошие гарантии для твоего кода. А память и производительность только приятный довесок.
Ну то есть проблема таки есть, просто отлавливается внешними силами, а не самим компилятором
Дважды память не освобождают, ссылки у них всегда валидные, буферы не переполняются. Жаль, что они только в комментариях на хабре встречаются.
Это что, вон в хаскеле вообще нет изменяемых переменных в обычном виде. Там для того чтобы завести изменяемое значение люди целые монады городят! Ну тупыыые.
Опять "ведущие эксперты" просто пересказали оф. доки
А разве уже решили проблему того, что 2 метода измерения дают разные результаты для этой постоянной, которые несколько несовместимы между собой?
А что будет, когда отключится интернет? Notion уже может в офлайне работать?
Можно структурировать, больше визуала, больше возможности разметки, можно ссылаться на что-то. Сам веду заметки в Obsidian.
Ну вы обобщаете, про идиотов, сроки и дебаг, я вот тоже обобщаю. Я говорил про конкретную касту "отрицальщиков типов", с которыми я лично работал. Они обычно гордятся своим незнанием, любят делать запутанные штуки, используют динамические возможности JS во зло, скажем так. При этом есть огромная куча хороших проектов на чистом JS, которые понятны и хорошо работают.
Конечно можно верить во всемирный заговор Microsoft по созданию TS, как инструмента для затягивания сроков и увеличения бюджетов. А можно задуматься, а почему с TS у вас код даже работает хуже, хотя по-факту это надмножество языка. TS создавался с целью помочь программистам. Если же вы с ним боретесь, то вероятно надо повысить экспертизу в команде, например. Know your instrument, как говорится. Причем, в отличие от других языков, тут можно задавать уровень точности компилятора, и в случае затруднений точечно избегать типизации. Можно обходиться только простыми интерфейсами, без дженериков и всяких advaced types, чисто для дополнительной помощи в IDE. А можно проинвестировать в знания и фигачить всё на максималках, с большим трудом, но и с большими гарантиями и большим профитом по итогу.
В конце концов, я предпочту, чтобы за меня всякой рутиной по проверке корректности данных занимались проклятые роботы, а я уж логику буду писать и тестировать именно её, а не писать тесты на то чтобы в функцию какую-то фигню не передали.
Я просто боюсь, что так сильно распущусь, что тоже начну в конструкторе методы объявлять. Это вы свободный человек, а меня за такой код из всех моих галер выкинут(
Я тоже знавал таких разрабов, ярых противников TS. Очень горды тем, что пишут на том самом js. Очень горды тем, что им типы нафиг не нужны. И обычно они работают одни, пилят прототипы, которые не будут поддерживать никто, либо пилят свои проекты в одиночку, потому что уровень велосипедства там такой, что никто больше не разберётся. Не все, конечно, но большинство такие.
Самое смешное, они реально думают, что тайпскриптеры целыми днями сидят и типы свои пишут, вместо работы. Напоминают пожилых людей, которые не разбираются в компухтерах и ругают айтишников в духе "кнопки свои нажимает, штаны просиживает, лучше бы делом занялся".
Высокомерный мем внутри
Ну я тоже) Я отвечал мистеру @flancer, который как бы доверяет себе и партнёру, но типы всё-равно везде ставит, просто в менее удобном и менее мощном виде.
Я понял, вы просто сразу пишете программы без ошибок. Всем бы так
Вот вам пример кода от адепта типов в JsDoc. В тайпскрипте строчек будет поменьше, если вас так пугает количество букв. Как минимум,
/** @type {
заменяется на:
.TS не даст скомпилироваться некорректному коду. Когда вся кодовая база на нём надо очень постараться, чтобы скомпилировать код с ошибками. На этом шаге надо призадуматься, а точно ли оно надо? Что нужно сделать, чтобы запустить ломаный код с JSDoc?
node index.js
и всё.А TS позволяет описывать контракты и всякие иварианты. Что позволяет сузить количество проблемных мест.
В этом месте не будет выведения типа, а только сужение из уже имеющегося множества. Изначально у нас тип
param
равенA | B
, так что в дальнейшем он не может вывести в другой типТам нежданчик не в месте проверки и вывода типа
param
, а в месте вызова функции. Странно то, что можно в функцию передатьobj
, потому что он не соответствует типуA | B
, который принимает функция. Тип у obj выводится компилятором как{ x: number, y: null }
, но функция принимает либо{ x: number }
, либо{ x: number, y: number }
. Там на местеy
может быть любой тип, и функция всё-равно его схавает. А ты вроде как ждёшь только A или B, в которомy
будетnumber
.Всё-таки важно. Она должна быть удобной (чтобы ты ей пользовался, а не избегал) и обязательной (иначе в один момент просто забудешь запускать проверки).
Так я рефакторю typescript-проект, у меня типы уже есть.
Это не так работает. Меняются параметры функции -> тайпскрипт выводит сигнатуру этой функции -> автоматом проверяет, все ли использования этой функции корректны. Если я где-то забыл перейти на новую сигнатуру у меня просто выскочит ошибка с указанием места.
Теперь перейдём в мир js. Что там будет, если поменять сигнатуру функции? Да ничего, если вы забудете где-то поменять параметры, то об этом узнаете только в рантайме. Повезёт, если сразу станет понятно проблемное место.
Если же меняется структура данных, которыми манипулирует функция, т.е. интерфейсы, то их поправить занимает не так много времени. При этом опять же, тс сразу покажет, где эти типы используются и
Рефакторинг - это не только изменение кода, но и проверка на корректность. Изменение кода обычно быстрее, так как я сразу вижу всё что нужно исправить. Проверка тоже быстрее, потому что часть глупых ошибок, типа "забыл изменить имя поля, забыл добавить второй параметр в функцию, опечатался в названии" просто исчезают навсегда. Пример я приводил - поменять поле name в одной структуре, не трогая другую. Простым поиском и заменой тут дело не решишь. Могу ещё примеров накидать
Противники типизации никак не могут понять, что они тоже в конечном итоге работают с типами, потому что данные, которыми манипулируют не рандомные, а имеют какую-то структуру. Только вот типы у них "вылазят" в самый последний момент, когда их уже используют. Но из-за динамичности языка где-то на пути от, условно получения из апи до вывода на экран, какие-то типы могут быть неправильно преобразованы или использованы. Тайпскрипт просто позволяет выявить это раньше, до запуска.
Это как писать программу по ТЗ. JS - это устные договорённости, которые все забывают или искажают, неверно интерпретируют (потому что описано размыто). Поэтому нужный результат долго получается - слишком много доделок. TS - это нормальное ТЗ записанное в условном конфлюенсе, где всё оговорено, где пограничные случаи описаны, так что ты просто читаешь и пишешь. Мне вот по второму способу удобнее и быстрее работать.
То есть фактически без проверок на ошибки, потому что ломаный код всё равно можно запустить.
Можно пример?