Delphi - он жив вполне, тоже работает замечательно. Большая часть игр с махровейшим с++ выпущена именно под винду.

Кроме Delphi, наверное, и 1С можно вспомнить... Насчёт игр - так если постараться, то и Haskell под виндой можно использовать. Вопрос же в количестве усилий.

Завязывайте с офтопом

Не. Для хаскеля нужно нормальное ide и система пакетов и сборки. Тогда можно будет просто писать код.

Для перехода на чисто-функциональный язык нужно сильно выворачивать мозги, да и изучать специфически функциональные структуры данных вроде zipper'ов и skew binary

одного иде мало

Для перехода на чисто-функциональный язык нужно сильно выворачивать мозги, да и изучать специфически функциональные структуры данных вроде zipper'ов и skew binary

Писал в продакшен - ни разу не использовал ни зиппер, ни skew binary. И даже близко не видел! Про второй вообще не слышал. 😂

А вот линзы сплошь и рядом использовали... По ходу дела мало-мало их освоил.

Думаю как реализовать stateful datagram oriented протокол, без использования tokio-proto, без оверхеда и без кучи комбинаторов футур. Ничего такого не встречалось?

На каждой из сторон будет висеть нечто вроде конечного автомата. А датаграммы поверх чего будут ходить? Сразу udp?

Думаю как реализовать stateful datagram oriented протокол, без использования tokio-proto, без оверхеда и без кучи комбинаторов футур. Ничего такого не встречалось?

На мио сразу пиши, че ты

На каждой из сторон будет висеть нечто вроде конечного автомата. А датаграммы поверх чего будут ходить? Сразу udp?

да, tokio_core::UdpSocket, от core тоже бы надо избавиться

mio... надо будет подумать.

На каждой из сторон будет висеть нечто вроде конечного автомата. А датаграммы поверх чего будут ходить? Сразу udp?

Конечный автомат есть, но для его реализации используется куча комбинаторов, пробрасывающих сокет, буфер и куски состояния между футурами.

Ну сделай одну большую футуру и крути в ней свой стейт

есть кстати крейт, облегчающий написание футурных стейт-машин, ща нагуглю

Так оно сейчас и есть

Зачем комбинаторы, если можно все руками писать 🤔

во, https://docs.rs/state_machine_future/0.1.7/state_machine_future/

во, https://docs.rs/state_machine_future/0.1.7/state_machine_future/

Найс

во, https://docs.rs/state_machine_future/0.1.7/state_machine_future/

интересно, спасибо

Зачем комбинаторы, если можно все руками писать 🤔

А зачем руками писать, если есть комбинаторы? С реализацией poll() не всё так тривиально. Хотя тоже вариант.

А зачем руками писать, если есть комбинаторы? С реализацией poll() не всё так тривиально. Хотя тоже вариант.

По условию задачи

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

Думаю как реализовать stateful datagram oriented протокол, без использования tokio-proto, без оверхеда и без кучи комбинаторов футур. Ничего такого не встречалось?

А почему без Токио прото?

Депрекейтед же

https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e вот поновее стейт

Если кто ещё читает пост - автор не совсем прав насчёт Go GC. Благодаря активному использованию объектов по значению и escape analysis, эффективно получается, что Go использует стек в качестве нулевого поколения. К тому же, стек у горутин лежит в куче. А в GC-кучу получается промоутятся только "убежавшие" объекты. Так что в целом программы на Go (стиль кодирования + компилятор + GC) используют "гипотезу поколений".

Насчёт фрагментации кучи автор тоже неправ - Go аллоцирует объекты в пулах, сгруппированных по размеру объектов.

Насчёт фрагментации кучи автор тоже неправ - Go аллоцирует объекты в пулах, сгруппированных по размеру объектов.

Как и все прочие делают. И более того - объекты же могут быть пермещены по желанию gc

Как и все прочие делают. И более того - объекты же могут быть пермещены по желанию gc

Не все делают. И вроде, у Go не перемещающий GC.

Не все делают. И вроде, у Go не перемещающий GC.

А как в го выглядит разница между стеком и гц? Как переменные отлияить

А как в го выглядит разница между стеком и гц? Как переменные отлияить

Ну, компилятор-то знает где что, соответственно, и рантайм знает. 😊

Ну, компилятор-то знает где что, соответственно, и рантайм знает. 😊

Юзер тоже знает?

В C/C++/Rust (я думаю) разница между стеком и кучей - какой сегмент в какой регистр записали, там и будет.

Та нет, я про синтаксис

Юзер тоже знает?

Это уж кто как, я всех не опрашивал... 😂

В русте Box<T> это куча

Та нет, я про синтаксис

А! В этом смысле - нет. Как в Java/C#.

Но можно догадаться - по значению кладёшь или создаёшь new/make, берёшь указатель и передаёшь куда-то или нет.

А ссылку на стек получить нельзя?

Или как работает это?

Взял ссылку на обьект - объект уходит в гц?

Я к тому, что стек реалоцируемый, и типа указатель на стек будет меняться, не сильно ли много компилятор умеет? Звучит как наебалово

Взял ссылку на обьект - объект уходит в гц?

Да.

Взял ссылку на обьект - объект уходит в гц?

Только если наружу отдал из функции

Escape analysis называется. 😃

^^

Ну, мы тут щас Go разрекламируем - половина чата переметнётся! 😂

Только если наружу отдал из функции

А как работает тогда аналог let x =... let z =&x; ... realloc_stack()

Где будет x

А как работает тогда аналог let x =... let z =&x; ... realloc_stack()

А что делает realloc_stack()? Подозреваю, в Go его просто нет.

наверное вайпает C:\\

А что делает realloc_stack()? Подозреваю, в Go его просто нет.

Ну условный триггер реалоции стека. Типа алокация многих переменных

Ну условный триггер реалоции стека. Типа алокация многих переменных

Так они на стек сверху кладутся - с нижними-то ничего не происходит. В Go growable stacks в куче.

Так они на стек сверху кладутся - с нижними-то ничего не происходит. В Go growable stacks в куче.

Ну так когда он растёт он реалоцируется

Реалокация это не просто увеличить размер, а возможное перемещение стека в другую область

Ну так когда он растёт он реалоцируется

Нет.

Спагетти-стек. 😉

Это как, он состоит из многих частей?

Да.

Я к тому, что стек реалоцируемый, и типа указатель на стек будет меняться, не сильно ли много компилятор умеет? Звучит как наебалово

Доброе утро

Тю, тогда какие проблемы такую херню организовать в Русте в рамках либ корутин?

As far as I know. Может, за минувшие годы чего и поменялось.

Тю, тогда какие проблемы такую херню организовать в Русте в рамках либ корутин?

Отсутствие GC?

Отсутствие GC?

А оно чем мешает?

Эти стеки из кучи тоже нужно собирать время от времени...

Ссылки нужно будет изменить.

Эти стеки из кучи тоже нужно собирать время от времени...

Зачем их собирать? Когда стек поинтер вернулся на предыдущий стек (вложенность уменьшилась) дропается следующая часть стека

Ссылки нужно будет изменить.

Какие?

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

Если запретить передачу ссылок между корутинами - то можно, но, думается, это будет слишком ограничивать как программистов, так и производительность.

Если запретить передачу ссылок между корутинами - то можно, но, думается, это будет слишком ограничивать как программистов, так и производительность.

Окей, ну сейчас у нас треды статик и скопед

Скопед гарантированно живёт меньше чем текущий стек, статик просит замувать объекты внутрь

В расте стек сегментированый? Насколько я знаю, нет.

В расте стек сегментированый? Насколько я знаю, нет.

Ну из коробки нет, я про то, что это можно накрутить поверх текущего раста неким корутин фреймворком

А если он не сегментированый, то увеличить его размер может быть не всегда возможно без перемещения

А если он не сегментированый, то увеличить его размер может быть не всегда возможно без перемещения

Так а в чем проблема добавить сегментирование, вот вопрос

"Уточки памяти" term by @qnikst

А в го вроде от сегментирования отказались Update: нет, не отказались.

Но им можно, у них gc