Если не Go, то что?

Ну так и я постарше вас

Не ты, а вы. Но даже если ты, то покажит пример библиотеки на го

Дык одно дело переписать, а другое дело написать заново с нескучным обоями. Разные задачи. Я вот ls в alias заменил для интерактивщины, а в скриптах старенький ls, совместимый.

Переписать что-то compliant чтобы усраться но было на Rust - наверное нету смысла дёргаться. А инновации нужно на Rust строчить

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

4.2

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

невероятный бред

поскольку однопоточная жаба работает значительно быстрее

это как?

Камон, хватит выкать, нормально же общались.

Не обращай внимания. Старческий маразм.

Нельзя в го сделать библиотеку и 3 программы которые ей пользуются.

Что, действительно нельзя что ли?

А ты попробуй.

А почему должен? Это статически компилируемый язык, это его фича.

Ну, fasthttp, например — библиотека?

Так причем тут это? К возможности создания библиотек это никак не относится.

А, эт очередной троллинг тупостью в твоём исполнении.

(да, я знаю, что ты не троллишь, просто придерживаюсь хороших манер)

Если очень хочется, то можно. Но зачем библиотеки в 2к19? Все равно в flatpak засовывать.

Так дядя про so говорит, про вот эти вот библиотеки. Тут прямое отношение.

Так что мешает go компилятору сгенерировать .so?

Не ты, а вы.

Пожалуйста: вы бредите.

Потом дочитал что он однопоточный с Global Lock.

А почто тебе многопоточность? Форкайся как диды, да сообщения посылай между процессами.

Rust тут при том, что эти штуки по 20 лет до ума доводили

И довели

на Rust высрали их более мощные и равно-эффективные (а то и быстрее) эквиваленты за месяцы-год

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

Серьезно, написать новый ни с чем не совместимый grep/ps/whatever сегодня не представляет особой сложности, потому что: а) есть на что ориентироваться и б) документации, примеров кода и библиотек на любой случай жизни просто море.

Это как с fish: вроде и выглядит хорошо, но когда руки уже привыкли к «&&/||» проще не пользоваться более красивым инструментом, чем менять привычки. Ну а хипстоте сегодняшней, возможно, и зайдет.

Ну так я все меняю только через alias. В скриптах они по дефолту отключены

И так делай до тех пор, пока не изучишь язык намного лучше.

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

Потом дочитал что он однопоточный с Global Lock.

Спасибо!

Я недавно увидел на нём реализацию qsort в Википедии, впечатлился, и уж было думал начать его учить вместо хаскеля. В жопу, теперь ни его, ни хаскель учить не буду.

Все работает в разы лучше и удобнее.

Нескучные cat и ls? Ты болен или прикалываешься?

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

4.2

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

невероятный бред

Я заметил, что местные энтерпрайз сеньиор эксперты по жабе говорят об изменениях годовой давности в жабе как про «старые», а истоки жабы для них, судя по всему, лежат где-то в 2010-2015 году, когда они закончили школу.

В жабе версии 1.3 еще не было никаких параллельных сборщиков мусора: http://www.reins.altervista.org/java/gc1.3.1.html
В 1.4 появился https://en.wikipedia.org/wiki/Concurrent_mark_sweep_collector
С самого начала были synchronized и volatile, но до версии 1.5, она же 5.0, volatile работало неправильно:
https://www.ibm.com/developerworks/library/j-jtp02244/ - Fixing the Java Memory Model, Part 1
Ну и java.util.concurrent.locks появилось только в 1.5.

Таким образом, можно говорить о том, что до 1.4, вышедшей в 2002 году, многопоточность в жабе была курам на смех, примерно как многопоток в питоне сейчас. Начиная с 1.5, то есть, с 2004 года, можно говорить о серьезной поддержке многопотока - восемь лет с момент релиза 1.0.

поскольку однопоточная жаба работает значительно быстрее

это как?

Здесь я действительно ошибся - я думал, что когда-то существовала истинно однопоточная жаба. А такой не было, по крайней мере на публике.
Дело в том, что многопоточный доступ к объектам, пусть и якобы несинхронизированный для стороннего наблюдателя, на самом деле подразумевает большое число блокировок самых разных внутренних структур. При чем, в случае жабы это именно многочисленные мелкие блокировки, а не какая-то одна большая - так потоки меньше друг другу мешают, но так же происходит общее снижение производительности.
Serial GC до сих пор является самым быстрым сборщиком - это просто еще раз подтверждает, что многочисленные мелкие блокировки обходятся дороже, чем простая общая блокировка: https://blog.gceasy.io/2016/08/15/questioning-status-quo-serial-gc-not-for-se...

примерно как многопоток в питоне сейчас.

Стоп, с java 1.2 полноценные потоки, никакого GIL и зеленых, какой питон?

Я не понял что в Lock такого особенного? Просто помогает избегать вложенных блоков синхронизации.

volatile работало неправильно:
https://www.ibm.com/developerworks/library/j-jtp02244/ - Fixing the Java Memory Model, Part 1

Я не увидел ошибки, там говорится что volatile раньше нельзя было использовать как флаг готовности объекта, потому как состояниях других полей, не помеченные как volatile, могли отличаться от потока к потоку, т.к. изменения non-volatile могут быть не видны всем потокам сразу. А теперь в JMM добавили контракт, что если поток1 пишет в volatile поле, а поток2 читает значение этого поля, то изменениях оставшихся non-voatile полей становятся видимыми для читающего потока. А если поток3 не проверит volatile то у него могут быть не видны последние изменения в non-volatile полях.

В сях таких контрактов нету, там все зависит от железа, и наверное лучше внешние библиотеки использовать для синхронизации. А вот жаба должна исполняться одинаково на разных архитекторах, потому такой контракт и прописали.

P.S. По поводу контракта с volatile я не знал, я кажется прокачал скил для ответа по поводу volatile на интеврью, теперь еще буду про JMM добавлять. Чтож спасибо :)

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

Первый вопрос. Ты можешь пояснить о чем ты говоришь в приведенной цитате? Вот есть у нас T1 аксессает поле P1 на объекте O1 желая его прочитать. T2 у нас отсутствует (однопоточная программа). Что за блокировки у нас тут будут конкретно и сколько мы по твоей оценке теряем в сравнении, например, с аналогичным С кодом?

Второй вопрос. Ты утверждал, что Java в свое время проектировалась якобы как «изначально спроектированы под одно ядро» (что бы это ни значило) и потому якобы «не способны показать роста производительности на нескольких ядрах». Далее ты говоришь о многопоточности в увязке с GC. У меня есть программа program1, она использует 4 ядра и дает результат за 1 секунду. Каким образом и сколько моя программа теряет от того, что Java «изначально спроектированы под одно ядро» и как это связано с GC?

Не, хаскель, Rust и Elm твои друзья

C++?

Нет. Это библиотека исходного кода. Я дично хочу .so файл.

Не понимаю о чем вы.

Стоп, с java 1.2 полноценные потоки, никакого GIL и зеленых, какой питон?

В питоне тоже есть различной хреновости варианты выполнения нескольких потоков - об этом я и писал. Кстати да, спасибо за инфу - действительно, в жабе до 1.2 были зеленые потоки.

Я не понял что в Lock такого особенного? Просто помогает избегать вложенных блоков синхронизации.

А что в нем особенного? Или ты про мое упоминание java.util.concurrent.locks? До этой штуки ты мог явно блокироваться по объекту или по классу, что весьма ограничивает возможности маневров. Это можно охарактеризовать как «неразвитые инструменты многопоточности до 1.5».

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

Эта особенность модификатора volatile, скопированная из C, делала его потрясающе бесполезным.

В сях таких контрактов нету, там все зависит от железа

В Си ты можешь добавить

asm volatile ("" : : : "memory");"

Да вы что. Вы kernel.h тоже статикой линкуете?

в жабе до 1.2 были зеленые потоки.

Там с 1.1 реальные треды. Это 1997 год.

java.util.concurrent.locks? До этой штуки ты мог явно блокироваться по объекту или по классу, что весьма ограничивает возможности маневров. Это можно охарактеризовать как «неразвитые инструменты многопоточности до 1.5».

Что ты хотел сказать тут? Как-то непонятно ты выразился.

> Go слишком куцый. Он только для микросеовисов и сетевых приложений всяких.

Распространённое неверное мнение.

А развенчивания мифов, конечно же, не будет.

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

synchronized wait/notify были первой версии 1996

В 1.1 1997 уже были реальные треды (возможно только под солярис на сановских серверах, потому как на PC это куда менее актуально было в те годы)

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

Он уже в 1997 был нормальным. О чем ты говоришь? В питоне в 2019 нет того, что в джаве в 1997. Я не топлю за джаву. Но как это сравнимо? Где тут «курам на смех»?

В питоне в 2019 нет того, что в джаве в 1997

В корабле 2019 года нет того, что было в самолете 1997 года.

Еще раз. Вы тут что самые умные?

Вот есть у нас T1 аксессает поле P1 на объекте O1 желая его прочитать. T2 у нас отсутствует (однопоточная программа). Что за блокировки у нас тут будут конкретно и сколько мы по твоей оценке теряем в сравнении, например, с аналогичным С кодом?

Если бы у тебя был такой код на Си, то никаких блокировок бы не было. Однако же, JVM - это сильно больше, чем «выполнить разыменование указателей». Грепни сорцы хотспота по MutexLocker: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/archive/tip.tar.bz2
Конечно, добрая половина из блокировок будут в сборщиках мусора.
Оценить, сколько теряется, я не могу, а тесты ты и без меня можешь нагуглить.

https://www.javacodegeeks.com/2015/09/testing-concurrent-applications.html#te... - вот хорошие графики
https://stackoverflow.com/questions/19901915/why-single-thread-is-faster-than...
https://stackoverflow.com/questions/3820647/multithreading-not-faster-than-si...
https://pdfs.semanticscholar.org/dd54/a215131c5eacd997708c5c4612345fe989c7.pdf - Интересное сравнение многопотока с многопроцессом, которые идут почти ноздря в ноздрю.

Ты утверждал, что Java в свое время проектировалась якобы как «изначально спроектированы под одно ядро» (что бы это ни значило) и потому якобы «не способны показать роста производительности на нескольких ядрах»

У жабы есть фундаментальная проблема, которая упомянута в pdf выше, и которая не даст жабе расти вверх с увеличением числа потоков - это наличие единой кучи объектов, обслуживание которой становится дороже с каждым потоком. Этой проблемы не стояло в 90-х годах, но она встает сейчас. Я уже упоминал некоторое время назад работы по этой проблеме, и с тех пор ничего не поменялось:
https://www.cs.kent.ac.uk/pubs/2005/2228/content.pdf - A fast analysis for thread-local garbage collection with dynamic class loading (2005)
https://kar.kent.ac.uk/57582/ - A study of thread-local garbage collection for multi-core systems (2016)

java.util.concurrent.locks? До этой штуки ты мог явно блокироваться по объекту или по классу, что весьма ограничивает возможности маневров. Это можно охарактеризовать как «неразвитые инструменты многопоточности до 1.5».

Что ты хотел сказать тут? Как-то непонятно ты выразился.

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

В 1.1 1997 уже были реальные треды (возможно только под солярис на сановских серверах, потому как на PC это куда менее актуально было в те годы)

Да, ты прав, на солярке уже в 1.1 были родные потоки: https://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqe/

В питоне в 2019 нет того, что в джаве в 1997.

А в джаве в 2019 нет того, что было в питоне в 1997. Языки, действительно, разные, потому сравнивать их сложно. Тем не менее, в питоне есть ограниченные реализация многопоточных вычислений, которые вполне позволяют использовать онный в ИИ/симуляциях и разных научных вычислениях в рамках одного процесса.

Ты хочешь защищить доступ к полю объекта. А можешь защитить только весь объект

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

Object field = new Object();
Object lock = new Object();

public void test() {
    synchronized (lock) {
        field.foobar = foobarbaz;
    }
}

Ты кукаретик похоже просто.

Вот ты писал про жаву: «изначально спроектированы под одно ядро».

Java (1.0), 1996, есть потоки, synchronized keyword. То есть на уровне синтаксиса уже заложено в первой же версии.

К первой же версии Java в 1996 выходит книга Doug Lea «Concurrent Programming in Java.»

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

Ты обыкновенный пустой кукаретик. Это видно уже по тому, что рассуждая про те времена и джаву ты говоришь «ядро». Это выдаёт тебя. Я даже объяснять не хочу. Будет маркером для других.

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

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

Когда ты пишешь код с блокировками, то для исключения дэдлоков нужно выполнять простое правило - в один момент времени должна быть взята только одна группа блокировок, и эта же группа будет всем скопом отпускаться. То есть, должно быть что-то вроде synchronized (lock1, lock2) - но и такая конструкция создает неудобство в достаточно сложной программе. Зато tryLock и прочие позволяют реализовать безопасные блокировки, да еще и с кооперацией для исключения голодания - потому я и пишу, что только с 1.5 в жаве появились серьезные инструменты многопоточности.

Java (1.0), 1996, есть потоки, synchronized keyword. То есть на уровне синтаксиса уже заложено в первой же версии.

Ну в питоне заложены потоки - дальше что? Толку с них нет.

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

Ты не прав. Санки действительно продавали многоПРОЦЕССОРНЫЕ системы, но многопоточная производительность у них была ужасная: https://www.oracle.com/technetwork/systems/opensparc/12-multicore-spracklen-1...
Это железо лучше всего справляется с большим кол-вом процессов, где каждый процесс работает со своими данными.

ls, cat, du, ps
позволяет писать такой крутой софт очень быстро и просто

Постирония? Одобряю.

ls, cat, du, ps позволяет писать такой крутой софт очень быстро и просто

Постирония? Одобряю.

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

ls, cat, du, ps
позволяет писать такой крутой софт очень быстро и просто

Постирония? Одобряю.

Да, это забавно, но мне кажется, что здесь не все осознают ироничность высказывания. Во-первых, сонсольные утилиты переотягощены наследием прошлого века - по мере роста кол-ва софта уже становится неприкольно запоминать аргументы у каждой отдельной утилиты. Во-вторых, сонсольные утилиты выдают уродливый неструктурированный текст, который прокатывал совсем недавно - 20-30 лет назад, но нынче даже небогоугодный PowerShell умеет обрабатывать сложные сущности, что ставит его на уровень интерпретируемых языков, вроде php/python/ruby/vbs.

Ты не прав.

Ты зачесывал что-то про процессоры того времени, про «соответствуют развитию железа». Что мол якобы тогда и джаву делали однопоточную из-за этого.

В реальности же 1996 год (релиза первой версии Java) совпадает с Sun Ultra Enterprise 6000 is a cabinet-housed data center server with up to 30 processors и Sun Workstation Ultra 4000 (Up to 14 UltraSPARC СPUs).

Ты утверждал, что в джаве многопоточность

курам насмех
изначально спроектированы под одно ядро
примерно как многопоток в питоне сейчас
[джаву] c горем пополам удалось распалаллелить, и то в этом результате можно усомниться

В реальности же ее изначально проектировали как многопоточную. О чем свидетельствует synchronized как часть синтаксиса с 1996 версии 1. Кроме того, там нативные треды с 1997 года.

мог явно блокироваться по объекту или по классу, что весьма ограничивает возможности маневров. Это можно охарактеризовать как «неразвитые инструменты многопоточности до 1.5».

Выяснилось, что ты не понимаешь семантики ключевого слова (или конструкции) synchronized.

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

Выяснилось, что ты ошибся

Ты не прав. Санки действительно продавали многоПРОЦЕССОРНЫЕ системы, но многопоточная производительность у них была ужасная

У меня вопрос. Если ты говоришь что «плохая» у сановских машин, ты должен как-то обосновать это. Если 4 или 30-процессорная машина сана была плохая (для пускания на ней жавы). То какая была хорошая? Мне вот самому любопытно, тот же x86 что мог предложить в плане многопроцессорности тогда джаве? PC на с ранней версией NT были бы лучше по-твоему под джаву, как оцениваешь?

--

О, ты уже открыл для себя тот факт что раньше были процессоры, а не «ядра». Оказалось ты мой намек понял.

Ты зачесывал что-то про процессоры того времени, про «соответствуют развитию железа». Что мол якобы тогда и джаву делали однопоточную из-за этого.
В реальности же 1996 год (релиза первой версии Java) совпадает с Sun Ultra Enterprise 6000 is a cabinet-housed data center server with up to 30 processors и Sun Workstation Ultra 4000 (Up to 14 UltraSPARC СPUs).

И в каком месте тут противоречие? Да, Сан делал одноядерные процессоры, и до 2005 года развивал именно одноядерные процессоры.

Выяснилось, что ты не понимаешь семантики ключевого слова (или конструкции) synchronized

Я не скрываю, что я не пишу на жаве. Многие сидящие здесь в курсе - просто не рискуют возразить.

Выяснилось, что ты ошибся

И я это подтвердил - однопоточной жабы никогда не существовало.

Если ты говоришь что «плохая» у сановских машин, ты должен как-то обосновать это. Если 4 или 30-процессорная машина сана была плохая (для пускания на ней жавы). То какая была хорошая? Мне вот самому любопытно, тот же x86 что мог предложить в плане многопроцессорности тогда джаве? PC на с ранней версией NT были бы лучше по-твоему под джаву, как оцениваешь?

Презенташка 1995 года в духе «потоки - зло, не пишите многопоточных приложений»: https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf
Кто автор презентации? John Ousterhout из САН МАЙКРОСИСТЕМ. Человек из Сан пишет, цитирую: «avoid threads wherever possible» - что прямо противоречит бредятине, которую ты мне втираешь про «Сан продвигал многопоточные технологии».
В 90-х многопоточные технологии никто не развивал, под них не делали ни языков, ни железа, и жава была сделана в то время. Потоки в жаве сделаны скорее как маркетинговый ход, вроде «конечно же, вы не будете использовать потоки, но если вдруг у вас возникнет острая необходимость все-таки потоки сделать - у нас есть некоторые базовые примитивы для поддержки онной». Это примерно как продавать вазелин и наушники в супермаркете - человек пойдет в этот супермаркет, потому что там «всё есть», и неважно что выбор мал, что качество низкое.
Менеджер-заказчик в этом плане мало чем отличается от домохозяйки, потому что приходит на рынок, где является не специалистом, а просто мимопотребителем, которому нужно впарить надежные и стабильные технологии, высокую производительность, чуткую поддержку, перспективность, проверенные решения, признанные лидерами бизнеса - и не важно, что за этим кроется vendor-lock, который высосет из тебя последние соки, а если у тебя получится каким-то образом выжить - будет пить кровь еще многие годы.

Забыл упомянуть доки к первым JDK:
https://www.cs.princeton.edu/courses/archive/fall97/cs461/jdkdocs/
https://www.cs.upc.edu/lclsi/Manuales/java1.2/index.html
Здесь видно, что про существование потоков в жаве предпочитают не говорить.

К слову об UltraSPARC - начало разработки многоядерных версий подозрительно совпадает с разработкаой версии жавы 1.5.