а файбер — это кооперативная многозадачность в одном потоке

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

а файбер — это кооперативная многозадачность в одном потоке

Можно сделать пул потоков и бежать файберы на нём

можно, но смысл же не в этом

смысл в том, что файбер — это кооперативная многозадачность с yield, а await/async — это обертка над созданием потоков

опять же, судя по описанию, с C# я никогда дела не имел)

это два подхода к решению одной и той же проблемы или как?

Допустим в Ди нужны await\async или они там будут только оверхэдом?

это два подхода к решению одной и той же проблемы или как?

можно и так сказать

Допустим в Ди нужны await\async или они там будут только оверхэдом?

В принципе, было бы неплохо для написания, например, GUI, приложений. Но мы же все знаем, как обстоят дела с GUI в D ;)

если функция получает await она получается не завершится пока await сам не будет завершен?

foo() { await .... }

https://habrahabr.ru/post/139734/ тут вот рассказывают про await/async

что-то мы в оффтопик уходим)

Да зайди просто в чат сишарпистрв и спрашивай там)

Я вот понял что хешмап в Д не такой уж быстрый и довольно сильно жрет память

По сравнению с обычными линейными случаями

В принципе, было бы неплохо для написания, например, GUI, приложений. Но мы же все знаем, как обстоят дела с GUI в D ;)

?

Как дела с gui в D?

неочень)

неочень)

Ладно, а 'очень' это как?

Потому что что я не читаю про gtk на D это только проще делать

Нет других языков, на которых с gtk лучше чем на D

очень — это когда GUI является либо экосистемой языка, либо есть несколько нативных альтернатив)

очень — это когда GUI является либо экосистемой языка, либо есть несколько нативных альтернатив)

Я бы не стал тянут в экосистему gui

Напоминает Delphy

Что что а gui это библиотека

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

не частью, а экосистемой)

например, частью стандартной библиотеки

например, частью стандартной библиотеки

Ну вот я именно про это

в противном случае приятно было бы иметь набор нативных альтернатив)

в противном случае приятно было бы иметь набор нативных альтернатив)

Нативная есть что? Под gnome на gtk достаточно нативно получается

Под винду на win api бэк должен быть?

не щупал, кстати, мое упущение)

но вообще, конечно, да, было бы приятно, если бы было нечто нативное для D, прозрачно отображающееся на нативный GUI для платформы

но вообще, конечно, да, было бы приятно, если бы было нечто нативное для D, прозрачно отображающееся на нативный GUI для платформы

А зачем?

я так понимаю, DlangUI примерно по такому принципу построен?

я так понимаю, DlangUI примерно по такому принципу построен?

Вроде да

а чтобы тонны зависимостей не таскать

а чтобы тонны зависимостей не таскать

Субъективное понятие 'тонны'

Если они например ставятся одним установщиком?

dlangui какой то дутый ИМХО у Адама вроде была ГУИ либа из двух файлов

в данном конкретном случае оно не субъективное: для написания GUI-приложений под Win или macOS GTK совершенно не обязателен, но в рамках D, если хочется приятного и переносимого, он обязателен)

Весь gtk нужный под win одним 'next->next->next' ставится

ну и зачем он там?)

или зачем он в KDE?)

в данном конкретном случае оно не субъективное: для написания GUI-приложений под Win или macOS GTK совершенно не обязателен, но в рамках D, если хочется приятного и переносимого, он обязателен)

Как и qt во многих случаях

или в LxQT?)

Но ведь даже под самой виндой никто не пользуется чистым winapi

Все мутят обёртки

неужто блин так сложно создать ГУИ либу?

И в итоге то тот же gtk вызывает winapi в конце концов

а у нас получается обертка над оберткой)

неужто блин так сложно создать ГУИ либу?

Да

в чем главная проблема?

в чем главная проблема?

Объем

в плане?

запускаем все это в KDE и получается обертка над оберткой, работающая в обертке)

Очень много писать

в общем, это вопрос религии, и вряд ли мы придем к какому-то мнению)

как я понимаю или самому кнопки рисовать или обертку над системным API ?

запускаем все это в KDE и получается обертка над оберткой, работающая в обертке)

KDE запущеный на win?

в общем, это вопрос религии, и вряд ли мы придем к какому-то мнению)

Если говорить конкретно, то уже надоели жалобы на отсутствие gui... Они есть и самый полный функционал предоставляет gtk, который достаточно хорошо работает под win, на удивление

я не жалуюсь и не говорю, что его нет)

С практической точки зрения 'вам шашечки или ехать?'

ERROR: S client not available

Дела делать можно и в целом приемлемо по удобству

С практической точки зрения 'вам шашечки или ехать?'

с таким подходом и D не нужен, у нас уже есть C++)

дела делать можно и в целом приемлемо по удобству, особенно с последними стандартами)

как я понимаю или самому кнопки рисовать или обертку над системным API ?

В плане написания gui очень много моментов и делать их сейчас уже не зачем

к примеру?

к примеру?

Буфер обмена с окружением drag-n-drop и тд

Много мелочей

При наличии хорошей обёртки теряет смысл

с таким подходом и D не нужен, у нас уже есть C++)

Опять оффтоп?)

Мне кажется высказывание 'с gui дела обстоят туго' имеет подтекст в том, что применимость для написания настольных приложения низкая

Конкретно по D

Я убеждаю в обратном

Применимость D для написания настольных приложений не ниже python

ну, я имел в виду, что какие-то нативные штуки, заточенные под GUI, как в C#, в язык вводить нет смысла, потому что у сообщества нет единого видения этого самого GUI

а async/await, плодящий треды, собственно, только для подобного и пригоден

Применимость D для написания настольных приложений не ниже python

разве что в Python есть чумовой интерактивный дебагер, с которым проще разобраться в чем-то новом)

В компилируемых ЯП возможно такое сделать?

В компилируемых ЯП возможно такое сделать?

Никогда не пользовал это для gui

Применимость D для написания настольных приложений не ниже python

Как бы ни выше.

Сам гуй на Racket предпочитаю ваять ибо родной кросплатформенный фреймворк рулит. Не рулит он разве что по количество доступных виджетов (биндинги не ко всему написаны).

Сам гуй на Racket предпочитаю ваять ибо родной кросплатформенный фреймворк рулит. Не рулит он разве что по количество доступных виджетов (биндинги не ко всему написаны).

Racket это либа для D? Или язык другой?

Racket это либа для D? Или язык другой?

> язык другой Разновидность Схемы. Проектировался под обучение программированию, но вырос в годный язык для практического применения. По бенчмаркам быстрее питона, но тормознее жабы. Есть статически типизированный диалект, Typed Racket. > либа для D В сишные программы без труда встраивается, думаю, встроится и в D.

Скриптовой?

Скриптовой?

Компилируется в байткод, на x86 (если ничего не путаю) байткод частично компилируется в машкод.

Пруфов не могу привести, поэтому прям железно утверждать не стану (надо уточнить).

Хм, а смысл, если они оборачиваются? Или 'по желанию'?

Структуры передаются by value. MS рекомендует не создавать структур более 12 байт.

Хороший коммент: "А перехватив ошибку на месте, ты даже понять не сможешь, насколько она фатальна, потому что вся логика процесса находится наверху. Уровень перехвата ошибок должен быть разным, в зависимости от задачи перехвата. Если это освобождение ресурсов, то внизу. А если с целью логирования или перезапуска, то наверху." Как я понимаю у Rust и Go именно такая проблема?

А какая ошибка бывает нефатальна?

Ошибка она и в африке ошибка, надо ее лечить.

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

Ну так линейный возврат кодов и пробрасывает ошибку в родителя.

Всем привет!