Ладно, я перестал понимать о чем мы спорим)

Я вообще начал спорить о том, что монады с функторами - это фишка ФП, и для языков, в которых это самое ФП особо не распространено (Go как раз один из таких языков, как я понимаю) такие конструкции не приживуться и вообще они лишние.

Но только с определенных ракурсов

Хорошо, trimStart/trimEnd тоже под Stage 2

extended literals вполне логично включить сейчас в свете того, что мы имеем BigInt и встроенный литерал n

Я вообще начал спорить о том, что монады с функторами - это фишка ФП, и для языков, в которых это самое ФП особо не распространено (Go как раз один из таких языков, как я понимаю) такие конструкции не приживуться и вообще они лишние.

Ну вот про то, что будь там генерики, проблемы с ошибками не было бы совсем, потому что определить функцию Аля checkError<T>(f: T => void): (T, Error) => void Не было бы никаких проблем

extended literals вполне логично включить сейчас в свете того, что мы имеем BigInt и встроенный литерал n

Если чето попадает в stage3, то становится приоритетом в реализации. Но всякие важные по мнению команды тс фичи могут заимплементить и раньше. В митинг ноутсах можно смотреть чё они там решают

Не становится

Пока я ничего не видел из новых пропозалов

Если чето попадает в stage3, то становится приоритетом в реализации. Но всякие важные по мнению команды тс фичи могут заимплементить и раньше. В митинг ноутсах можно смотреть чё они там решают

Не всегда

Я говорю, они расслабились

Потому что пару лет как нового не было считай вообще

Я говорю, они расслабились

И правильно сделали, на самом деле

Флоу там уже половину пропозалов реализовал, в тс пока даже в обсуждениях на митингах не особо встречал

И правильно сделали, на самом деле

Да новые фичи вообще не нужны

?‍♂️

Есть же старые

Я говорю, они расслабились

Еще как! Хотят, что бы я WebGL2.d.ts включил в стандартные определения. Но как это сделать хз, учитывая что все WebAPI они генерят из WebIDL от своего Edge

Да новые фичи вообще не нужны

новые фичи нужны, но не нужны радикальные новые фичи

новые фичи нужны, но не нужны радикальные новые фичи

Например?

новые фичи нужны, но не нужны радикальные новые фичи

И я о том же! Зачем новые когда есть старые. Нет радикалам!

типа как ES5 => ES2015 - вот это были серьёзные изменения

и они были нужны

очень нужны

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

Еще как! Хотят, что бы я WebGL2.d.ts включил в стандартные определения. Но как это сделать хз, учитывая что все WebAPI они генерят из WebIDL от своего Edge

Ну определения типов это не так критично)

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

Как дженериков?

Как дженериков?

Дженерики в JS?

Как будто что-то плохое

Js?

ну это слишком толсто

Такой ещё вопрос, у нас есть конструкторы, а деструкторы у нас есть? Как за собой подчищать память?

так, надо срочно ввести malloc/free в js

Такой ещё вопрос, у нас есть конструкторы, а деструкторы у нас есть? Как за собой подчищать память?

GC все подчистит

GC все подчистит

После чатиков отжирающих по 500мб я ему не доверяю

Такой ещё вопрос, у нас есть конструкторы, а деструкторы у нас есть? Как за собой подчищать память?

У нас есть obj = null

У нас есть obj = null

это разве не просто убирает ссылку?

Убирает и говорит GC очистить

Ручное управление памятью только для тех кто её сам выделяет

После чатиков отжирающих по 500мб я ему не доверяю

Если я правильно смотрю на цифры - то таже самая телега у меня ~300мб занимает

Ручное управление памятью только для тех кто её сам выделяет

тоже верно

Такой ещё вопрос, у нас есть конструкторы, а деструкторы у нас есть? Как за собой подчищать память?

деструкторов нет чистить память в жс нельзя

Оке, тогда просто расслаблюсь и буду получать удовольствие

Оке, тогда просто расслаблюсь и буду получать удовольствие

слышал, что некоторые люди так живут

Если я правильно смотрю на цифры - то таже самая телега у меня ~300мб занимает

десктопная или в браузере? Дектопная 150мб ест. Вру, 55мб

Убирает и говорит GC очистить

Говорит подчистить system.gc()

Ну типа если реально хочется покопаться в байтах то ручные TypedArray будут работать как ожидается, вручную выделил — вручную собрал, но сдаётся мне это не то чем бы хотелось заниматься на фронте

После чатиков отжирающих по 500мб я ему не доверяю

Ну GC хоть и спасает от циклических ссылок, но от безмозглого программиста вряд ли. malloc/free только усугубит все это

Ну типа если реально хочется покопаться в байтах то ручные TypedArray будут работать как ожидается, вручную выделил — вручную собрал, но сдаётся мне это не то чем бы хотелось заниматься на фронте

Ну для этого есть asm.js и wasm

Асмжс — это режим который движок выберет если увидит что вы копаетесь с байтами)

Потому что как спека же вроде не взлетело, которая с 'use asm' ещё была; теперь движки определяют годность кода самостоятельно

Нет, это если хочеться самому управлять памятью) Да еще и писать на C/C++/Rust и прочем дерьме ?

Я про это же и говорю

Ой ща Сова стригеррится, ведь Rust "прочим дерьмом" назвали.

десктопная или в браузере? Дектопная 150мб ест. Вру, 55мб

У меня сейчас десктопная 210 и я не знаю прибавлять ли к этому еще 110 из compressed memory или наоборот вычитать

Ой ща Сова стригеррится, ведь Rust "прочим дерьмом" назвали.

Оно не прочее, а особенное

Ой ща Сова стригеррится, ведь Rust "прочим дерьмом" назвали.

Да я сам пишу на Rust и помогаю писать компилятор AssemblyScript. Это стеб=)

Да я сам пишу на Rust и помогаю писать компилятор AssemblyScript. Это стеб=)

О, а что за компилятор AssemblyScript?

rust -> wasm чтоли?

rust -> wasm чтоли?

С тса же вроде

О, а что за компилятор AssemblyScript?

Странно, что ты о нем не слышал, это ведь сабсет typescript: https://github.com/AssemblyScript/assemblyscript

оооооо, шикарно

rust -> wasm чтоли?

нет rust -> wasm из коробки раста

Странно, что ты о нем не слышал, это ведь сабсет typescript: https://github.com/AssemblyScript/assemblyscript

только вот не сабсет

ибо не умеет в number

Да, просто сильно похож

только вот не сабсет

Суперсет сабсета (вообще это больная тема, Даниель до сих пор не знает как это правильно назвать=))

"Inspired by"?)

ибо не умеет в number

type number = f64 и теперь умеет)

type number = f64 и теперь умеет)

лол

Ну отношение к тс как у элексира к руби грубо говоря

@maxgraey или tsserver понимает?

@maxgraey или tsserver понимает?

Не все. Дело в том, что есть некоторые надмножества, которые не совсем совместимы. Например перегрузка операторов: class Vec2 { ... @operator('+') function add(a: Vec2, b: Vec2): Vec2 { return new Vec2(a.x + b.x, a.x + b.y); } } var a = new Vec2(1, 2) var b = new Vec2(2, 4) var c = a + b // <- вот на это будет ругаться, но в AS это валидно В остальном более не менее ок

Ага, понял, спасибо)

А это нельзя решить плагинами к tsserver?

Или смысла нет и у вас просто форк?

Можно, но ts не в приоритете. Если интерестно, можешь написать

Голоперидола этому шизику ударную дозу

Я что-то не так сказал?

Или смысла нет и у вас просто форк?

Это не форк. Парсер написан с нуля. Никаких зависимостей от ts. Только от binaryen. Собственно основная цель - это компиляция в wasm и asm.js. Но можно транспилировать и в js через tsc, для этого есть полифиллы, но не все можно. Как писать совместивый код описано здесь: https://github.com/AssemblyScript/assemblyscript/wiki/Writing-portable-code

Привет ребят. Пришел в TS бувально час назад, поэтому глупый вопрос: какой бест пректис для такого случая?: Есть export interface Config { } - обычный интерфейс конфига аппликухи, в файле config.d.ts И сам конфиг const config: Config = { }; который позже экспортится, в файле config.ts. Собственно вопрос: правильно ли вообще разделять вот так тайпинги и код? Для меня выглядит неестественно, а IDE и компилер не могут найти нужный интерфейс Config в config.ts. Должен ли я вынести эти тайпинги в какой то один, отдельный файл на проект (не либа), или фигачить такое прямо в config.ts и вообще не писать d.ts файлы?

Привет ребят. Пришел в TS бувально час назад, поэтому глупый вопрос: какой бест пректис для такого случая?: Есть export interface Config { } - обычный интерфейс конфига аппликухи, в файле config.d.ts И сам конфиг const config: Config = { }; который позже экспортится, в файле config.ts. Собственно вопрос: правильно ли вообще разделять вот так тайпинги и код? Для меня выглядит неестественно, а IDE и компилер не могут найти нужный интерфейс Config в config.ts. Должен ли я вынести эти тайпинги в какой то один, отдельный файл на проект (не либа), или фигачить такое прямо в config.ts и вообще не писать d.ts файлы?

Не надо так делать

.d.ts для js файлов

Хм, а есть способ сделать const config: Config = {}; return config; в одну строчку?

типа return {} : Config ?

Мне IDE предлагает тупо забить на тип Config, но так не пойдет)

Мне IDE предлагает тупо забить на тип Config, но так не пойдет)

Пометь тип возврата из функции

И все

Спасибо.

так нельзя?)

а так можно

Так ты тут объект сделал

и все таки хочется первый синтаксис