и который не будет трансформироваться в js под капотом)

абсолютно фиолетово что во что трансформируется. Главное чтоб работало и есть не просило

возможно изменится сам способ доставки интерфейса

через браузер

и сами браузеры изменятся

умрут или трасформируются

тогда появятся и новые решения под них

i.e приложения в очках виртуальной/дополненной реальности

не забиваете же гвозди лопатой

это почему вдруг?!

i.e приложения в очках виртуальной/дополненной реальности

VR не уйдет дальше ентертаймента, для интерфейсов не годится.

пока не уйдет, через лет 10 уйдет)

а через лет 20 мб и джс умрет

0)0)

пока не уйдет, через лет 10 уйдет)

Ну пока, там есть один фундаментальный косяк - гораздо больше телодвижений чем в случае с контроллерами/клавиатурами и тому подобными тоучами. Грубо говоря попробуй вытянуть руки перед собой, и покрути ими в воздухе - через полчаса такого "взаимодействия с VR" покажется, что лучше таки мышкой

скажите можно каким то образом установить конкретную версию пакета ? не используя glide/dep ? - типо go get github.com/Sirupsen/logrus@1.2.3 ?

не, у меня основной язык ts можно сказать. И примерно треть времени тратится на еблю с webpack-ом и т.п. В общем лучше бы они убили поциента, а не оживляли

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

что ты там делаешь треть времени

ну и если тебе лень то юзай parcel, он с полпинка заводится

интересно, можно ли будет интерфейс прямо в мозг

транслировать

это же все 10101010101

вставил кабель, а потом по вайфай

и стрим пошел

ну юзай парсель, я вот в тс другие проблемы вижу, вроде того что он не умеет Array<T|null> => Array<T> при array.filter(x => x)

интересно, можно ли будет интерфейс прямо в мозг

Вроде работают над этим, но пока только в качестве радара для слепых. Ссылки не припомню. Но увы, проклятый гуманизм тормозит прогресс

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

то есть проблема не в вебпаке конено, он просто инструмент. проблема в том что module resolving в node сделали идиоты, которые в жизни не работали с другими менеджерами пакетов. Но обсуждать эту больную тему здесь я не могу, а то меня опять начнёт бомбить и админ зогбанет

Вы по-юношески категоричны. НЕ ВСЕ шаблонизаторы - зло. Фронтенд на DSL - тот еще костыль, призванный уменьшить количество боли от html + css + js, не более того. Все, что касается фронтенда, отвратительно не только в Го. И оно отвратительно безотносительно вендора. А сама идея писать фронт на Го... Кхм, какие там "ключевые плюшки" в Го? Строгая статическая типизация, многопоточность "искаропки" (все вот эти горутины, каналы и прочее), грамотная стандартная библиотека. Что из этого нужно на фронте? Вот ничего из этого на фронте не нужно, и не надо мучить бабушку с идеей писать гошный фронт.

асинхронный неблокирующий код и многопоточность точно не нужны на фронте? Или вы не работали над фронтом?))

собственно, вам лучше знать. Вы же заявляете, что строгая типизация на фронте нужна.

нужна. Фронт он как и бэк имеет свойство расти и разрабатываться большой командой. Если бы типизация была на фронте не нужна то Microsoft никогда не разработали бы TypeScript который сейчас так популярен

грабля растет из того, что html - это "язык разметки гипертекста", который потом стали обвешивать уймой костылей для того, чтобы он стал похож на "язык реализации интерфейсов"

к сожалению да, для документов подходит, а вот для GUI не очень

асинхронный неблокирующий код и многопоточность точно не нужны на фронте? Или вы не работали над фронтом?))

А многопоточность зачем?

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

у вас проблемы с html, я понял

они у всех, иначе не появились бы такие фреймы как Vue, Angular, React etc.

асинхронный неблокирующий код и многопоточность точно не нужны на фронте? Или вы не работали над фронтом?))

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

вот даже реально, если смотреть в сторону webassembly - нафига именно Го?

а почему не Go?) C++? welcome to hell!

нужна. Фронт он как и бэк имеет свойство расти и разрабатываться большой командой. Если бы типизация была на фронте не нужна то Microsoft никогда не разработали бы TypeScript который сейчас так популярен

я говорил о ненужности СТРОГОЙ типизации, и даже пример накалякал: var a1 int32 = 10 var a2 int64 = 20 a3 := a1 + a2 //ОШИБКА КОМПИЛЯЦИИ Вот это на фронте зачем? А против ЯВНОЙ типизации, и даже СТАТИЧЕСКОЙ типизации, я ничего не имел, вы ко мне несправедливы

а почему не Go?) C++? welcome to hell!

не го - потому что го, в основном, про многопоточность. А она в гуе не нужна

Писать гуй на Го - не более чем анекдот. Язык чуть менее чем полностью непригоден для этого.

<template>Писать гуй на {{language}} - не более чем анекдот.</template>

<template>Писать гуй на {{language}} - не более чем анекдот.</template>

фронтендер детектед!!! Гофер бы написал: Писать гуй на {{ .Language }} - не более, чем анекдот.

и задумывалось оно именно для того

+

Ну во первых нужна нормальная асинхронность, а не горутины. Ещё нужен нормальный параметрический полиморфизм.

чем горутины не "нормальная асихронность"?)))

Ты в аде колбэков потонешь без промисов и async/await. А промисов на го не написать, ибо нужен параметрический полиморфизм. А без промисов не будет и async/await.

зачем тебе промисы в языкк, в котором есть горутины?!?!

Чтобы рисовать гуй многопоточность и правда не нужна.

?

короче ребята, тут какой-то пиздец! Я смотрю тут одни спецы по фронту собрались, я в ужасе от количества бреда)) заканчивайте))

они у всех, иначе не появились бы такие фреймы как Vue, Angular, React etc.

потому html - это не ЯП, а формат сериализации, причём идиотский

пиздец, в гоферском чатике обсуждают хтмл, его в фронтендерских чатиках меньше обсуждают

точнее, его вообще не обсуждают там

ибо вот он есть, и от него никуда не денешься

пиздец, в гоферском чатике обсуждают хтмл, его в фронтендерских чатиках меньше обсуждают

ни фига ты нипонел, вумник, а всё туда же

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

чтоб раз и навсегда: асинхронный код и многопоточный код это 2 парадигмы конкуррентности. асинхронный - более безопасный, но менее гибкий и менее производительный. многопоточный - менее безопасный, но более гибкий и производительный. асинхронный подход старается не блокировать основной поток, перемещая блокирующие операции в event loop. В асинхронном коде обязательно нужны Promises или async/await, иначе заблокируешь основной поток и всё вообще встанет, даже сам гуй. в многопоточности Go же такой вид асинхронности не нужен по причине наличия горутин, в горутине можно запустить блокирующий таск совсем вез event loop'ов, callback'ов, Promise'ов и т.д. просто написать синхронный читабельный код. единственная опастность может возникнуть если не синхронизировать доступ к памяти, которую делят меж собой несколько горутин, что в async программировании в принципе быть не может, там код выполняется в 1 потоке. но если бы многопоточность на фронте была бы не нужна - WebWorkers никогда не появились бы. Она ещё как нужна, просто представьте: мы запрашиваем таблицу данных с сервера и прежде чем её отобразить, её нужно преобразить, а это занимает некое время. Если писать эту трансформацию большого колва данных просто в главном потоке то вероятность велика, что гуй на 50, а может и все 500 мс зависнет и не будет откликаться. На дворе 2018 год, ни кому не нужен microstuttering и freezing на гуях. Без WebWorker'ов пришлось бы писать плагин для event loop'а для своей бизнес логики, чем естественно никто не занимается по очевидным причинам. Теперь WebWorker'ы же используются для вычислений и операций на заднем фоне взаимодействуя с главным кодом event loop'а. Тот кто утверждает что многопоточность на фронте не нужна, скорее всего представляет себе фронт как статичную HTML'у из 90х годов, а не динамичную, анимированную, реактивную, супер сложную штуку 2018го

чтоб раз и навсегда: асинхронный код и многопоточный код это 2 парадигмы конкуррентности. асинхронный - более безопасный, но менее гибкий и менее производительный. многопоточный - менее безопасный, но более гибкий и производительный. асинхронный подход старается не блокировать основной поток, перемещая блокирующие операции в event loop. В асинхронном коде обязательно нужны Promises или async/await, иначе заблокируешь основной поток и всё вообще встанет, даже сам гуй. в многопоточности Go же такой вид асинхронности не нужен по причине наличия горутин, в горутине можно запустить блокирующий таск совсем вез event loop'ов, callback'ов, Promise'ов и т.д. просто написать синхронный читабельный код. единственная опастность может возникнуть если не синхронизировать доступ к памяти, которую делят меж собой несколько горутин, что в async программировании в принципе быть не может, там код выполняется в 1 потоке. но если бы многопоточность на фронте была бы не нужна - WebWorkers никогда не появились бы. Она ещё как нужна, просто представьте: мы запрашиваем таблицу данных с сервера и прежде чем её отобразить, её нужно преобразить, а это занимает некое время. Если писать эту трансформацию большого колва данных просто в главном потоке то вероятность велика, что гуй на 50, а может и все 500 мс зависнет и не будет откликаться. На дворе 2018 год, ни кому не нужен microstuttering и freezing на гуях. Без WebWorker'ов пришлось бы писать плагин для event loop'а для своей бизнес логики, чем естественно никто не занимается по очевидным причинам. Теперь WebWorker'ы же используются для вычислений и операций на заднем фоне взаимодействуя с главным кодом event loop'а. Тот кто утверждает что многопоточность на фронте не нужна, скорее всего представляет себе фронт как статичную HTML'у из 90х годов, а не динамичную, анимированную, реактивную, супер сложную штуку 2018го

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

потому html - это не ЯП, а формат сериализации, причём идиотский

эээ, нэт, формат сериализации это вам JSON и XML, а вот HTML это язык разметки гипертекстовых документов.

чтоб раз и навсегда: асинхронный код и многопоточный код это 2 парадигмы конкуррентности. асинхронный - более безопасный, но менее гибкий и менее производительный. многопоточный - менее безопасный, но более гибкий и производительный. асинхронный подход старается не блокировать основной поток, перемещая блокирующие операции в event loop. В асинхронном коде обязательно нужны Promises или async/await, иначе заблокируешь основной поток и всё вообще встанет, даже сам гуй. в многопоточности Go же такой вид асинхронности не нужен по причине наличия горутин, в горутине можно запустить блокирующий таск совсем вез event loop'ов, callback'ов, Promise'ов и т.д. просто написать синхронный читабельный код. единственная опастность может возникнуть если не синхронизировать доступ к памяти, которую делят меж собой несколько горутин, что в async программировании в принципе быть не может, там код выполняется в 1 потоке. но если бы многопоточность на фронте была бы не нужна - WebWorkers никогда не появились бы. Она ещё как нужна, просто представьте: мы запрашиваем таблицу данных с сервера и прежде чем её отобразить, её нужно преобразить, а это занимает некое время. Если писать эту трансформацию большого колва данных просто в главном потоке то вероятность велика, что гуй на 50, а может и все 500 мс зависнет и не будет откликаться. На дворе 2018 год, ни кому не нужен microstuttering и freezing на гуях. Без WebWorker'ов пришлось бы писать плагин для event loop'а для своей бизнес логики, чем естественно никто не занимается по очевидным причинам. Теперь WebWorker'ы же используются для вычислений и операций на заднем фоне взаимодействуя с главным кодом event loop'а. Тот кто утверждает что многопоточность на фронте не нужна, скорее всего представляет себе фронт как статичную HTML'у из 90х годов, а не динамичную, анимированную, реактивную, супер сложную штуку 2018го

теперь смотрите: "асинхронный и многопоточный" код - это "2 разные парадигмы конкуррентности". Прямо вас же и цитирую. А теперь берем случай с фронтом, браузером и большой табличкой и искренне не понимаем, чем вам асинхронность не угодила, зачем тут многопоточность, и как вы ее собираетесь в ограничениях браузера реализовывать (вы же в песочнице с 1 потоком)

эээ, нэт, формат сериализации это вам JSON и XML, а вот HTML это язык разметки гипертекстовых документов.

если веровать в сие, то аминь пусть будет так. но это бессмыслица. json разметка, хтмл ЯП. абсурд

то есть проблема не в вебпаке конено, он просто инструмент. проблема в том что module resolving в node сделали идиоты, которые в жизни не работали с другими менеджерами пакетов. Но обсуждать эту больную тему здесь я не могу, а то меня опять начнёт бомбить и админ зогбанет

Проблема не в вебпаке, а в том, что ты используешь ts. Ты сам подписался на жуткую боль, хватит обсирать инструменты, не предлагая ничего лучше.

потому html - это не ЯП, а формат сериализации, причём идиотский

Чтоооооо ты несёшь

Проблема не в вебпаке, а в том, что ты используешь ts. Ты сам подписался на жуткую боль, хватит обсирать инструменты, не предлагая ничего лучше.

я там написал ниже, что проблема не в вебпаке

потому html - это не ЯП, а формат сериализации, причём идиотский

Ты знал, что ml в html - это markup language?

Ты знал, что ml в html - это markup language?

ой, а что тогда J в джаваскрипте? такая же нелепость

зачем тебе промисы в языкк, в котором есть горутины?!?!

Кстати, было бы удобно в некоторых случаях иметь promise.all()

если веровать в сие, то аминь пусть будет так. но это бессмыслица. json разметка, хтмл ЯП. абсурд

подсказка: ключевое слово - "семантическая разметка". Так что да, html - Язык Разметки Гипертекста (построенный на базе xml)

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

1. асинхр. и многопот. это конкурентные парадигмы, если ты так не считаешь то посоветую тебе по-дружески заняться изучением парадигм написания программного кода чтоб не смешить людей. 2. то что в асинхронном коде не может происходить что либо одновременно, это не более безопасно? Или почему в C++/Java/Go порой нужны Mutex'ы a в JavaScript в принципе не нужны?? не-синхронизированный доступ к памяти может привести к неопределённому поведению (undefined behavior), это в асинх js в принципе не возможно, там всё в 1 потоке, поэтому этот подход "безопаснее" 3. не менее производительный?! да ты что, тролль чтоли?!

ой, а что тогда J в джаваскрипте? такая же нелепость

Да никто не скрывал никогда, что в javascript слово java было только потому, что это было модно

да тролль, тролль он. Я его уже пол-дня кормлю)

Ты знал, что ml в html - это markup language?

Павел Филимоненков это походу троль, ребята

ERROR: S client not available

Павел Филимоненков это походу троль, ребята

Похоже на то

1. асинхр. и многопот. это конкурентные парадигмы, если ты так не считаешь то посоветую тебе по-дружески заняться изучением парадигм написания программного кода чтоб не смешить людей. 2. то что в асинхронном коде не может происходить что либо одновременно, это не более безопасно? Или почему в C++/Java/Go порой нужны Mutex'ы a в JavaScript в принципе не нужны?? не-синхронизированный доступ к памяти может привести к неопределённому поведению (undefined behavior), это в асинх js в принципе не возможно, там всё в 1 потоке, поэтому этот подход "безопаснее" 3. не менее производительный?! да ты что, тролль чтоли?!

"асинхр. и многопот. это конкурентные парадигмы" - кто тебе сказал такое? "то что в асинхронном коде не может происходить что либо одновременно, это не более безопасно?" - это в браузере не может, но асинхронность тут не причём. В C# например может легко ну т.д. фигню несёшь

ой, а что тогда J в джаваскрипте? такая же нелепость

прямо с самого начала говорили, что j в джаваскрипте - "чем-то отдаленно похожий на java"

Павел Филимоненков это походу троль, ребята

по-моему, об этом было известно ещё с конца того года

тем более, что "научное" название у джаваскрипта, вообще-то, ecmascript

теперь смотрите: "асинхронный и многопоточный" код - это "2 разные парадигмы конкуррентности". Прямо вас же и цитирую. А теперь берем случай с фронтом, браузером и большой табличкой и искренне не понимаем, чем вам асинхронность не угодила, зачем тут многопоточность, и как вы ее собираетесь в ограничениях браузера реализовывать (вы же в песочнице с 1 потоком)

тем, что твой "асинхронный" код заблокирует осовной поток своей трансформацией большой таблицы и тем самым повиснет гуй, в этом вся беда асинхронного кода, он однопоточен. Ещё раз повторюсь: именно поэтому появились WebWorkers

Да никто не скрывал никогда, что в javascript слово java было только потому, что это было модно

прально, нутак так же и хтмл. МЛ - потому что модно, не какой-то там json

"асинхр. и многопот. это конкурентные парадигмы" - кто тебе сказал такое? "то что в асинхронном коде не может происходить что либо одновременно, это не более безопасно?" - это в браузере не может, но асинхронность тут не причём. В C# например может легко ну т.д. фигню несёшь

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

прально, нутак так же и хтмл. МЛ - потому что модно, не какой-то там json

неверно, МЛ - "Язык Разметки". За "Язык Программирования" никто не топил. А ЯЗЫК он именно потому, что "семантическая разметка". Фактически, это DSL - domain specific language.

"асинхр. и многопот. это конкурентные парадигмы" - кто тебе сказал такое? "то что в асинхронном коде не может происходить что либо одновременно, это не более безопасно?" - это в браузере не может, но асинхронность тут не причём. В C# например может легко ну т.д. фигню несёшь

если что-то происходит одновременно, то это либо изолированные потоки как WebWorkers, либо многопоточность. "многопоточного асинха" быть не может, либо многопот. либо асинх.

тем, что твой "асинхронный" код заблокирует осовной поток своей трансформацией большой таблицы и тем самым повиснет гуй, в этом вся беда асинхронного кода, он однопоточен. Ещё раз повторюсь: именно поэтому появились WebWorkers

собственно, многопоточный вам тоже таблицу не отдаст, пока не "пересчитает"

собственно, многопоточный вам тоже таблицу не отдаст, пока не "пересчитает"

но гуй не повиснет ? и разница огромная

можно показывать спиннер анимированный, рендерить видео и другие элементы UI в в то время когда таблица трансформируется в отдельном потоке. Иначе же всё это повиснет и не будет откликаться ни на какие клики и интеракции

если что-то происходит одновременно, то это либо изолированные потоки как WebWorkers, либо многопоточность. "многопоточного асинха" быть не может, либо многопот. либо асинх.

у тебя страшная каша в голове. несёшь страшную ахинею. Вот что такое "многопоточного асинха" и к чему ты это рпиплёл - хз.

у тебя страшная каша в голове. несёшь страшную ахинею. Вот что такое "многопоточного асинха" и к чему ты это рпиплёл - хз.

Я могу сказать то же самое в твой адрес.

у тебя страшная каша в голове. несёшь страшную ахинею. Вот что такое "многопоточного асинха" и к чему ты это рпиплёл - хз.

многопоточность асинха это либо потоки Event Loop'а, либо изолированные потоки аля WebWorkers, и всё, извини Паша, но с тобой уже нет желания вести беседу, пустая трата времени

многопоточность асинха это либо потоки Event Loop'а, либо изолированные потоки аля WebWorkers, и всё, извини Паша, но с тобой уже нет желания вести беседу, пустая трата времени

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

@onokonem надо бы сюда хотя бы @banofbot какой-нибудь

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

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

просто представил себе картину маслом: "Асинхронность конкурирует с многопоточностью, бля"

в избранное

можно показывать спиннер анимированный, рендерить видео и другие элементы UI в в то время когда таблица трансформируется в отдельном потоке. Иначе же всё это повиснет и не будет откликаться ни на какие клики и интеракции

собственно, в асинхронном коде вам не запрещается делать ровно то же самое...

разница в том, "что под капотом"

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

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

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

>просто не надо фигню писать эх, сейчас бы учить других, когда сам...

а за *****рики уже бы бан дали....

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

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

собственно, в асинхронном коде вам не запрещается делать ровно то же самое...

если у тебя вучисления происходят в основном потоке то всё встанет, и видео, и спиннер, и клики не будут работать, всё заморозится пока вычисление не завершится. Не надо так писать гуй в 2018м

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

так это не я считаю, чудак ты. это юзер Roman Sharkov так считает