Size: a a a

Programming Offtop

2020 August 23

AK

Anatoliy Kernokus in Programming Offtop
потому что есть огромная кодобаза и тут не будет так как у Java с Kotlin - постепенное вытеснение. тут либо всё переписывать на раст, либо сидеть на плюсах. Если бы людям было удобно писать ПО на мк на расте,то думаю это уже произошло бы бумом в индустрии.(можно и на JS писать,но никто же не пишет:))  только палками не забивайте, это мнение джуна
источник

AK

Anatoliy Kernokus in Programming Offtop
Alexander Nozik
Почему? Как раз дичь писать это на С++.
я ярый ненавистник плюсов и хочу узнать почему писать ПО для мк на С и С++ это дичь а раст для этого лучше, просвятите?
источник

AN

Alexander Nozik in Programming Offtop
Anatoliy Kernokus
потому что есть огромная кодобаза и тут не будет так как у Java с Kotlin - постепенное вытеснение. тут либо всё переписывать на раст, либо сидеть на плюсах. Если бы людям было удобно писать ПО на мк на расте,то думаю это уже произошло бы бумом в индустрии.(можно и на JS писать,но никто же не пишет:))  только палками не забивайте, это мнение джуна
Если кодобаза на С, она и останется. А если на С++, то от нее так или иначе надо избавляться
источник

AN

Alexander Nozik in Programming Offtop
Anatoliy Kernokus
я ярый ненавистник плюсов и хочу узнать почему писать ПО для мк на С и С++ это дичь а раст для этого лучше, просвятите?
Потому что бесплатный контроль памяти, и, гораздо более важно, современный идоиматичный язык.
источник

AK

Anatoliy Kernokus in Programming Offtop
избавляться от кодобазы на плюсах, это не то же самое что избавляться от кодобазы на той же жабе. это НАМНОГО сложнее
источник

AK

Anatoliy Kernokus in Programming Offtop
Alexander Nozik
Потому что бесплатный контроль памяти, и, гораздо более важно, современный идоиматичный язык.
надо ознакомиться с бесплатным контролем памяти поближе,первый раз слышу
источник

AO

Alexey Otts in Programming Offtop
Alexander Nozik
Есть, но я слышал нелестные отзывы про их кодовую базу. И хочется мнения очевидца
Судя по всему ещё что то в дискорде пилится
https://m.habr.com/ru/post/487116/
источник

AN

Alexander Nozik in Programming Offtop
Anatoliy Kernokus
надо ознакомиться с бесплатным контролем памяти поближе,первый раз слышу
Тогда не понятно, о чем вы спорите. Это ключевая фича раста, вокруг которой все построено
источник

AK

Anatoliy Kernokus in Programming Offtop
Alexander Nozik
Тогда не понятно, о чем вы спорите. Это ключевая фича раста, вокруг которой все построено
я вообще ни о чём не спорю)
источник

AN

Alexander Nozik in Programming Offtop
Anatoliy Kernokus
избавляться от кодобазы на плюсах, это не то же самое что избавляться от кодобазы на той же жабе. это НАМНОГО сложнее
А кто спорит? Вопрос в том, что дешевле - избавиться от нее или поддерживать ее
источник

I

Igor in Programming Offtop
Вывод: хочешь просто - пиши иммуатебльный синглтред код, без шареных ресурсов 🤔
источник

AO

Alexey Otts in Programming Offtop
Anatoliy Kernokus
надо ознакомиться с бесплатным контролем памяти поближе,первый раз слышу
Ну типо у компилятора достаточно информации, для того чтобы самому расставить все места освобождения памяти
источник

AN

Alexander Nozik in Programming Offtop
Alexey Otts
Ну типо у компилятора достаточно информации, для того чтобы самому расставить все места освобождения памяти
Скорее управление памяти увязано с лексическими скоупами
источник

AK

Anton Korotkikh in Programming Offtop
Ну так они по сути правы там. Ты либо не понимаешь вопрос либо специально ищешь соринки с бревном в своём jvm-глазу. В чём суть вопроса? - где пакетный маганер в жабе. Пакетный манагер - это такая простая и минималистичная штука в пользовании, она, внезапно устанавливает пакеты и иногда может билдить и запускать скрипты. И да, его в жабе - нет. Вместо минималистичного тулинга, для использования которого достаточно прочитать вывод хелп команды или пару страниц доки, предлагается безумный жирный комбайн с километровыми мануалами.
Представь что это вопрос про микроволновку, типа, а где у вас тут микраха? Человек знает, что у микрахи отрывается дверца, нажимается кнопка и она греет - это всё что от неё требуется и это покрывает 99% потребностей рынка и так должна быть устроена микраха. Берётся команда (npm, gem, go, pip, cargo) и ставистя пакет install и может есть build. Но вместо этого прикатывеется какая-то монструозная доменная печь с кучей настроек и тумблеров, совершенная непригодная для того чтобы быстро разогреть пиццу. И самое нелепое, дальше начинаются загоны, что это ок вы просто не осилили. Это не ок - это всратый UX и перусложнённость на пустом месте, в джаве нет нормального пвакетного мнагера, как в других экосистемах. И если бы подход типа градла был ок, то все бы клепали монструозные комбайны, покрывающие кейсы только здоровенных мутных проектов (а в большей части задач, нужно просто поставить зависмости и собрать), но так никто не делает, как заметно по рынку, это легаси херня и отказ признавать ошибки.
Из гениального есть ещё это:
Java packaging and dependency management is two orders wuperior to anything you can find for JavaScript
Это косой костыль на фоне жс (и любого другого мейнстрима типа gem или cargo) сейчас, а не packaging and dependency management.
источник

AD

Apache DOG™ in Programming Offtop
Anton Korotkikh
Ну так они по сути правы там. Ты либо не понимаешь вопрос либо специально ищешь соринки с бревном в своём jvm-глазу. В чём суть вопроса? - где пакетный маганер в жабе. Пакетный манагер - это такая простая и минималистичная штука в пользовании, она, внезапно устанавливает пакеты и иногда может билдить и запускать скрипты. И да, его в жабе - нет. Вместо минималистичного тулинга, для использования которого достаточно прочитать вывод хелп команды или пару страниц доки, предлагается безумный жирный комбайн с километровыми мануалами.
Представь что это вопрос про микроволновку, типа, а где у вас тут микраха? Человек знает, что у микрахи отрывается дверца, нажимается кнопка и она греет - это всё что от неё требуется и это покрывает 99% потребностей рынка и так должна быть устроена микраха. Берётся команда (npm, gem, go, pip, cargo) и ставистя пакет install и может есть build. Но вместо этого прикатывеется какая-то монструозная доменная печь с кучей настроек и тумблеров, совершенная непригодная для того чтобы быстро разогреть пиццу. И самое нелепое, дальше начинаются загоны, что это ок вы просто не осилили. Это не ок - это всратый UX и перусложнённость на пустом месте, в джаве нет нормального пвакетного мнагера, как в других экосистемах. И если бы подход типа градла был ок, то все бы клепали монструозные комбайны, покрывающие кейсы только здоровенных мутных проектов (а в большей части задач, нужно просто поставить зависмости и собрать), но так никто не делает, как заметно по рынку, это легаси херня и отказ признавать ошибки.
Из гениального есть ещё это:
Java packaging and dependency management is two orders wuperior to anything you can find for JavaScript
Это косой костыль на фоне жс (и любого другого мейнстрима типа gem или cargo) сейчас, а не packaging and dependency management.
Чем вам мавен с сбт не угодил
источник

AD

Apache DOG™ in Programming Offtop
Мне только хмл
источник

AK

Anton Korotkikh in Programming Offtop
Apache DOG™
Чем вам мавен с сбт не угодил
UX сильно изменился за последнее время. Я же об этом и пишу, всё везде стало очень просто одной командой ставишь пакет, одной собираешь проект всё - теперь уже в лом для базовых задач изучать манагер или билд тул, если молоток нужно изучать перед тем как забить гвоздь - это просто хуёвый молоток. А что мваен? - он по умолчанию даже не собирает пригодный для запуска fatJar (а это должно быть по умолчанию при вбике команды build), он могёт поставить зависомсть одной командой? даже когда ставишь, внутри много лишнего типа groupId, artifactId итд. нахуа? есть навазние пакета есть версия - отсальное нинужно в большинстве случаев.
источник

AR

Alxius R in Programming Offtop
как считаете это нормальный БП на 700 Ватт?  https://www.dns-shop.ru/product/bf966624c84b3330/blok-pitania-xilence-red-wings-xn054-700w-xp700r7/  Корсары просто дорого.  Для обычного ПК Ryzen +1080 сойдёт? По идее должно.  но на 600вт БП всё выключается и лампочка белая на видеокарте мигает, от некоторых игр.
источник

BP

Bogdan Panchenko in Programming Offtop
Anton Korotkikh
Ну так они по сути правы там. Ты либо не понимаешь вопрос либо специально ищешь соринки с бревном в своём jvm-глазу. В чём суть вопроса? - где пакетный маганер в жабе. Пакетный манагер - это такая простая и минималистичная штука в пользовании, она, внезапно устанавливает пакеты и иногда может билдить и запускать скрипты. И да, его в жабе - нет. Вместо минималистичного тулинга, для использования которого достаточно прочитать вывод хелп команды или пару страниц доки, предлагается безумный жирный комбайн с километровыми мануалами.
Представь что это вопрос про микроволновку, типа, а где у вас тут микраха? Человек знает, что у микрахи отрывается дверца, нажимается кнопка и она греет - это всё что от неё требуется и это покрывает 99% потребностей рынка и так должна быть устроена микраха. Берётся команда (npm, gem, go, pip, cargo) и ставистя пакет install и может есть build. Но вместо этого прикатывеется какая-то монструозная доменная печь с кучей настроек и тумблеров, совершенная непригодная для того чтобы быстро разогреть пиццу. И самое нелепое, дальше начинаются загоны, что это ок вы просто не осилили. Это не ок - это всратый UX и перусложнённость на пустом месте, в джаве нет нормального пвакетного мнагера, как в других экосистемах. И если бы подход типа градла был ок, то все бы клепали монструозные комбайны, покрывающие кейсы только здоровенных мутных проектов (а в большей части задач, нужно просто поставить зависмости и собрать), но так никто не делает, как заметно по рынку, это легаси херня и отказ признавать ошибки.
Из гениального есть ещё это:
Java packaging and dependency management is two orders wuperior to anything you can find for JavaScript
Это косой костыль на фоне жс (и любого другого мейнстрима типа gem или cargo) сейчас, а не packaging and dependency management.
Добавить зависимость в гредле или мавене - строчка (в мавене 3-4), это равносильно "одна команда" ?
источник

AM

Andrew Mikhaylov in Programming Offtop
Anton Korotkikh
Ну так они по сути правы там. Ты либо не понимаешь вопрос либо специально ищешь соринки с бревном в своём jvm-глазу. В чём суть вопроса? - где пакетный маганер в жабе. Пакетный манагер - это такая простая и минималистичная штука в пользовании, она, внезапно устанавливает пакеты и иногда может билдить и запускать скрипты. И да, его в жабе - нет. Вместо минималистичного тулинга, для использования которого достаточно прочитать вывод хелп команды или пару страниц доки, предлагается безумный жирный комбайн с километровыми мануалами.
Представь что это вопрос про микроволновку, типа, а где у вас тут микраха? Человек знает, что у микрахи отрывается дверца, нажимается кнопка и она греет - это всё что от неё требуется и это покрывает 99% потребностей рынка и так должна быть устроена микраха. Берётся команда (npm, gem, go, pip, cargo) и ставистя пакет install и может есть build. Но вместо этого прикатывеется какая-то монструозная доменная печь с кучей настроек и тумблеров, совершенная непригодная для того чтобы быстро разогреть пиццу. И самое нелепое, дальше начинаются загоны, что это ок вы просто не осилили. Это не ок - это всратый UX и перусложнённость на пустом месте, в джаве нет нормального пвакетного мнагера, как в других экосистемах. И если бы подход типа градла был ок, то все бы клепали монструозные комбайны, покрывающие кейсы только здоровенных мутных проектов (а в большей части задач, нужно просто поставить зависмости и собрать), но так никто не делает, как заметно по рынку, это легаси херня и отказ признавать ошибки.
Из гениального есть ещё это:
Java packaging and dependency management is two orders wuperior to anything you can find for JavaScript
Это косой костыль на фоне жс (и любого другого мейнстрима типа gem или cargo) сейчас, а не packaging and dependency management.
А напомни, как к ноде без вебпака прикручиваются, я не знаю, левые транспайлеры?
источник