команда может выбирать стек разработки, систему хранения данных, способ аутентификации, способ развертывания, а так же выбрать процесс разработки удобный ей.
Врагу не пожелаю работать в компании с таким подходом.
Что-то в этом роде. Поэтому я всем кто у меня спрашивает как быстро перейти с одного языка на другой рекомендую кроме синтаксиса сосредоточиться на понятиях владения и неявного преобразования типов. Обычно эти вещи от языка к языку изменчивы и вполне способны привести к долго отлавливаемым багам.
В случае Java, C#, Rust, C/C++ под переменной a и b будет находиться одна и та же область памяти. В Go происходит неявное копирование.
Я отдаю себе отчёт, что это всё в Go происходит в рамках его спецификации. Претензий не имею. Просто отметил, что такое поведение не очень очевидно для тех, что пришёл из других языков в Go.
Лично я привык, что переменные - это не сами данные, а сущность позволяющая именованный доступ к данным. При этом не важно это данные, ссылка на данные или ссылка на ссылку на данные.
И когда я присваиваю "а" к "б", то не ожидаю, что произойдёт копирование.
Во многих языках именно так и произойдёт - копирования не будет.
Поэтому здесь это и не очевидно. Имея большой по размерам массив неожиданно получим в этой строке просадку по скорости / памяти.
Тем, кто приходит из других языков это будет неожиданно.
Заодно можно будет оценить, какие дополнительные возможности предоставляет форк,
для этого нужны не дюжие знания в devops и доступ к развесистому оборудованию (кластеризация, репликации и прочее-прочее). у типового студента этого банально нет и не требуется.
в каждой версии они улучшают работу с JSONB. но не факт, что именно на ваших сценариях будет заметно улучшение.
в своих сервисах мы решили использовать JSONB для входящих неструктурированных данных + как способ "безболезненного" расширения атрибутивной модели - все то, что не требует ни индексации, ни участия в запросах.
Мир знает ОС когда драйвера можно было использовать вообще собранные под другую архитектуру (PowerPC --> Intel, к примеру).
Как минимум заставили пересмотреть отношение к космическим "свечам", по которым делают оценку расстояний.
Microsoft уже подсчитала сколько деревьев своим багом убила? Че там гринпис?
Врагу не пожелаю работать в компании с таким подходом.
С чего это поды однопоточные? сколько выделите CPU ресурсов, столько и будет. Ну и от языка разработки это может зависеть, конечно.
В свое время слышал шикарное определение Микросервисов - это решение в котором нет Oracle DB!
Как подписаться чтобы получить уведомление о выходе статьи???
Что-то в этом роде. Поэтому я всем кто у меня спрашивает как быстро перейти с одного языка на другой рекомендую кроме синтаксиса сосредоточиться на понятиях владения и неявного преобразования типов. Обычно эти вещи от языка к языку изменчивы и вполне способны привести к долго отлавливаемым багам.
Можем продолжить про массив. Вот пример на Java:
https://www.programiz.com/online-compiler/2nS7QHhiZmTGp
В случае Java, C#, Rust, C/C++ под переменной a и b будет находиться одна и та же область памяти. В Go происходит неявное копирование.
Я отдаю себе отчёт, что это всё в Go происходит в рамках его спецификации. Претензий не имею. Просто отметил, что такое поведение не очень очевидно для тех, что пришёл из других языков в Go.
Лично я привык, что переменные - это не сами данные, а сущность позволяющая именованный доступ к данным. При этом не важно это данные, ссылка на данные или ссылка на ссылку на данные.
И когда я присваиваю "а" к "б", то не ожидаю, что произойдёт копирование.
Во многих языках именно так и произойдёт - копирования не будет.
Поэтому здесь это и не очевидно. Имея большой по размерам массив неожиданно получим в этой строке просадку по скорости / памяти.
Тем, кто приходит из других языков это будет неожиданно.
Можете подробнее? Друг интересуется.
В ряде задач проблему циклических ссылок можно решить через использование кастомного аллокатора памяти типа Arena. Просто и эффективно.
Правда не универсальное решение, но где подходит - это пушка. И нет утечек, и скорость выделения/освобождения памяти максимальнр быстрая.
для этого нужны не дюжие знания в devops и доступ к развесистому оборудованию (кластеризация, репликации и прочее-прочее). у типового студента этого банально нет и не требуется.
но я с вами согласен. хорошее начинание.
Эм. Steam - чем вам не доверенный источник? и если он не доверенный - то какой другой доверенный источник для игр вы посоветуете?
в каждой версии они улучшают работу с JSONB. но не факт, что именно на ваших сценариях будет заметно улучшение.
в своих сервисах мы решили использовать JSONB для входящих неструктурированных данных + как способ "безболезненного" расширения атрибутивной модели - все то, что не требует ни индексации, ни участия в запросах.
и размер таблицы, пожалуйста.
Субьективщина это всё. Мне больше понравились оригинальные изображения, чем их альтернатива.
Слишком вырвиглазные цвета и задранный контраст. опять же, на мой вкус.
Ох. Как же это не очевидно, что под капотом операции присвоения будет выполнена операция копирования.
В общем случае не может. Потому пока идут обсуждения, чтобы предоставить доступ к DOM через новое API, более гранулярное.
Тем, что код в песочнице получит доступ к области памяти вне песочницы.