Го же можно под ведроид?

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

нет доступка к Android API, нет SDK

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

недавно где-то видел про вариант go + react native

недавно где-то видел про вариант go + react native

а как же доступ к API ?

cordova?

cordova?

вот хз, наверное плагины, да

вот хз, наверное плагины, да

не знаю насколько они хорошо поддерживают Android АPI, но если ты из Web то тебе действительно будет легче на HTML5 писать приложение, Go тут совсем не причём, он тут негоден

не знаю насколько они хорошо поддерживают Android АPI, но если ты из Web то тебе действительно будет легче на HTML5 писать приложение, Go тут совсем не причём, он тут негоден

вот типа этого https://github.com/miguelespinoza/react-goku

мы разрабатываем приложение на C++ Qt, отличная среда для GUI приложений, а Go мы используем в бэкэнде для серверной части

мы разрабатываем приложение на C++ Qt, отличная среда для GUI приложений, а Go мы используем в бэкэнде для серверной части

А го вы используете потому что?

Он сокращает время разработки?

в твоём случае это unused variable, это не считается, взгляни на мой вариант: https://play.golang.org/p/5Ay4ObtgkP

в твоем примере уже естественный отбор

Го же можно под ведроид?

gomobile

нет доступка к Android API, нет SDK

не дезинформируй, есть gomobile

В одну сторону

Ибо в другую - адь

1. он прост, когда у тебя команда из более десятка разработчиков и все они разного уровня опыта и знаний то Go действительно наиболее продуктивен, ов нём нет сложных элементов современных языков, нет отвественности за память (memory management), модульность и пакеты 2. он достаточно производительный и не жрёт память как Java 3. на нём легко писатъ конкуррентные системы, когда у тебя на нескольких ядрах разные асинхронные процессы, которые порой пересекаются и т.д. короче concurrent programming

в твоем примере уже естественный отбор

ну я согласен что такое бывает чрезвычайно редко.. я тоже не вижу в этом проблемы, когда программист не имбицил то он не забудет проверить ошибку, но тем не менее, сам язык позволяет undefined behaviour, в C++ если не словить exception то будет просто крах, а тут не крэш а undefined behaviour, это чрезвычайно опасно, например можно неправильные данные, т.е. мусор записать в БД или ещё какую нибудь хрень вернуть просто изза забытой проверки ошибки

не дезинформируй, есть gomobile

возможно тут я не прав конечно, вопрос лишь в надёжности даноого middleware'а, можно ли доверять

по всей видимости эта библиотека экспериментальная ("The Go Mobile project is experimental"), я бы не стал на ней серьёзное решение пилить, лишь разве побаловаться

В go даже int и uint не сравнишь

а зачем сравнивать? компилятор не позволит тебе мешать типы

если не проверишь ошибку — не соберется

Ну вот чего ты обманываешь-то, про _ тактично забыл?

Ну вот чего ты обманываешь-то, про _ тактично забыл?

Ну вот чего ты обманываешь то! Не проверил ошибку - ошибка компилятора. А '_' - это не 'не проверил', а 'специально проигнорировал'.

Ну вот чего ты обманываешь то! Не проверил ошибку - ошибка компилятора. А '_' - это не 'не проверил', а 'специально проигнорировал'.

👍😁

Ну вот чего ты обманываешь то! Не проверил ошибку - ошибка компилятора. А '_' - это не 'не проверил', а 'специально проигнорировал'.

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

Тоже верно.

Похоливарим? https://m.habrahabr.ru/company/wrike/blog/323550/

дарвин и программирование

ты уверен, что стоит это читать?)

врайк конечно хороши, у меня заочный знакомый там работает. но я хз )

Я почитал. Там мало и неочём

ну вот. доверюсь мнению коллеги

А о чем холиварить?

в интернете кто-то не прав

в интернете кто-то не прав

А в чем не прав то?

TL;DR: Следующего большого языка программирования не предвидится Похоже, что дело обстоит именно так. Новых естественных островов, на которых мог бы закрепиться свежий лидер, похоже не планируется, а эксперименты по созданию новых языков не могут побороть инертность индустрии разработки. Пожалуй, это не так уж и плохо.

придумай сам )

Мейнстримные языки с нами всерьез и надолго, и их знание всегда пригодится. При этом, новые языки вроде Rust или Go тоже имеют перспективу, возможно, не как замена всего и вся, но как инструмент для решения интересных задач.

в чем )) в этом и суть холиваров )

Поехали.

да фигня

голанг загнется через пару лет

раст тоже

во фронтенде будет elm

а давно вы вообще свежий язык программирования видели?

в бекенде все те же игроки, типа питона

наркоманы обколятся хаскелом и будут на нём писать. староверы на кложе

jvm маст хев

Мейнстримные языки с нами всерьез и надолго, и их знание всегда пригодится. При этом, новые языки вроде Rust или Go тоже имеют перспективу, возможно, не как замена всего и вся, но как инструмент для решения интересных задач.

ничего не знаю про rust, но go лет больше, чем половине участников чата.

~ 9 лет go, не?

8, судя по вики

нет

ну т.е. чисто формально да

если не учитывать, что это мажорная версия Alef 1992 года

Имхо, Go как ЯП вообще хоть как-то стал попуоярен только последние года три

с докером примерно

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

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

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

Ну не знаю, мне кажется, что успех Go с докером не связан.

Например, от того, что (к примеру) в яндексе будут кодить на js, мне никаким боком (разве что яндекс не будет выкладывать на github написанные по пути либы и багрепортить в апстирим)...

Например, от того, что (к примеру) в яндексе будут кодить на js, мне никаким боком (разве что яндекс не будет выкладывать на github написанные по пути либы и багрепортить в апстирим)...

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

(хотя в случае js не понятно куда дальше)

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

так оно и есть. даже термин есть killer app. тот же руби до бейзкамра и RoR был никому ненужной пародией на перлопитон

Ну не знаю, мне кажется, что успех Go с докером не связан.

ну с чем-то он должен быть связан. как игрушка Пайка в 2009 он не очень зашел - рантайм был сырой и бажный, а предыдущая вермия так и вообще 15 лет пылилась

У меня зашёл когда я о нём начитался на хабре. Кто тамошним авторам проплатил - не знаю 😄

посмотрел я на Swift GCD, самая обычная future библиотека, насколько я понимаю если гоурутину заблокировать runtime автоматически отложет её в сторону и будет выполнять другие гоурутины пока та не проснётся, в GCD такого нет, там если задание на dispatch queue выполняется и делает например syscall или запрос на бд то блокирует основной системный поток на котором исполняется, в это время другой work элемент не может выполняться, бредятина

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

посмотрел я на Swift GCD, самая обычная future библиотека, насколько я понимаю если гоурутину заблокировать runtime автоматически отложет её в сторону и будет выполнять другие гоурутины пока та не проснётся, в GCD такого нет, там если задание на dispatch queue выполняется и делает например syscall или запрос на бд то блокирует основной системный поток на котором исполняется, в это время другой work элемент не может выполняться, бредятина

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

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

когда syscall блокирует горутину golang scheduler переключается на другие гоурутины чтоб не блокировать процессор

когда syscall блокирует горутину golang scheduler переключается на другие гоурутины чтоб не блокировать процессор

и тут не так работает все. шедулер отцепляет этот P-процесс, который выполняется в отдельном системном треде и создает новый системный тред и процесс шедулера

планировщик и его процессы в Go работают поверх обычных системных ниток, ничем работа в этих нитках не отличается от работы в нитках в Swift. сискол блокирует системную нитку хоть тресни и это не меняется нигде

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

если говорить про Swift то там очереди есть serial и concurrent

На самом деле для меня главной причиной, по которой я мало интересуюсь свифтом , это то, что с инструментарием под что-то, кроме макоси, у него швах

так-то язык очень интересный

(хотя руст гораздо привлекательнее, да)

На самом деле для меня главной причиной, по которой я мало интересуюсь свифтом , это то, что с инструментарием под что-то, кроме макоси, у него швах

угу, поэтому я его нигде, кроме IOS/MacOS и не использую

(хотя руст гораздо привлекательнее, да)

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

планировщик и его процессы в Go работают поверх обычных системных ниток, ничем работа в этих нитках не отличается от работы в нитках в Swift. сискол блокирует системную нитку хоть тресни и это не меняется нигде

http://blog.nindalf.com/how-goroutines-work/ Goroutines are cheap and do not cause the thread on which they are multiplexed to block if they are blocked on: network input sleeping channel operations or blocking on primitives in the sync package.

может быть syscall'ы действительно блочат системные потоки, но всё остальноё - нет