Pascal не составляет сильной конкуренции C#, Java, Go etc.
Потому что дело не в языке, а в том, что стоит за ним. C# продвигается майкрософтом - конференции, реклама, поддержка для всех продуктов. За Java стоят миллионы существующих энтерпрайз приложений и их команды. И когда такая команда стартует новый проект, то естественно выбирает опять джаву. Что касается Го, то он много лет точно так же был не особо популярен, пока не выяснилось что он очень хорошо подходит для быстрой разработки микросервисов/девопса и на него стали переходить в первую очередь со всях node.js решений. Плюс Го удобен тем, что вокруг него можно собирать команда разработчиков с разных стэков - примитивный синтакст могут быстро освоилить хоть джависты, хоть плюсовики.
3) Причем чем тут бухучет, вот это твое представление о сложных высоконагруженных приложениях на 5 девяток? Не гипервизор в клауде, которые MS переписала на раст, не DDoS detection в Cloudflare, ни система оркестрации контейнеров типа Firecracker, нет - это все не сложные приложения. Вот бухучет это да.
4) А ты наглядный пример старого дурака, который пишет о том, в чем совершенно не разбирается и думает, что раз 30 лет назад он что-то наговнокодил на С это придает хоть какой-то вес его словам.
Какая еще вкусовщина и маркетинг, если GC/RAII/Borrow Check как раз созданы для решения проблем прописи памяти, dangling pointer, memory leak и т.д. И С++ это не "С с объектами", почитайте Страуструпа. И 30 лет назад приложения были на порядок проще как по требованиям безопаности, так и по функционалу, это как сравнивать ЗИС-5 с КАМАЗ-54907.
Во-первых С уже лет 40 не является основным языком разработки сложных систем, а во-вторых разработка на С несет огромное количество дополнительных трудностей, которые разными способами пытались и пытаются решать во всех последующих языках, от С++ и Java до Go, Zig и Rust.
целая матрица поведения для null каналов, привязка recovery к стеку вызова, интерфейсы, которые могут быть одновремено null и не null, скрытое копирование и аллокации - это не сложные концепции? В том же Rust поведение куда более очевидное и предсказуемое.
Спросите джуна что выведет данный код, увидете какой будет процент правильных ответов
type User struct {
Name string
}
func main() {
users := [1]User{{Name: "aaa"}}
users[0].Name = "bbb"
fmt.Println(users)
user := users[0]
user.Name = "ccc"
fmt.Println(users)
}
Причем тут бизнес логика, если вы буквально цитируете кусок текста, описывающий как технически происходит обработка асинхронных запросов и спрашиваете зачем это нужно? Использование async/await паттерна или грин-тредов в Go как раз позволяют структурно описывать программу синхронно в последовательности действий Ι/Ο, при том что среда исполнения делает обработку Ι/Ο асинхронной.
Что значит "не возникает" и причем тут языки? Механизм обработки конкурентных запросов определяется конкретной библиотекой. В той же java есть Spring MVC с пуллом потоков и блокирующим стеком, при котором возникает именно та проблема, о которой пишет автор статьи - падение производительности в high load за счет потерь на Ι/Ο и есть WebFlux, который использует эвент луп, так же как нода.
Ну это не очень хороший вариант в том плане, что для большинства реализаций gRPC у вас будет происходить перенос парсером данных из сетевого буффера в double[] конечного рантайма(джавы, сишарпа, го и т.д.), т.е. дополнительные расходы на перенос данных, что на 100 гб будет довольно заметно.
Зависит ещё от формата данных. Если это одно сообщение в 100 гигов, то будет огромный оверхэд на сериализацию. Если вам при этом нужно только поменять отдельные поля, посчитать аггрегацию по полю и сохранить данные на диск, то тот Apache Arrow Flight может быть заметно эффективней.
А зачем надо решать то, чего нет в условии задачи?
Алгоритмические задачи предполагают нахождение оптимального решения, а не любого, которое работает. Иначе, конечно, любой пример это "простая задача", чего тут решать. У вас, в частности, сложность O(N^2), что совсем не оптимально.
прогнал T-SQL скрипт на своем совсем не быстром компьютере, чуть больше 1000 случайных пар значений
Так оценку алгоритма и производительности решения никогда не делают.
Статья как сделать HTTP запрос и сохранить результат на диск. Контент который мы заслужили.
Вы бы спросили ChatGPT что будет если у вас больше одного экземпляра приложения запущено, а потом писали бы статью.
Потому что дело не в языке, а в том, что стоит за ним. C# продвигается майкрософтом - конференции, реклама, поддержка для всех продуктов. За Java стоят миллионы существующих энтерпрайз приложений и их команды. И когда такая команда стартует новый проект, то естественно выбирает опять джаву. Что касается Го, то он много лет точно так же был не особо популярен, пока не выяснилось что он очень хорошо подходит для быстрой разработки микросервисов/девопса и на него стали переходить в первую очередь со всях node.js решений. Плюс Го удобен тем, что вокруг него можно собирать команда разработчиков с разных стэков - примитивный синтакст могут быстро освоилить хоть джависты, хоть плюсовики.
write once run anywhere!
никакой - язык под задачу берется.
1) Я тебе не брат
2)
Why C++ is not just an Object-Oriented Programming Language
Bjarne Stroustrup
https://www.stroustrup.com/oopsla.pdf
3) Причем чем тут бухучет, вот это твое представление о сложных высоконагруженных приложениях на 5 девяток? Не гипервизор в клауде, которые MS переписала на раст, не DDoS detection в Cloudflare, ни система оркестрации контейнеров типа Firecracker, нет - это все не сложные приложения. Вот бухучет это да.
4) А ты наглядный пример старого дурака, который пишет о том, в чем совершенно не разбирается и думает, что раз 30 лет назад он что-то наговнокодил на С это придает хоть какой-то вес его словам.
Какая еще вкусовщина и маркетинг, если GC/RAII/Borrow Check как раз созданы для решения проблем прописи памяти, dangling pointer, memory leak и т.д. И С++ это не "С с объектами", почитайте Страуструпа. И 30 лет назад приложения были на порядок проще как по требованиям безопаности, так и по функционалу, это как сравнивать ЗИС-5 с КАМАЗ-54907.
Во-первых С уже лет 40 не является основным языком разработки сложных систем, а во-вторых разработка на С несет огромное количество дополнительных трудностей, которые разными способами пытались и пытаются решать во всех последующих языках, от С++ и Java до Go, Zig и Rust.
Можно на хабре в любом месте написать что делфи устарел - начнется такое, что растовики тихо отдыхают в сторонке.
целая матрица поведения для null каналов, привязка recovery к стеку вызова, интерфейсы, которые могут быть одновремено null и не null, скрытое копирование и аллокации - это не сложные концепции? В том же Rust поведение куда более очевидное и предсказуемое.
Спросите джуна что выведет данный код, увидете какой будет процент правильных ответов
Причем тут бизнес логика, если вы буквально цитируете кусок текста, описывающий как технически происходит обработка асинхронных запросов и спрашиваете зачем это нужно? Использование async/await паттерна или грин-тредов в Go как раз позволяют структурно описывать программу синхронно в последовательности действий Ι/Ο, при том что среда исполнения делает обработку Ι/Ο асинхронной.
Что значит "не возникает" и причем тут языки? Механизм обработки конкурентных запросов определяется конкретной библиотекой. В той же java есть Spring MVC с пуллом потоков и блокирующим стеком, при котором возникает именно та проблема, о которой пишет автор статьи - падение производительности в high load за счет потерь на Ι/Ο и есть WebFlux, который использует эвент луп, так же как нода.
Если на ваш api бэкэнд приходят два запроса одновременно, вы их последовательно обрабатывать будете?
А деньги на обслуживание бэкэнда откуда брать?
Ну это не очень хороший вариант в том плане, что для большинства реализаций gRPC у вас будет происходить перенос парсером данных из сетевого буффера в double[] конечного рантайма(джавы, сишарпа, го и т.д.), т.е. дополнительные расходы на перенос данных, что на 100 гб будет довольно заметно.
Зависит ещё от формата данных. Если это одно сообщение в 100 гигов, то будет огромный оверхэд на сериализацию. Если вам при этом нужно только поменять отдельные поля, посчитать аггрегацию по полю и сохранить данные на диск, то тот Apache Arrow Flight может быть заметно эффективней.
Алгоритмические задачи предполагают нахождение оптимального решения, а не любого, которое работает. Иначе, конечно, любой пример это "простая задача", чего тут решать. У вас, в частности, сложность O(N^2), что совсем не оптимально.
Так оценку алгоритма и производительности решения никогда не делают.
Получается так.
А как это решить в SQL за О(N) без императивного кода?
Приведите, пожалуйста, пример компании, которая нарушает законы своей юрисдикции.