Пиар+низкий порог входа

А что тогда не за Dart? Набор or тот же

Dart мёртв же

Dart мёртв же

В нутре Гугла активно юзают

Dart мёртв же

Гуглу об этом расскажи

А то они как раз на нем flutter выпустили тольвот.

А, типа в гугле юзают, значит жив? Ага, конечно.

А что все так за GO заговорили? Чем он подкупает?

Я бы сказал относительной простотой и производительностью

А потом начать перечислять минусы го...

Там даже перегрузки функций нет. Не говоря уже про дженерики.

Это я про го, а не про дарт, если что.

А, типа в гугле юзают, значит жив? Ага, конечно.

Как минимум не мертв

Я бы сказал относительной простотой и производительностью

его можно сравнить с рубями?

его можно сравнить с рубями?

Не в пользу рубей

его можно сравнить с рубями?

Руби сложнее

А потом начать перечислять минусы го...

а можно весь список пожалуста?

C++ со сборщиком мусора.

Как минимум не мертв

Ну я бы поспорил. Например, насколько я знаю, есть всякие банки на загнивающем западе, которые юзают такую древность как COBOL. Можно ли считать на этом основании, что cobol живее всех живых?

C++ со сборщиком мусора.

эм, вроде как в STL "моде" у C++ тоже есть сборщик мусора

C++ со сборщиком мусора.

Это про какой язык?

Так, ладно, чую холивар = ) Короче понял что нужно самому сесть и изучить что такое GO)

Go до C++ как до Китая пешком.

Go до C++ как до Китая пешком.

Ну, мы недалеко от Китая)

Go больше похож на Си. Этакая чуть более прокачанная сишка с gc, горутинами и интерфейсами.

Ну, мы недалеко от Китая)

Но пешком туда не пойдешь

эм, вроде как в STL "моде" у C++ тоже есть сборщик мусора

Чего?

Но пешком туда не пойдешь

Ну, я ходил один раз, но да. Хреново накинул(

Плюсы и го о разном так то. Разные сферы

Начнём с того, что в go есть gc. После этого продолжать глупо.

Чего?

да, фигню сказал. Помню что когда STL используешь, там с памятью по проще работа происходит

там shared_ptr

то есть фактически подсчёт ссылок

но это не GC

+ в расте же Cell/Box/Rc/Arc есть но это ни разу не гц

Go до C++ как до Китая пешком.

а зечем Го ходить до С++, этого убожества для мазохистов?

а зечем Го ходить до С++, этого убожества для мазохистов?

ну я и Го могу спокойно назвать убожеством для мазохистов

а зечем Го ходить до С++, этого убожества для мазохистов?

Го тоже для мазохистов, только у плюсов хоть нож острый

Го тоже для мазохистов, только у плюсов хоть нож острый

+++

ну я и Го могу спокойно назвать убожеством для мазохистов

это стокгольмский синдром у тебя. программисты на Go продуктивнее программистов на C++ раз в 10. только сумасшедшему может понравится конпеляция по пол часа, отсутсвие модулей как таковых и сообщения об ошибках безумного конпелятора на 1000 экранов

Конпелятор?

это стокгольмский синдром у тебя. программисты на Go продуктивнее программистов на C++ раз в 10. только сумасшедшему может понравится конпеляция по пол часа, отсутсвие модулей как таковых и сообщения об ошибках безумного конпелятора на 1000 экранов

а программисты на TS раз в 10 продуктивнее программистов на Go

а программисты на TS раз в 10 продуктивнее программистов на Go

Главное кучу за собой не забывать убирать.

а программисты на TS раз в 10 продуктивнее программистов на Go

в фронте, где Го и близко нет

???

как это типизировать ? function foo () { foo.lala = 123; }

как это типизировать ? function foo () { foo.lala = 123; }

Че

@iyntx тут обсуждали как то

как это типизировать ? function foo () { foo.lala = 123; }

class

как это типизировать ? function foo () { foo.lala = 123; }

type Foo = { (): void; lala?: number; }; const foo: Foo = () => { foo.lala = 1; }

type Foo = { (): void; lala?: number; }; const foo: Foo = () => { foo.lala = 1; }

Норм спасибо

как запретить тайпчекеру выводить общий тип {} в джинериках? То есть я хочу, чтобы f в примере ниже не тайпчекалось, а только f3 function foo<T>(n: number) { return (v: T) => { return Stream.continually(() => v).take(n) } } let f = foo(10)("a") // OK, f: Stream<{}> let f2: Stream<string> = foo(10)("a") // Error: Type {} is not assignable to type 'string' let f3 = foo<string>(10)("a") //OK, f: Stream<string>

как запретить тайпчекеру выводить общий тип {} в джинериках? То есть я хочу, чтобы f в примере ниже не тайпчекалось, а только f3 function foo<T>(n: number) { return (v: T) => { return Stream.continually(() => v).take(n) } } let f = foo(10)("a") // OK, f: Stream<{}> let f2: Stream<string> = foo(10)("a") // Error: Type {} is not assignable to type 'string' let f3 = foo<string>(10)("a") //OK, f: Stream<string>

нашёл ответ: надо по дефолту ставить <T = never>. правда хотелось бы опцию комплиятора function foo<T = never>(n: number) { return <T>(v: T) => { return Stream.continually(() => v).take(n) } }

как запретить тайпчекеру выводить общий тип {} в джинериках? То есть я хочу, чтобы f в примере ниже не тайпчекалось, а только f3 function foo<T>(n: number) { return (v: T) => { return Stream.continually(() => v).take(n) } } let f = foo(10)("a") // OK, f: Stream<{}> let f2: Stream<string> = foo(10)("a") // Error: Type {} is not assignable to type 'string' let f3 = foo<string>(10)("a") //OK, f: Stream<string>

ещё понял, что foo надо определять вот так в моём случае, тогда тип нормально считается function foo(n: number) { return (v: T) => { return Stream.continually(() => v).take(n) } }

Подскажите пожалуйста, почему при вращении имейдж каждый раз накладывается?

потому что ты не очищаешь 2д контекст?

clearRect то нету

Надо определять code coverage. Как лучше делать: запускать транспиленые тесты на выходном js коде или через ts-node тесты запускать?

потому что ты не очищаешь 2д контекст?

Подскажите пожалуйста, как мне это сделать, не снеся при вращении то, что находится под шестерёнкой?

Чуваки такой вопрос. Пишу hoc для реакта, с такой сигнатурой: hoc(ReplacementComponent)(OriginalComponent). Суть в том, что иногда вместо OriginalComponent надо рендерить ReplacementComponent. Соответственно ReplacementComponent должен уметь принимать пропсы от OriginalComponent (но не только их, в общем случае. Пытаюсь так: function hoc<P, R extends P>(ReplacementComponent: React.ComponentClass<R>) { return function hocFactory<T extends React.ComponentClass<P>>(OriginalComponent: T): T { } } Оно работает только если R не шире P, то есть, если например в P есть свойство с типом "a", а в R то же свойство, но с типом "a" | "b", то TS ругается. Кто-нибудь такое решал уже?

Подскажите пожалуйста, как мне это сделать, не снеся при вращении то, что находится под шестерёнкой?

не писать вручную а использовать pixiJS или другую либу для рендеринга а если пишешь вручную то не жаловаться что HTML5 Canvas2d API непонятный. по нему много туториалов и хелпа

?

все равно придется перерисовывать вообще всё

либо использовать несколько канвасов и возлагать на браузер ответственность за composition

все равно придется перерисовывать вообще всё

Я не против перерисовать вообще всё) Просто у меня таких шестерни будет три и они будут вращаться в разные стороны и на данный момент я не совсем понимаю как мне выполнять очистку

полный clearRect, ну и все три перерисовать если нет идей как работать с context2d - надо взять пикси

Надо определять code coverage. Как лучше делать: запускать транспиленые тесты на выходном js коде или через ts-node тесты запускать?

Без разницы, все равно по сорсмапам восстанавливать

Без разницы, все равно по сорсмапам восстанавливать

Может я что-то не так запускал. Просто у меня Istanbul показывал на функцию, которую сгенерил tsc из export * from, а ее никак не протестить

Может я что-то не так запускал. Просто у меня Istanbul показывал на функцию, которую сгенерил tsc из export * from, а ее никак не протестить

Посмотрите nyc, он умеет мапить

https://github.com/istanbuljs/nyc

Посмотрите nyc, он умеет мапить

Ну вот я им и пользовался. Пойду дальше копать его настройки. Спасибо

Ребята из ангуляр тоже Istanbul используют. Можно у них подсмотреть

Всем привет! Использую связку Express + TypeScript + Mongoose и столкнулся с проблемой, что при вызове .find({}) модели не могу получить длину полученого массива

.exec() в конец

а еще у тебя await посеян

as — зло

У промиса нет length

as — зло

+

as — зло

Как зло? В ООП это ведь обычное дело тайп кастинг. Или, например, когда у тебя часть кода из JS импорируется. Или на крайняк типизация в композиции из нескольких хоков у тебя не завелась, то просто делаешь as any as React.ComponentClass<PropTypes>. А вот почему тут as в конце, если можно просто анотировать let user: UserModel[]

Как зло? В ООП это ведь обычное дело тайп кастинг. Или, например, когда у тебя часть кода из JS импорируется. Или на крайняк типизация в композиции из нескольких хоков у тебя не завелась, то просто делаешь as any as React.ComponentClass<PropTypes>. А вот почему тут as в конце, если можно просто анотировать let user: UserModel[]

обычное дело, но зло чем меньше тайпкастов, тем чище архитектура и код

Как зло? В ООП это ведь обычное дело тайп кастинг. Или, например, когда у тебя часть кода из JS импорируется. Или на крайняк типизация в композиции из нескольких хоков у тебя не завелась, то просто делаешь as any as React.ComponentClass<PropTypes>. А вот почему тут as в конце, если можно просто анотировать let user: UserModel[]

если не завелась и ты делаешь as any — это пиздос

обычное дело, но зло чем меньше тайпкастов, тем чище архитектура и код

+

надо было им сделать оператор ASS а не as. При чём именно капсом. Чтобы всем было понятно что кастица всегдачерез жопу

Кастит очень просто - не кастит

Как зло? В ООП это ведь обычное дело тайп кастинг. Или, например, когда у тебя часть кода из JS импорируется. Или на крайняк типизация в композиции из нескольких хоков у тебя не завелась, то просто делаешь as any as React.ComponentClass<PropTypes>. А вот почему тут as в конце, если можно просто анотировать let user: UserModel[]

Правильно as не использовать