Сообщение от voraa А облако Яндекса?

А оно всё на Go?

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

Моя главная причина ненависти к линупсу - это бесконечные зависимости от которых в винде отказались, когда диски стали большими. Но надо ли всегда создавать монолитное приложение? Зачем грузить dll, пока она не понадобилась.

Сообщение от voraa Первые оптимизирующие компиляторы начали появляться именно для фортрана. Если можно считать быстрее, то почему этим не воспользоваться

Это не отменяет того, что ассемблер был быстрее, и вставки на ассме были в моде еще долго.

Сообщение от voraa Ну как бы владельцу сервера это может вылиться в копеечку. Туже задачу можно решить распараллеливанием (что в GO решается на автомате)

Даже если смотреть в моменте, то задача замены или дополнения оборудования намного более проста и предсказуема, чем переработка ПО. Для индустрии же в целом, создать более мощный компьютер нужно один раз, а потом просто его производить. А программ пишутся тысячи. От более мощных компьютеров они все будут работать быстрее, а вот как скорость их написания поднять? Если программа не написана, то о ее производительности говорить нет смысла. Опять же список задач, которые будут выполняться длительное время, по мере улучшения аппаратной части сокращается. Есть задачи нерешаемые за разумное время сейчас, но время выполнения многих сократилось до значений, когда некоторое ускорение уже не дает значимого результата с точки зрения юзера.

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

А на сервере не будет ли проблемой производительность дисковой системы, например? Решение системы дифуров весьма однородный код, там могут эффективно проявляться какие-то оптимизирующие фичи, и вообще саму задачу будет удобно записать на Фортране с его ориентацией на массивы. И время выполнения между разными компиляторами может различаться в разы. А код игрового движка, или движка базы данных является таким же однородным? И не окажется ли время выполнения для разных языков довольно близким? Не в одной функции, а в целом, если это, например, игра, то расчет кадра. Ну будет, допустим C++ самым быстрым, но быстрее он будет на 15-20%. Зато писаться на Delphi или C# будет в 3 раза быстрее.

Мой рант не столько за Delphi, он против C++ и его "производительности", которую не видно, но вокруг которой десятки лет водили хороводы, игнорируя более продуманные языки, но выдумывая обрезки от C++, и в итоге пришли к тому, что на фиг эта ручная оптимизация работы с памятью нужна, а вот автоматическое распараллеливание нужно.

В моем понимании языков программирования существует всего 2 вида:
1) Встроенные, т. е. ограниченные средой выполнения и не имеющие средств работы с памятью. Скриптовые сюда же.
2) Самостоятельные, общего назначения.

И среди последних нет никаких простых\сложных, для нубов и для мужиков. Есть просто язык, если он сложен в освоении и использовании, то это просто плохой язык. Если язык несложный, то это совсем не значит, что он маломощный.

Добавлено через 36 секунд

Сообщение от testuser2 Если в языке нет энумов, то это уже так себе )

Вирту это скажи с его Оберонами.

0

Сообщение от Beltar не имеющие средств работы с памятью. Скриптовые сюда же.

Но среди скриптовых есть один, имеющий средства работы с памятью, это vba.

0

Сообщение от Beltar Зачем грузить dll, пока она не понадобилась.

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

Сообщение от Beltar Но надо ли всегда создавать монолитное приложение?

Микросервисы тоже хороши могут быть. Но какая тут связь с dll?

Сообщение от Beltar и вставки на ассме были в моде еще долго.

На однотипных процах может быть. Мне приходилось мигрировать с x86 на PowerPC (да еще с другим порядком байт)

Сообщение от Beltar а вот как скорость их написания поднять?

Упрощением языков, понижением порога входа.

Сообщение от Beltar И среди последних нет никаких простых\сложных, для нубов и для мужиков. Есть просто язык, если он сложен в освоении и использовании, то это просто плохой язык. Если язык несложный, то это совсем не значит, что он маломощный.

Это все очень относительно и субъективно После нескольких лет работы на ассемблере (правда не x86, а PDP-11 и Vax) C мне показался знакомым и родным. Старый С++ я тоже как то сразу понял, пока это был просто С с классами. Может и дальше бы понимал, но переключился на вебовскую работу. А вот после C, Паскаль невзлюбил сразу. За его begin/end, лишние двоеточия, какой то кошмар со строками...

0

Сообщение от alecss131 Движок вполне себе не плохой

Первые три версии были действительно не плохими. Большая часть известных и заслуженных игр Unreal Engine базируется именно на версиях Unreal Engine 1-3, либо их модификациях. Начиная с 4-ой версии в среднем по играм на нем стало хуже: рендеринг теней с шумами, дрожание теней (CSM, cascaded shadows), растительности (она как-то особенно плохо выглядит в UE4-5), белые вспышки от occlusion culling при даже не резких поворотах камеры, статтеры не смотря на предкомпиляцию шейдеров, SSGI вместе с TAA сглаживанием создают при движении какое-то отвратительное визуальное желе, да и самое по себе TAA без альтернативное со своими артефактами: размытие, шлейфы, дрожание, шумы в тенях. В конечном итоге получается так, что картинка неплохая только в статике. В движении изображение замусорено.

0

Кошмар со строками - это когда каждый второй плюсер пытается сделать помимо STD::String еще и свой класс.

Сообщение от voraa Микросервисы тоже хороши могут быть. Но какая тут связь с dll?

При чем тут микросервисы, просто статически слинковать всё в одно монолитное приложение.
С др. стороны, если у вас задача 100500 разных юзеров обслуживать и, скорее всего, сразу всё понадобится, то, наверное, логично всё грузить. Но там где это не так, монолитная экзешка на 200 Мб размером будет не в тему. Но как бы тоже выделяется ниша, для которой язык мало подходит.

Сообщение от voraa Упрощением языков, понижением порога входа.

Что значит упрощение? Вот Вирт сделал Оберон, я считаю, сделал фигню. Язык у него на 40 стр. может помещается, но код писать на Delphi все равно проще. Например, перечисления не являются абсолютно необходимыми в программировании, их всегда можно заменить константами, но они позволяют сразу задать диапазон возможных значений, отсечь потенциальные ошибки присваивания. И я не вижу смысла упрощать языки, убирая из них перечисления. ООП убирать? Я не хочу вдаваться в философский бред об ООП концепциях, но то ООП, что я вижу в реальных языках решает вполне конкретные задачи. Задает способы доступа, позволяет группировать объекты, позволяет повторно использовать код за счет наследования. Т. е. на масштабе всего проекта, делает его написание и самое главное, отладку, проще. Относительно последнего, сишники могут сколько угодно верещать на begin\end в Паскале, но на фоне той же ошибки типа if (a=b) в C несколько более долгое написание кода - это ни о чем, т. к. каждый запуск для отладки и поиск ошибки - это куда большие потери времени.

То, что язык синтаксически проще некуда, совсем не означает, что на нем легко писать.

Порог входа? По идее, это тот объем языка, который надо выучить, чтобы начать работать. Даже у очень большого языка этот объем может быть не очень большим. Мое мнение - создать универсальный язык можно, и только танцы с бубном вокруг C++ с последующим нагромождением языков под задачи помешали этому.

0

Сообщение от Beltar При чем тут микросервисы, просто статически слинковать всё в одно монолитное приложение. С др. стороны, если у вас задача 100500 разных юзеров обслуживать и, скорее всего, сразу всё понадобится, то, наверное, логично всё грузить. Но там где это не так, монолитная экзешка на 200 Мб размером будет не в тему. Но как бы тоже выделяется ниша, для которой язык мало подходит.

Можно долго спорить, что лучше монолит или микросервисы, но правильного ответа просто нет и быть не может. Все зависит от задачи, условий...
В монолите на 200 мегов тоже нет ничего страшного. Ну висит себе в памяти, работает... Это же сервис (сервер), а не CGI, который при каждом запросе надо тягать.

Сообщение от Beltar но на фоне той же ошибки типа if (a=b) в C

Смешно. Это как сказать, что кто то в паскале будет постоянно делать ошибки var = 0 (вместо var:=0)

ЗЫ И, на мой взгляд, введение в GO := было ошибкой, приводящей к ошибкам.

Добавлено через 25 минут

Сообщение от Beltar но код писать на Delphi все равно проще.

Это все слишком субъективно. А кому то на С++ проще, а мне (сейчас) на GO было бы проще (А на JS совсем просто, при всех его "странностях")

0

Сообщение от voraa Можно долго спорить, что лучше монолит или микросервисы

На сайте до ста тысяч посетителей в сутки никто не будет делать микросервисы. Этот форум когда то имел 200 тысяч уникальных и хватало ресурсов без микросервисов. Хватает одного сервака, но хорошего. Мне бы такие проблемы и я бы с удовольствием разбирался в этих возможностях. У меня максимум было 70 с копейками тысяч уникальных в сутки. Старый сервак со старым оборудованием вполне с этим справлялся. Было три зеркала на разных винтах. Чтение с любого и запись на каждый. Сейчас уже таких проблем нет с магнитными носителями и ресурсы намного круче. А то, что этот форум иногда подвисает, то проблема в том, что форуму уже дохрена лет и дохрена там скопилось инфы. Удалить нельзя, а пользоваться накладно.

0

Сообщение от black1385 На сайте до ста тысяч посетителей в сутки никто не будет делать микросервисы.

А на более нагруженных будут. Как будто, кроме форумов в инете ничего не существует.
Да и просто микросервисы имею преимущество перед монолитом в том, что их проще разрабатывать, отлаживать и модифицировать.
С другой стороны вся система на микросервисах может оказаться сложнее, чем монолит.

0

Сообщение от black1385 На сайте до ста тысяч посетителей в сутки никто не будет делать микросервисы.

Микросервисы не только с масштабированием помогают. Это ещё и разделение на зоны ответственности разных команд разработки.

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

Она гарантировано сложнее станет. Другой вопрос насколько.

0

Сообщение от voraa А на более нагруженных будут.

Будут. Возьми любой. Даже тот же рутуб. Один сервак это не потянет. И даже дело не в кол-ве серваков. Ты же веб-программист и должен это понимать. Я никогда не делал на микросервисах, но представление имею.

Добавлено через 41 секунду

Сообщение от Usaga Это ещё и разделение на зоны ответственности

Именно это я и хотел сказать

0

Сообщение от Usaga Это ещё и разделение на зоны ответственности разных команд разработки.

Для этого нужны не микросервисы, а модульность в архитектурне.

Сообщение от voraa Это как сказать, что кто то в паскале будет постоянно делать ошибки var = 0 (вместо var:=0)

Не так, в Паскале такая ошибка вызовет ошибку компиляции. В Си это вызовет непредсказуемый эффект в рантайме. Возможно, современные компиляторы Си и могут выдавать предупреждения на такие сомнительные случаи, но не факт, ведь это может быть и специально так написано. Типа

Как компилятору понять в общем случае, программист написал так намеряно или опечатался?

Синтаксис Паскаля строже и однозначней, позволяет меньше выкрутасов (типа Duff's device) и заметно снижает вероятность выстрелить себе в ногу, это факт. А всякие баги и уязвимости в Сишном коде из-за всяких там выходов за границы массивов, переполнений и прочего UB почти что норма. Даже я о подобных случаях довольно часто читал, хотя на Си не пишу.

Добавлено через 6 минут

Сообщение от Beltar А давайте разберем зачем Гугл вообще сделал Go и что это такое. А это просто еще одно урезание C++ по самое не могу с добавлением многопоточности.

Go к C++ имеет крайне мало отношения.

Сообщение от Beltar Нет, я такого не говорил, мне неизвестна статистика. Я говорил, что Delphi для этого применяется, и направление это там взято как бы еще в 2011-ом году, и до сих пор не закрыто. Какой процент мобильных приложений написан на Delphi? Может 1%, а может 10%. Прикол в том, что даже 1% от богатого рынка - это огромная величина

А, да? Ну так же можно утверждать, что и Python какую-то огромную величину этого рынка занимает. Может, даже больше, чем Delphi.

0

Сообщение от korvin_ Для этого нужны не микросервисы, а модульность в архитектурне.

Модульная архитектура это must have by default. Но одно приложение - это одно приложение. Один язык, один технологический стек. Не тоже самое, что разнесение кода по разным проектам.

0

Сообщение от voraa Смешно. Это как сказать, что кто то в паскале будет постоянно делать ошибки var = 0 (вместо var:=0)

Разница в том, что в Паскале это не скомпилируется, т. е. ошибка будет исправлена сразу.

Сообщение от korvin_ А, да? Ну так же можно утверждать, что и Python какую-то огромную величину этого рынка занимает. Может, даже больше, чем Delphi.

Может и занимает. Но, скорее всего, нет, т. к. Питон запчасть. В т. ч. и для Delphi.

Интересную статку по опросу 3000 юзеров самой Аброкадаброй нашел на начало 2024-го.
https://www.youtube.com/watch?v=OpyU8HRPzPE

Смотреть час видео, конечно, не все хотят, но интересного там, что спустя 2 месяца после релиза 12-ой версии на нее 20% опрошенных перешли, остальные в основном на 11-ой. Т. е. обновление версий у юзеров каждые 2-4 года реально идет и бабосы разрабу заносят.

Заработали эти 3000 юзеров на написанном на Delphi\Builder'е софте 7 млрд USD и в основном там десктоп и Windows Server, потом андроид, хотя уже тоже значимо. Потом iOS, Linux и исчезающе мало MacOS, хотя ее и так исчезающе мало. Прикол в том, что вопреки представлениям, что на Windows уже никто не пишет, еще как пишут, просто, основной рынок - это, видимо, дорогой заказной софт, где всегда работы полно. Потому что все "эти ваши" веб-технологии на линупсе лишь малая оконечность всей IT-индустрии, задача которой сводится, в основном, к "из база взял, в браузер показал". А создается всё, что там показывается, или не показывается, но обсчитывается, именно прикладным софтом на винде.

Сообщение от korvin_ Go к C++ имеет крайне мало отношения.

Синтаксически больше похоже на гибрид Си с Паскалем. Тут можно спросить, почему так, ведь, обычно, тащили сишный синтаксис без этих ваших func, var и объявлениями <Тип> [<Переменная>], но при этом оставили дурацкий сишный псевдо"for" в котором надо руками инкрементацию счетчика писать. Но появился этот язык именно потому, что ни C++, ни его обрезки Гугл не устраивали.

0

Сообщение от Beltar дурацкий сишный псевдо"for" в котором надо руками инкрементацию счетчика писать.

А как надо? Если не 1 менять, а на 2? Или не прибавлять надо, а умножать?

Сообщение от Beltar и исчезающе мало MacOS

В мире? В РФ? В США?
Хотя, если это касается Дельфи, то не удивительно. В MacOs наверно на другом пишут.

Сообщение от Beltar Потому что все "эти ваши" веб-технологии на линупсе лишь малая оконечность всей IT-индустрии, задача которой сводится, в основном, к "из база взял, в браузер показал".

А чем величину оконечности меряли? Количеством пользователей? Заработанными деньгами? Затраченными деньгами? Строками кода?

0

Сообщение от voraa В MacOs наверно на другом пишут

У них свои родные языки, Objective-C и пришедший ему на смену Swift, который очень похож на Kotlin/Go/Rust

0

Сообщение от alecss131 Swift, который очень похож на Kotlin/Go/Rust

Странное перечисление. Я бы Go с Rust не смешивал. Это совсем разные языки, на мой взгляд.

1

Сообщение от Beltar хотя ее и так исчезающе мало

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

Добавлено через 3 минуты

Сообщение от Beltar Заработали эти 3000 юзеров на написанном на Delphi\Builder'е софте 7 млрд USD

То есть, в среднем по 2 млн на юзера? Не густо.

0

Сообщение от voraa Странное перечисление

Мне все они показались похожими. Я знаком хорошо со свифтом, поверхностно с котлином и бегло осмотрел остальные 2. Общего у них больше чем у например Go c С++
Ну и дальше много похожего

0

Сообщение от alecss131 Kotlin 1 2 3 4 fun add(x:Int, y:Int): Int{     var z: Int = x + y     return z }

или сокращённый вариант

0

Ну вот функции у GO c Rust слегка похоже объявляются! (А циклы разные, и switch/match тоже) Ну это не делает их похожими (Про Swift с Kotlin не говорю - я про них ничего не знаю). Похожесть синтаксиса - ничего не значит.

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

0