Какова вероятность, что Google заменит Java на Go в Android?

А что тебе другое надо? Не хочешь жабу - тебе уже сказали, что можно и без нее.

А в чём там проблема с многопоточностью? К сожалению, не в курсе ситуации.

Которая не jvm.

Какова вероятность, что Google заменит Java на Go в Android

в течении 10 лет 1E-10, и это верхняя оценка..

google продаёт Android в котором jvm и java, и балуется с Go. Убить продажи ради развлечения? Это фантазия не из реального мира

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

Не хочется думать что постоянные подтормаживания андроидов это не джава... ага ... ;) С этим безобразием надо что-то делать. Но реально го до джавы далековато ещё.

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

Пятый андроед не лагает)

это в стиле - выпустим новую версию и всё заработает, ага...

ерунда, никто в йаве не заставляет пользоваться низкоуровневыми средствами. в java.util.concurrent высокоуровневых классов для чего угодно полно.

для популяризации и продвижения языка

До сих пор их это, вроде, не сильно заботило. Или они таки что-то такое предпринимают?

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

Вот когда столкнешся со всякими legacy проектами - поймешь всю прелесть такой «вермишели». Чужой код читается не сложнее книжки на английском, в отличии от всякого динамического и/или эзотерического г-на.

Пруф? А ну да, откуда бы ему быть...

https://confluence.jetbrains.com/display/CLION/Known issues

То есть претензия к Kotlin только в том, что там многопоточность такая же как в Java?

И где там про 8 гигабайт?

но смущает Java с её нереальным количеством вермишели в коде

use Scala luke.

а вообще Go «уже» работает на Android, дальше будет более тесная интеграция, о замене речи нет, но два языка паралельно нативно вполне могут работать

The most notable new feature in this release is official support for Android. Using the support in the core and the libraries in the golang.org/x/mobile repository, it is now possible to write simple Android apps using only Go code. At this stage, the support libraries are still nascent and under heavy development. Early adopters should expect a bumpy ride, but we welcome the community to get involved.

Заменит? 0

Добавит в сдк? 30

Добавит в ндк? 100

будь единая(ну максимум до 5) архитектура для всех где установлен андроид тогда - 90%, а в текущем состоянии в районе 10%

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

Google не продвигает языки программирования. Google продвигает свой browser, это их бизнес, не языки програмирования.

Golang не был готов для реального использования в больших проектах до версии 1.1 В той версии появился race detector - http://blog.golang.org/race-detector

Golang раскидывает горутины по потокам(threads) ОС. Это среда для возникновения race conditions. Race detector позволяет отслеживать это в «рантайме»(runtime). Идея состоит в написании тестов которые предположительно могут вызвать race conditions, и отслеживание ошибок используя этот race detector. Рутинная исследовательская работа после написания большой программы.

В Ерланг такой проблемы в языке нет, потому что «переменные» в Erlang невозможно изменять. Хотя вроде бы в некотором софте могут быть проблемы такого рода, в db Mnesia, как сообщают.

Говорят что в языке Rust определяют race conditions уже на этапе компиляции. Надо будет посмотреть на язык. Хотя те кто над ним работают всегда напоминают что Rust это «work in progress», о стабильности пока речи нет.

В Go функции высокого порядка(high order functions, anonymous functions, closures), и возможно другие средства которые усложняют работу сборщика мусора. По крайней мере в Node.js так, где часто основная задача нахождение утечек памяти в асинхронном коде который и без утечек разбирать по частям трудно.

В Erlang каждый процесс имеет свой отдельный GC.

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

А разобраться джависту в смешанном проекте на java/kotlin - это вообще пустяковое дело.

Какова вероятность, что Google заменит Java на Go в Android?

В ближайшие 10 лет – 0%.

Например, для популяризации и продвижения языка

Зачем это Google?

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

С Oracle нет проблем.

Продвинувшись в веб-разработке до состояния зарабатывать деньги, решил освоить разработку под Android (про Cordova в курсе), но смущает Java с её нереальным количеством вермишели в коде, простейший хелловорлд в которой выглядит как законченная программа на руби/питоне.

http://www.thejach.com/imgs/lisp_parens.png

про Java можно похожую картинку нарисовать. Кто–то видит вермишель. Кто–то видит суть, а вермишешь мозгом отфильтровывается.

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

Начинай обмазываться. Реальных альтернатив у тебя нет.

В Erlang каждый процесс имеет свой отдельный GC.

да ладно. Три с половиной миллиона GC ?

Мнезия это не более чем приложение, реализованное на самом языке. Это фреймворк над dets/ets. Всё что можно там, можно и в мнезии. Насчёт нарушения иммутабельности первый раз слышу. Изменение определённых сущностей в (d)ets вроде возможно, да.

Erl слишком прост и дёшев, нужно учить emacs - как пугало ;)

да ладно. Три с половиной миллиона GC ?

Да. Только атомы хранятся в отдельном общем пространстве и вообще никогда не подвергаются GC. Сколько создашь, столько их будет в VM всегда, и есть максимально возможное число атомов в виртуальной машине Erlang. Бинарные данные больше определённого размера тоже хранятся в отдельном общем пространстве для виртуальной машины.

А так, у каждого процесса свой GC, что является одной из главных причин почему Erlang хоть медленее некоторых других языков, но держит миллионы соединений при правильной организации взаимодействия легких процессов. Это одно из требований fault tolerance.

Node.js тоже держит миллионы соединений, но не обслуживает их ))) При миллионах соединений, node.js их не закрывает, но в это время в панике работает только GC общая для всей системы, и каждый запрос может обрабатываться 5-10 минут. Зато героически держит. JIT хороший, но он отстраняется от процессора сборщиком мусора.

Хорошие сборщики мусора только у Java(которая «индустриальный стандарт» где программисты расходный материал), Lua(нужно было игровой индустрии), и особенная система управления памятью в Newlisp.

В Mono вроде бы тоже хороший сборщий(sgen) в последних версиях.

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

Fixed.

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

Как в твоей голове.

Как в твоей голове.

Нет, в твоей.

0 что заменят, 0.00001, что будут активно продвигать go параллельно, для NDK, например.

Ни Кен Томпсон, ни Роб Пайк не являются отцами сишки. Кен Томпсон папа скорее unix. Пайк вообще под стол пешком ходил тогда.

Dalvik не является jvm

Насчёт GC per process первый раз слышу. Как-то не логично, кто тогда управляет сборщиками. Главная фича процессов эрла - крайне дешёвая стоимость создания процесса и последующих накладных. Со стороны кажется (или так на самом деле), что если это функциональный иммутабельный, то GC не нужен.

Процесс это чисто пользовательская вещь - там GC не актуален. Поощряется создание и падение процессов.

Например драйвер мускула. Процессу фиолетово что там с мусором, он сам по себе иммутабелен. В мусоре рулит функция, а не процесс. Возможно даже рулит один statement (что тоже является частным случаем функции), хотя особого смысла в пределах функции зачищать нет.

Более того гарантия иммутабельности позволяет VM внутри функции принять решение о выполнении в несколько потоков. После отработки функции все остатки мусора безжалостно «прибиваются» если они конечно есть ;)

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

Если go наберет обороты, то возможно его когда-нибудь начнут позиционировать как основной язык нативной разработки для android(ndk и пр.). Но вероятность этого невелика, т.к. вряд ли это будет позитивно воспринято разработчиками.

#@ять, ты буквоед? Это не jvm толко потому, что она не исполняет джава-байкод, если его предварительно не обработать. В остальном это такая же JVM, в чем, собственно, и заключается контекст ветки.

Крайне мала.

Это не jvm толко потому, что она не исполняет джава-байкод, если его предварительно не обработать. В остальном это такая же JVM, в чем, собственно, и заключается контекст ветки.

Так jvm - это vm, которая исполняет байт-код Java. Что у dalvik от jvm? У них очень разные архитектуры и у них разный байткод.

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

В контексте этого топика это jvm потому, что аббревиатура jvm не является зарегистрированным названием.

Какой смысл ты вкладываешь в «очень разные архитектуры»? Есть много JVM с разными архитектурами.

Но все они соответствуют спецификации. В отличие от. Так что общего-то?

Общего то, что это виртуальные машины, выполняющие программы на Java. Более того, байткод dalvik получается из Java-байткода. И да, dalvik тоже соответствует некой спецификации. Ваш К.О.

Общего то, что это виртуальные машины, выполняющие программы на Java.

Даже JVM не выполняет программы на Java.

Более того, байткод dalvik получается из Java-байткода.

Это всего лишь трансляция.

И да, dalvik тоже соответствует некой спецификации.

Но не спецификации JVM.

Даже JVM не выполняет программы на Java.

Да неужели? А кто же тогда выполняет программы [написанные] на Java? Никто? Программы [написанные] на Java невыполнимы? Про интерпретаторы даже не заикайся.

Это всего лишь трансляция.

Вот именно.

Но не спецификации JVM

Нет спецификации JVM. Есть «The Java® Virtual Machine Specification», в которой аббревиатура JVM даже не используется. Раз ты такой педант в этих вопросах, изволь использовать точное название, и значок ® не забывай.

Много писанины, синхронизации/блокировки, взаимодействие потоков

как там ещё не завезли к тебе FJ ?

Например, для популяризации и продвижения языка

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

очков вероятности

это как вообще???

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

Количество ядер в среднестатистическом андроид девайсе * 10%

А вообще если они пилят 1.* версию сразу в NDK это о чем то да говорит.

Сколько вы дадите очков вероятности из 100?

Вероятность должна находится в интервале от 0.0 до 1.0.

0.001. Покрайней мере пока ничего замену Java на Go не предвещает.

Покрайней мере пока ничего замену Java на Go не предвещает.

Да почему замена то? Запилят Go до уовня ещё одного годного инструмента для АндроЕда :)

PS: Оно кстати уже работает (см. Go 1.4 Release Notes), но это pre-alfa ...

Покрайней мере пока ничего замену Java на Go не предвещает.

Да почему замена то? Запилят Go до уовня ещё одного годного инструмента для АндроЕда :)

Ну так заголовок:

Какова вероятность, что Google заменит Java на Go в Android?