Здравствуйте, LaptevVV, Вы писали:

N>>А вот куда _вам_ надо чтобы он ехал — я не знаю. Может, как раз в сторону такого копипастинга?
LVV>Мы копипасту в своей обучающей среде извели как класс.

За счёт чего?

LVV>Отсутствие копипасты мгновенно стимулирует студентов писать функции.
LVV>Но переходя к С++ они тут же "влезают обратно на пальму" копипасты...

Вы им запретили функции?

Здравствуйте, VladiCh, Вы писали:

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

А вы видели, _во что_ он компилируемый? )

Вот например небольшой кусочек выходного бинаря:

  48fcd7:       48 8b 05 a2 38 0d 00    mov    0xd38a2(%rip),%rax        # 563580 <os.Args>
  48fcde:       48 83 3d a2 38 0d 00    cmpq   $0x2,0xd38a2(%rip)        # 563588 <os.Args+0x8>
  48fce5:       02 
  48fce6:       0f 8c 2b 03 00 00       jl     490017 <main.main+0x377>
  48fcec:       48 8b 48 18             mov    0x18(%rax),%rcx
  48fcf0:       48 8b 40 10             mov    0x10(%rax),%rax
  48fcf4:       48 89 04 24             mov    %rax,(%rsp)
  48fcf8:       48 89 4c 24 08          mov    %rcx,0x8(%rsp)
  48fcfd:       48 c7 44 24 10 00 00    movq   $0x0,0x10(%rsp)
  48fd04:       00 00 
  48fd06:       48 c7 44 24 18 20 00    movq   $0x20,0x18(%rsp)
  48fd0d:       00 00 
  48fd0f:       e8 5c e3 fc ff          callq  45e070 <strconv.ParseInt>
  48fd14:       48 8b 44 24 20          mov    0x20(%rsp),%rax
  48fd19:       48 89 44 24 60          mov    %rax,0x60(%rsp)
  48fd1e:       90                      nop

Это соответствует исходной строке: tt, _ := strconv.ParseInt(os.Args[1], 0, 32).

ec...06: скопировали локальные переменные в стек, потому что функция берёт аргументы только из стека.
14...1e: скопировали результаты из стека (да, в Go результаты тоже на стеке, не в регистрах) в локальные переменные (точнее, одна — tt).
Потом эти значения снова вытащат со стека и будут использовать. Оптимизация работает только в пределах одного предложения, но не между ними. В результате сплошные перегонки через память (обычно через L1 кэш, но есть нюансы, и это всё равно нагрузка на интерфейс связи процессор — память).

А теперь сравниваем с тут и думаем, почему умные опытные люди постарались максимум навесить на регистры (даже там, где это чревато слегка боком, как с переменными аргументами), а тут — седая древность, если не больше.

Вишенка на торте: откуда финальный nop? Это не выравнивание, как покажется тем, кто видел выходной ассемблер какого-нибудь GCC. Это осталось потому, что я err не присваивал, а кодогенератор где-то по дороге потерял возможность сэкономить.

Качество и скорость выходного кода примерно соответствует GCC, Clang без оптимизации совсем (-O0) — ну разве что чуть лучше потому, что у этих двух ещё SSA добавляет странные копирования, когда они ещё не изведены.

Весь выходной код Go именно такой. Не верите — поставьте docker и напустите хоть `objdump -d`, хоть что вам удобнее. Это чтобы не надо было самому что-то собирать.

Так вот — выхлоп JIT в Java нормально оптимизирован, в отличие от, и работает в разы быстрее. Это даже не вспоминая решения типа "у нас тут единственный подкласс в реальности, поэтому меняем вызовы виртуальной функции по указателю на прямой вызов" (в Go тут были бы аналогичные поиски в свойствах класса, соответствующего интерфейсу).
Торможения идут только на прогрев — поэтому там, где важна скорость работы с самого старта, этот прогрев делается искусственно.

И — процессоры сейчас рассчитываются как раз под код, который хоть как-то оптимизирован (на уровне хотя бы -O1 для GCC) и старается не всё гонять через память. Go не соответствует этим шаблонам и соответственно ещё хуже выполняется.

VC> и рандомного времени ответа.

Прогрев, однако. Причём чем дальше, тем меньше тормозит на этом прогреве.

VC>С AOT это как-то решается (для небольших приложений), но из того что я слышал возникают другие проблемы, уже с большими приложениями.

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

LVV>>Отсутствие копипасты мгновенно стимулирует студентов писать функции.
LVV>>Но переходя к С++ они тут же "влезают обратно на пальму" копипасты...
N>Вы им запретили функции?
Нет.
С большинства просто мгновенно слезает флер "цивилизации"...
Но отдельные личности все-таки становятся более "цивилизованными"...

Здравствуйте, vsb, Вы писали:

vsb>Но язык это ерунда.
vsb>Go лучше, тем, что:
vsb>1. Не требует IDE для разработки. vscode хватает за глаза.

На таком уровне и Java не требует.

vsb>2. У него легче рантайм. У жавы накладные расходы на хелло-ворлд примерно 50 MB. У go — единицы мегабайтов.

Из этих 50MB почти ничего не грузится, если не позвать.
А вот нахрена Go эти единицы мегабайтов на Hello World — непонятно.
Похоже, просто не захотели подумать соптимизировать.

vsb>3. Самое главное: в Java кошмарное коммьюнити. Первое, что делает любой жавист, это тянет в проект спринг бут, который сходу делает проект отстойным.

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

vsb>4. В го просто шикарнейший инструментарий. Просто сразу с языком идёт менеджер для зависимостей, система сборки, причём с поддержкой сборки на C (попробуйте настроить сборка на C в Java-проекте, посмотрю я на вас).

Вообще строится — я делал, кажется, через Maven. Готовые рецепты прошли, даже когда я про этот Maven знал только имя и где лежит файл проекта.

vsb> В го идёт go fmt, которым пользуются 146% программистов, В Java даже про размер отступа договориться не смогли, про другие языки вообще молчу.

А зачем об этом договариваться универсально по планете?

Здравствуйте, LaptevVV, Вы писали:

LVV>>>Отсутствие копипасты мгновенно стимулирует студентов писать функции.
LVV>>>Но переходя к С++ они тут же "влезают обратно на пальму" копипасты...
N>>Вы им запретили функции?
LVV>Нет.
LVV>С большинства просто мгновенно слезает флер "цивилизации"...

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

LVV>Но отдельные личности все-таки становятся более "цивилизованными"...

которые этот опыт получили где-то ещё...

Здравствуйте, netch80, Вы писали:

vsb>>Но язык это ерунда.
vsb>>Go лучше, тем, что:
vsb>>1. Не требует IDE для разработки. vscode хватает за глаза.

N>На таком уровне и Java не требует.

Не согласен. Java требует. Я пробовал писать на Java и на Go на vscode и в Idea (все комбинации). И в vim пробовал писать на Go. Java юзабельна только в идее. Go юзабелен везде. Ну это моё мнение, кому и в ed в hex писать бинарники нормально.

vsb>> В го идёт go fmt, которым пользуются 146% программистов, В Java даже про размер отступа договориться не смогли, про другие языки вообще молчу.

N>А зачем об этом договариваться универсально по планете?

1. Меня бесит смотреть на разные стили. Когда в моём приложении один стиль, в спринге другой, в каком-нибудь викете третий. Я по исходникам библиотек прыгаю постоянно. Когда весь код однообразный, это снижает когнитивную нагрузку.

2. Нет проблемы, когда у одного IDE настроена так, у второго по-другому. И в пул-реквестах куча мусора, когда она переформатировала весь файл. Ходить за каждым и настраивать ему IDE это потеря времени. Настраивать в мавене всякие checkstyle-ы на каждый проект это потеря времени. Универсальный стиль на всей планете это нулевые потери времени на вышеописанное.

Здравствуйте, pagid_, Вы писали:

p> R>... Фортран, ада изначально нишевые и ниши узначально узкие. На этом основании считать их "мертвечиной"? Не серьезно.

p> С чего бы им быть изначально нишевым. Это по ходу дела они нишевыми стали. Причем по разным причинам.

Фортран делался для расчетных задач, что отражено в его названии, и сейчас используется только там, где нужна имено хардкорная скорость расчетов (со слов человека работающего с суперами). Ада разрабатывалась конкретно под мишшн критикал (встраиваемое ПО, системы управления) по инициативе МО США.

Здравствуйте, Разраб, Вы писали:

Р> R>Не понял о чем это. О дельфях?

Р> Firemonkey вроде я смотрел

Firemonkey работает на линуксе.

Здравствуйте, so5team, Вы писали:

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

s> COBOL в середине нулевых, как минимум, использовался в Сбербанке. Не удивлюсь, если в крупных компаниях РФ он до сих пор применяется.

На мейнфреймах от IBM, в составе программно-аппаратного комплекса т.е.?

s> R>Фортран, ада изначально нишевые и ниши узначально узкие.

s> Вы заблуждаетесь.

Нет.

s> R>На этом основании считать их "мертвечиной"? Не серьезно.

s> Ну извините, что разбил вам розовые очки и вы узнали, что Delphi для кого-то не выглядит живой и перспективной технологией.

У Delphi более 3 миллионов разработчиков, и пофигу, кто и что думает о ее перспективах.

Здравствуйте, rudzuk, Вы писали:

s>> COBOL в середине нулевых, как минимум, использовался в Сбербанке. Не удивлюсь, если в крупных компаниях РФ он до сих пор применяется.

R>На мейнфреймах от IBM, в составе программно-аппаратного комплекса т.е.?

А какая разница, если софт на COBOL работает и дописывается. Это означает что язык не мертв с формальной точки зрения.

s>> R>Фортран, ада изначально нишевые и ниши узначально узкие.

s>> Вы заблуждаетесь.

R>Нет.

Ну нет, так нет. Особенно про Ada.

R>У Delphi более 3 миллионов разработчиков, и пофигу, кто и что думает о ее перспективах.

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

N>>>А вот куда _вам_ надо чтобы он ехал — я не знаю. Может, как раз в сторону такого копипастинга?
LVV>>Мы копипасту в своей обучающей среде извели как класс.
N>За счёт чего?
Просто не реализовали.
Мы ж для совсем нулевых свою IDE написали с редактором. Без копипасты
LVV>>Отсутствие копипасты мгновенно стимулирует студентов писать функции.

Здравствуйте, vsb, Вы писали:

vsb>>>Go лучше, тем, что:
vsb>>>1. Не требует IDE для разработки. vscode хватает за глаза.

N>>На таком уровне и Java не требует.

vsb>Не согласен. Java требует. Я пробовал писать на Java и на Go на vscode и в Idea (все комбинации). И в vim пробовал писать на Go. Java юзабельна только в идее. Go юзабелен везде. Ну это моё мнение, кому и в ed в hex писать бинарники нормально.

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

vsb>>> В го идёт go fmt, которым пользуются 146% программистов, В Java даже про размер отступа договориться не смогли, про другие языки вообще молчу.

N>>А зачем об этом договариваться универсально по планете?

vsb>1. Меня бесит смотреть на разные стили. Когда в моём приложении один стиль, в спринге другой, в каком-нибудь викете третий. Я по исходникам библиотек прыгаю постоянно. Когда весь код однообразный, это снижает когнитивную нагрузку.

Ну он не настолько разнообразен — в нормальных проектах — чтобы это влияло.
Отличия в другом более существенны — начиная с методов проверки ошибок.

vsb>2. Нет проблемы, когда у одного IDE настроена так, у второго по-другому. И в пул-реквестах куча мусора, когда она переформатировала весь файл. Ходить за каждым и настраивать ему IDE это потеря времени.

Никто не ходит. Даётся стандартная тулза и стандартный конфиг.
Контроль (CI/аналог) на сервере проверяет, если тулза изменила — PR режектится.

vsb> Настраивать в мавене всякие checkstyle-ы на каждый проект это потеря времени.

А будто go fmt на jenkins настраивать это не ровно такая же потеря времени.

vsb> Универсальный стиль на всей планете это нулевые потери времени на вышеописанное.

И тоже если его не форсируешь — его сломают. А Go не форсирует.

Здравствуйте, so5team, Вы писали:

s> R>На мейнфреймах от IBM, в составе программно-аппаратного комплекса т.е.?

s> А какая разница, если софт на COBOL работает и дописывается. Это означает что язык не мертв с формальной точки зрения.

Формально не мертв. Хорошо. Вообще, финансовый сектор очень консервативен, и переписывать тонные работающего кода просто так никто не станет. Это дороже, чем оплачивать сервис IBM. Свидетельствует ли это в пользу кобола? Нет. Впрочем, в Сбере уже ни мэйнфреймов ни кобола, насколько мне известно.

s> Тогда казалось бы с чего бы у вас так припекло?

Здравствуйте, so5team, Вы писали:

S>COBOL в середине нулевых, как минимум, использовался в Сбербанке. Не удивлюсь, если в крупных компаниях РФ он до сих пор применяется.
Сомневаюсь, это очень нехарактерный для СССР/РФ ЯП. Но кое-где мог использоваться, особенно в составе импортных программно-аппаратных комплексов, как уже написали.

Здравствуйте, rudzuk, Вы писали:

R>Фортран делался для расчетных задач, что отражено в его названии, и сейчас используется только там, где нужна имено хардкорная скорость расчетов (со слов человека работающего с суперами).
Фортран делался в те времена, когда единственная задача компьютеров была расчетная. Экономическое использование в форме специализированных компов на замену электро-механических табуляторов только намечалось. Уже по этой причине он не мог быть изначально нишевым. Он как раз на тот момент был майнстимовым.

R>Ада разрабатывалась конкретно под мишшн критикал (встраиваемое ПО, системы управления) по инициативе МО США.
Ада разрабатывалась по заказу МО США, как универсальный язык для всего. В полном соответствие с представлениями конца 70-х о том что такое хорошо в языкостроении, без какой либо особой привязки к встроенным системам и тому подобному. Это изначально. Потом требования МО США смягчились и в какой-то момент он был обязательным для подрядчиков МО США только во встроенных системах. Но это позже.

Здравствуйте, pagid_, Вы писали:

S>>COBOL в середине нулевых, как минимум, использовался в Сбербанке. Не удивлюсь, если в крупных компаниях РФ он до сих пор применяется.
_>Сомневаюсь, это очень нехарактерный для СССР/РФ ЯП. Но кое-где мог использоваться, особенно в составе импортных программно-аппаратных комплексов, как уже написали.

Компания, в которой я тогда работал, делала для Сбербанка проект. В процессе согласования протокола взаимодействия между их и нашим компонентом представитель банка сказал что-то вроде "А для этого нужно будет кусок на COBOL-е дописать" и на мой удивленный вопрос подтвердил, что речь, действительно идет о COBOL-е. Дело было где-то в 2003-2004 годах.

Здравствуйте, pagid_, Вы писали:

p> Фортран делался в те времена, когда единственная задача компьютеров была расчетная. Экономическое использование в форме специализированных компов на замену электро-механических табуляторов только намечалось. Уже по этой причине он не мог быть изначально нишевым. Он как раз на тот момент был майнстимовым.

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

p> Ада разрабатывалась по заказу МО США, как универсальный язык для всего.

Читаем википедию:

Ada was originally designed for embedded and real-time systems.

In the 1970s the US Department of Defense (DoD) became concerned by the number of different programming languages being used for its embedded computer system projects, many of which were obsolete or hardware-dependent, and none of which supported safe modular programming. In 1975, a working group, the High Order Language Working Group (HOLWG), was formed with the intent to reduce this number by finding or creating a programming language generally suitable for the department's and the UK Ministry of Defence's requirements. After many iterations beginning with an original straw man proposal[21] the eventual programming language was named Ada. The total number of high-level programming languages in use for such projects fell from over 450 in 1983 to 37 by 1996.

Косвенное подтверждение:

Ada attracted much attention from the programming community as a whole during its early days. Its backers and others predicted that it might become a dominant language for general purpose programming and not only defense-related work

А в русскоязычной вики об этом заявляется прямо:

А́да (Ada) — язык программирования, созданный в 1979—1980 годах в ходе проекта Министерства обороны США с целью разработать единый язык программирования для встроенных систем (то есть систем управления автоматизированными комплексами, функционирующими в реальном времени). Имелись в виду прежде всего бортовые системы управления военными объектами (кораблями, самолётами, танками, ракетами, снарядами и т. п.). Перед разработчиками не стояло задачи создать универсальный язык, поэтому решения, принятые авторами Ады, нужно воспринимать в контексте особенностей выбранной предметной области.

Была у меня когда-то книжка по Ada-83 в темно-зеленой обложке. Там, кажется, об этом же говорилось.

Здравствуйте, rudzuk, Вы писали:

s>> А какая разница, если софт на COBOL работает и дописывается. Это означает что язык не мертв с формальной точки зрения.
R>Формально не мертв. Хорошо. Вообще, финансовый сектор очень консервативен, и переписывать тонные работающего кода просто так никто не станет. Это дороже, чем оплачивать сервис IBM.

В 90-х при моём факультете (кибер КиевГУ) сидела лавочка, которая массово переписывала софт с Кобола сначала на C++, потом на Java. При наличии библиотеки фиксированной точки это было тривиально.
Возможно, это хорошо работало за счёт дешевизны exUSSR программистов, не знаю уж. Но объёмы переписки были заметными.

Но ещё это было время кризиса IBM. Потом они заметно сменили модель бизнеса в сторону сервиса. Думаю, с 2000-х ваше утверждение стало актуальным.