ребята, как в ts описать что должна возвращать arrow function?

1. Программы на Go отлично масштабируются на все ядра процессора, в отличие от однопоточного nodejs. При этом не нужно извращаться с shared memory при взаимодействии между процессами nodejs, ведь в Go достаточно одного процесса, чтобы загрузить работой все ядра CPU. 2. Веб-сервер на Go отлично справляется с миллионом одновременных клиентских подключений, где каждое подключение обрабатывается отдельным потоком. Т.е. под Go не нужно извращаться с асинхронностью, калбэками, промисами, async / await и т.п. костылями при обращении к файлам и внешним сервисам типа базы данных, key-value storage/cache или самописным микросервисам — достаточно обычного простого и понятного синхронного кода. 3. Программы на Go работают быстрее программ на nodejs. См. techempower benchmarks. 4. Программы на Go содержат меньше багов, т.к. простой синхронный код легче дебажить, поддерживать и расширять, чем закрученный асинхронный. 5. Код на гоу написан в едином стиле благодаря go fmt, поэтому его легко читать и править. Благодаря этому в среде go-разработчиков отсутствуют споры о правильной расстановке скобок, табов и пробелов. 6. Программа на гоу компилируется в один исполняемый файл, который не нуждается ни в каких дополнительных зависимостях, в т.ч. не нужна и установка Go на серверы, где будет работать программа. Поэтому деплой и обновление программ на Go представляет из себя заливку новой версии бинарника и его перезапуск. Не нужно никаких докеров и никакой специальной подготовки окружения. При выходе новой версии гоу достаточно просто перекомпилировать программы новой версией компилятора и перезалить их в прод. Сравните это с апгрейдом nodejs. 7. .... 8. PROFIT!!!

1. Программы на Go отлично масштабируются на все ядра процессора, в отличие от однопоточного nodejs. При этом не нужно извращаться с shared memory при взаимодействии между процессами nodejs, ведь в Go достаточно одного процесса, чтобы загрузить работой все ядра CPU. 2. Веб-сервер на Go отлично справляется с миллионом одновременных клиентских подключений, где каждое подключение обрабатывается отдельным потоком. Т.е. под Go не нужно извращаться с асинхронностью, калбэками, промисами, async / await и т.п. костылями при обращении к файлам и внешним сервисам типа базы данных, key-value storage/cache или самописным микросервисам — достаточно обычного простого и понятного синхронного кода. 3. Программы на Go работают быстрее программ на nodejs. См. techempower benchmarks. 4. Программы на Go содержат меньше багов, т.к. простой синхронный код легче дебажить, поддерживать и расширять, чем закрученный асинхронный. 5. Код на гоу написан в едином стиле благодаря go fmt, поэтому его легко читать и править. Благодаря этому в среде go-разработчиков отсутствуют споры о правильной расстановке скобок, табов и пробелов. 6. Программа на гоу компилируется в один исполняемый файл, который не нуждается ни в каких дополнительных зависимостях, в т.ч. не нужна и установка Go на серверы, где будет работать программа. Поэтому деплой и обновление программ на Go представляет из себя заливку новой версии бинарника и его перезапуск. Не нужно никаких докеров и никакой специальной подготовки окружения. При выходе новой версии гоу достаточно просто перекомпилировать программы новой версией компилятора и перезалить их в прод. Сравните это с апгрейдом nodejs. 7. .... 8. PROFIT!!!

1. Программы на Go отлично масштабируются на все ядра процессора, в отличие от однопоточного nodejs. При этом не нужно извращаться с shared memory при взаимодействии между процессами nodejs, ведь в Go достаточно одного процесса, чтобы загрузить работой все ядра CPU. 2. Веб-сервер на Go отлично справляется с миллионом одновременных клиентских подключений, где каждое подключение обрабатывается отдельным потоком. Т.е. под Go не нужно извращаться с асинхронностью, калбэками, промисами, async / await и т.п. костылями при обращении к файлам и внешним сервисам типа базы данных, key-value storage/cache или самописным микросервисам — достаточно обычного простого и понятного синхронного кода. 3. Программы на Go работают быстрее программ на nodejs. См. techempower benchmarks. 4. Программы на Go содержат меньше багов, т.к. простой синхронный код легче дебажить, поддерживать и расширять, чем закрученный асинхронный. 5. Код на гоу написан в едином стиле благодаря go fmt, поэтому его легко читать и править. Благодаря этому в среде go-разработчиков отсутствуют споры о правильной расстановке скобок, табов и пробелов. 6. Программа на гоу компилируется в один исполняемый файл, который не нуждается ни в каких дополнительных зависимостях, в т.ч. не нужна и установка Go на серверы, где будет работать программа. Поэтому деплой и обновление программ на Go представляет из себя заливку новой версии бинарника и его перезапуск. Не нужно никаких докеров и никакой специальной подготовки окружения. При выходе новой версии гоу достаточно просто перекомпилировать программы новой версией компилятора и перезалить их в прод. Сравните это с апгрейдом nodejs. 7. .... 8. PROFIT!!!

создай канал как про пхп

не, ну вот риально, есть кто-то здесь, кто может внятно на техническом русском языке объяснить логику - нахуя коннектица к базе в промисе?

@why_php_is_bad

- синтаксис - пакеты - модульная система - наличие пакетов - управление пробрасыванием ошибок - система типов ……

Синтаксис и система типов нормальные же. Обработка ошибок и в ноде есть, просто по рукам тебя не бьют.

а что в parse? (сигнатура какая)

синтаксис говнина: методы на структурке через звездочки система типов ещё хуже: номинальной типизации нет, дженериков нет система ошибок через иф?

ну типо принимает string, возвращает массив Tokens[], а Tokens это string | Key

Чем тебе система типов не нравится?

для фильтра поставь сигнатуру ...): token is Key => ...

Чем тебе система типов не нравится?

я бы мог продолжить копипастить ответ оттуда же откуда и эта паста, но не буду

ну точней ему нужно возвращать boolean

не совсем, почитай тайпинги точнее можно и булеан

Бля, я знал, что это не он написал

обычно фанатики го/тс/любого языка не могут сами что-то писать

А откуда тогда все эти либы и вообще весь софт ?

пишут не фанатики

у меня вопросы насчет подхода. У меня есть функция внутри которой используется обьект(интефейс) Config, в нем все поля обязательные, но для юзера хочу сделать поля не обязательными, поэтому сделал функцию которая возвращает config с базовыми настройками и сделал обьект для юзера UserConfig в котором все поля не обязательные. И такая же ситуация с Context обьектом, в котором до определенного действия нету свойства Response, а потом есть. Поэтому я сделал тоже 2 интерфейса. Есть способ по проще или я вообще подхожу не правильно?

Partial ?

Partial<Config>

где это описано? Поиска в доке нет

Привет, всем! Парни, кто-нибудь, работал с транзакциями в TypeORM? Непонятно что делать с уровнем изолированности транзакции. Выходит так, что когда транзакции выполняются параллельно, и делают одну и туже задачу. То другая транзакция получает не актуальные данные. И с этого может вылезти много не приятных багов.

а смысл

Доброго времени суток, возможно ли в тайпскрипте указать сигнатуру функции в которой один и тот же параметр может иметь разные имена?

типа: func([x|width]: number) :void { ... }

если параметр имеет разные имена это разные параметры

@sergeysova вообще, что думаешь о "универсальных" классах/компонентах?

Это когда класс делает много разного

нарушает SOLID же

нарушает SOLID же

Солид ужас

А что лучше?

На равняться на петтерны

Ну это не, они ж не просто так придуманы. Просто нужно знать какой паттерн какую проблему решает и использовать тот что нужен

>они ж не просто так придуманы Просто так

На равняться на петтерны

На равняться на петтерны

Пиши как пишется, хуяк хуяк в прод

Пиши как пишется, хуяк хуяк в прод

Пиши как пишется, хуяк хуяк в прод

решаю бизнесс задачи как хочу, законом не запрещено