Динамическая типизация просто? Увольте.

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

Когда делал на C++ работу для универа, 6 часов убабахал на это.

Просто тебе не место в кодинге на плюсах. Без обид.

Пообщался с C++ разработчиками. Если проект, который на C#/Java пишется за неделю/две, на C++ я буду пилить 3 месяца…

Тут Вопрос в том, что на выходе. Проект на плюсах будет жрать 10 мб памяти и летать на любой затычке, а жабка будет жрать под терабайт и тормозить на топовом процессоре.

C# vs Java в 2020. Что выбрать?

Эскобар.жпг. Что то, что то, ынтерпрайз языкчки без идей, сделанные под ооп и макак.

Исследуя рынок понимаем, что по Java и вакансий больше, и зарплаты выше.

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

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

Помню, стивджобс как-то постил свое лежачее рабочее место. Найти не получится, только если его кастануть.

Я не про антагонистов, а про массы, посмотри любой офис средней галеры на яндекс/гугл.картах, если у нас как крысы в бочке, то за бугром чуть лучше, правда скорее гаммой и дизайнами, но сути не меняется.

Но ты же сам готов на жаваскрипте хоть ядро писать.

часть времени стоя работать, другую часть - сидя

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

Хотя, здесь я перегибаю полку, не везде так, но в большинстве случаев.

Если процессу отдается больше 10 гиг, то там начинаются проблемы со сборкой мусора (gc), особенно на компах с многоядерными процессорами.

Не пойму контекста, это для всех у кого есть gc? Т.е. для явы, шарпа, хаскеля..?

Kotlin. Всей душенькой ненавижу этот язык, и не спрашивайте, почему.

А вот таки спросим. Как раз надысь осилил первую серию уроков в Koans, и имею заявить, что nullable/notnull хорошо сделаны: компактно и выразительно по синтаксису, и монадненько (концептуально чисто) по сути. Но дальше смотреть заломало: primary constructor в заголовке класса и тип Nothing – из скалы, а я чё, скалы не видел?

Тем более что компилялись + исполнялись эти однострочные примеры из рук вон медленно. Котлин быстрее скалы, говорите? Чёт засомневало.

Во, кстати! Выбирай скалу. В метапрограммирование побаулешься. И вообще язык отличный – настолько, что наигравшись с ним, я понял, что дальше дорога только назад, и пошёл вспоминать (точнее, изучать современный) C++.

Если вы учитесь на первом курсе - вкладывайте основное время в изучение основ программирования (математика, алгоритмы, структуры данных, реляционные базы данных, анализ и проектитирование программ). Технологии очень быстро изменяются, а фундаментальные основы гораздо более стабильны. На период обучения выберите тот язык, который понравится. А изучать (и довольно хорошо знать) вам надо будет во взрослой жизни не один и не два языка программирования. Думаю, что штук 5 минимум (C, Python, скриптовый-PowerShell/bat/bash, C#/Java, JavaScript/TypeScript/веб) не считая языков разметки и передачи данных (XML, JSON, YAML, HTML).

Ну это если серьезно подходить к вопросу.

Ну а если нужен просто быстрый ответ - то однозначно Java. :)

Но ты же сам готов на жаваскрипте хоть ядро писать.

Не, ядро - это слишком. Даже если делать какого-то игоря, то жс только в качестве скриптухи сбоку.

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

Не пойму контекста, это для всех у кого есть gc? Т.е. для явы, шарпа, хаскеля..?

Это уже интересный вопрос, а насколько общая проблема? Со стороны ее видно по тому, насколько быстро и часто меняют сборщики мусора в жабе. Видимо, хорошо клюнул так жареный петух. Есть некоторая информация в описании сборщика мусора G1, где дается краткое описание проблемы.

Тут, правда, на ЛОРовском сайте брехали, что в go-lang типа очень хороший сборщик мусора, и ему-де все будет по плечу, но я чего-то сильно сомневаюсь. Причем, никаких результатов тестов для 10гб+ не приводилось, а ограничились лишь экстраполяцией «результатов», полученных для 4гб!

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

Еще спасает, что большинство современных ноутбуков, которыми пользуются разработчики, редко имеют размер памяти больше 8-16Гб, где нужно уместить все: и систему, и браузеры, и систему разработки, и само рабочее приложение. Поэтому особо проблемы и не замечают.

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

осознать что оплачиваемый «труд» есть отчуждение личного времени.

после этого многое про экономическую подсистему и объемлющей её подсистемы разделения полномочий в общей структуре человечества проясняется.

знание фундаментальных знаний CS годно в тех полупериферийных частях мир-системы где вопросы лояльности менее остры.

ибо сюзерен-вассал оказалось конкурентней системы эргастериев

Найти не получится, только если его кастануть.

Легко

Вульпекула

в go-lang типа очень хороший сборщик мусора

https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-w...

смеющийся испанец.жпг

А что за идея с балластом размером в 10 гигабайт?!! Можешь рассказать?

WSL2 - это ядро linux, которое крутится в виртуалке hyper-v, просто сделана интеграция так, что не заметно, что это виртуалка.

https://github.com/Frege/frege :)

Потому что уж лучше котлин, чем ломбок.

Ну в статье же объясняется все, ну...

Если вкратце - чтобы GC обмануть, и заставить его срабатывать реже.

Вот еще недавно было тоже про страдания с гошным гц, только эти вместо хитрых маневров решили сразу язык сменить

https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f

stevejobs ★★★☆☆
11.10.13 16:33:30

6 лет назад? Ё-мое...

Зачотный логотип. Посасывающая лямбда это 5.

https://doanduyhai.wordpress.com/2011/12/12/advanced-aspectj-part-ii-inter-type-declaration/

Всё это уже есть в аспектах, и уже народ наелся с них с лихвой. Всё новое - хорошо забытое старое.

еще такое есть https://github.com/typelead/eta

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

Он выделяет по-настоящему 10 гигабайт. И они будут выделены. А не зарезервирована в виртуальном пространстве. То есть память должна быть выделена в Ram или в файле подкачки.

То что менеджер памяти выносит из RSS(Working Set) дела не меняет. В подкачки память остаётся.

Память резервируется в виртуальном пространстве по-другому, с помощью платформенных функций типа mmap или VirtualAlloc. Обычные malloc, new и прочее всегда выделяют память, а не резервируют.

Это может сработать лишь в Linux и то если не выставлена overcommit_memory в OVERCOMMIT_NEVER.

На Windows/FreeBSD и MacOS это не будет работать.

В общем говнище полное его лайфхак. Лучше бы учился писать на Rust/C++/C если у него проблемы со сборщиком мусора.

Вот как выглядит его пример в Windows:

package main

import "time"
import "math"

func main() {
	_ = make([]byte, 100<<20)
	<-time.After(time.Duration(math.MaxInt64))
}

https://i.imgur.com/KyoyWB3.png

This shows just over 100MiB of memory has been allocated virtually to the process — Virtual SiZe (VSZ), while ~5MiB has been allocated in the resident set — Resident Set Size(RSS), i.e physical memory.

никаких 5мб, как он утверждает.

Committed 133MB.

5mb (или 9mb как на скриншоте) это WorkingSet

Но Committed всё равно все 133MB, а это значит что как минимум будут занимать место в файле подкачки.

Занятно. Ну у твича наверное линукс сервера все же.

Это может сработать лишь в Linux и то если не выставлена overcommit_memory в OVERCOMMIT_NEVER.
На Windows/FreeBSD и MacOS это не будет работать.

Про протекающие абстракции, что характерно, тоже недавно был го-срач :) (вроде бы даже на лоре, там про работу с файлами было кажется)

То есть, чтобы программа работала на 10 гигабайтах, ей нужно еще дополнительно сожрать 10 гигабайт просто впрок? Не смешно самому?

P.S. Ты думаешь, что у меня есть время читать все статьи? Я просто попросил тебя кратко пересказать, как ты понял, если ты сам понял, конечно.

So in summary, the ballast increases the base size of the heap so that our GC triggers are delayed and the number of GC cycles over time is reduced.

Я считаю, что понял правильно

То есть, чтобы программа работала на 10 гигайтах, ей нужно еще дополнительно сожрать 10 гигабайт просто впрок?

Автор статьи утверждает, что нет, хотя на этот счет есть сомнения (см. коммент выше от fsb4000)

Now onto 2. Won’t this use up 10Gib of my precious RAM? I’ll put your mind at ease. The answer is: no it won’t, unless you intentionally make it. Memory in ‘nix (and even Windows) systems is virtually addressed and mapped through page tables by the OS. When the above code runs, the array the ballast slice points to will be allocated in the program’s virtual address space. Only if we attempt to read or write to the slice, will the page fault occur that causes the physical RAM backing the virtual addresses to be allocated.

Не смешно самому?

Это не у меня надо спрашивать, а у человека из твича, который это придумал.

То есть, чтобы программа работала на 10 гигабайтах, ей нужно еще дополнительно сожрать 10 гигабайт просто впрок? Не смешно самому?

Там парниша пишет, что GC в go будет запускаться после того как выделенная память превысит выделенную память при прошлом запуске gc в 2 раза. И типа там у него в функциях создавались объекты потом уничтожались и GC часто вызывался.

it can make the decision to trigger the next GC when the total heap size is 2x what the live set currently is.

Тогда он решил выделять вначале 10гигабайт. И типа так как его программа потребляет меньше 10 гигабайт, то тогда этот trigger, что новая куча стала в 2 раза больше, чем была никогда не настанет, и gc будет вызываться реже, меньше CPU тратить.

Ну, наверное это всё верно, CPU он сэкономит.

Но вот вторая часть точно неверная:

Now onto 2. Won’t this use up 10Gib of my precious RAM? I’ll put your mind at ease. The answer is: no it won’t, unless you intentionally make it. Memory in ‘nix (and even Windows) systems is virtually addressed and mapped through page tables by the OS. When the above code runs, the array the ballast slice points to will be allocated in the program’s virtual address space. Only if we attempt to read or write to the slice, will the page fault occur that causes the physical RAM backing the virtual addresses to be allocated.

По крайней мере в Windows точно на 100%. Можно скачать Sysinternals Suite отсюда https://docs.microsoft.com/en-us/sysinternals/downloads/ и запустить его примеры в ProcessExplorer.exe или в vmmap.exe и почитать что такое Comitted, Working Set, Private Bytes и другие обозначения в Windows.

На Linux без vm.overcommit_memory=2 https://www.kernel.org/doc/Documentation/vm/overcommit-accounting возможно будет работать как задумывалось, он же наверное тестил прежде чем писать статью…

Я бы выбрал «образование». Ну, есть темы, которые программисту надо знать, и выучить их во время учёбы - святое дело. Потом будет уже не́когда.

Отдает каким-то редким извращением, причем сильно привязанным до кучи к специфике работы линуксового системного аллокатора. Не проще ли исправить сам gc в go-lang?

Когда делал на C++ работу для универа, 6 часов убабахал на это. На установку VS, на подключение QT

А мог бы сделать sudo apt install build-essentials qtcreator qt5-dev и не маяться.

Эта статья - прямое подтверждение наличия проблем в gc для go-lang.

Это уже интересный вопрос, а насколько общая проблема? Со стороны ее видно по тому, насколько быстро и часто меняют сборщики мусора в жабе.

Это потому что там реально заботит скорость и эффективность работы GC, ты обратил внимание что у других языков часто просто говорят что GC есть и не объясняют как он работает?

У большинства GC, особенно у Generational GC, проблема со среднеживущими объектами, потому как Generational подразумевает деление объектов на поколения: новые объекты и долгоживущие объекты. А вот средний объект, это как у нас средний класс :) Ведь все знают кто такие бедные и кто такие богатые, а средний непонятно. Типичным местом обитания среднеживущих объектов является кеш. Потом еще паузы, все GC требуют stop-the-world пауз чтоб обновить ссылки на объекты (новые объекты ведь туды-суюды гоняются, старые изредко перемещаются чтоб избежать проблемы фрагментации памяти). Короче проблемы GC не специфичны java, просто там этому очень много уделяется времени.

Плюс говорить на игроделов «классные разрабы» - это как-то слишком. Учитывая, что именно игры толкают миллионы школьников клянчить у родителей деньги на апгрейд пк, потому что каждый день что-то новое тормозит. Кстати, в последнее время туда же и фронтендщики подтягиваются, скоро будем апгрейдиться, чтобы твиттер поскроллить.

Это уже интересный вопрос, а насколько общая проблема? Со стороны ее видно по тому, насколько быстро и часто меняют сборщики мусора в жабе. Видимо, хорошо клюнул так жареный петух. Есть некоторая информация в описании сборщика мусора G1, где дается краткое описание проблемы.

Ну они понабирали клиентов на миллионы, потом приходит кто-то и говорит, что ему нужно субмиллисекундные задержки, они берут и садят команду на написание нового GC. Потом опять продлевают контракт, а еще продают мейнфрейм с терабайтами памяти, и опять новый GC писать нужно. Так оно по кругу и идет, спрос-предложение-спрос :)

в go-lang типа очень хороший сборщик мусора

В пределах 2-3 месяцев очень шумела какая-то история про то, как discord переписывал код на раст, потому что им сборка мусора как раз не понравилась (https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f).

Еще спасает, что большинство современных ноутбуков, которыми пользуются разработчики, редко имеют размер памяти больше 8-16Гб, где нужно уместить все: и систему, и браузеры, и систему разработки, и само рабочее приложение. Поэтому особо проблемы и не замечают.

У меня 32 гига памяти, скажу честно, лучше бы не тратился. не знаю, это так макось работает или просто я неправильно смотрю, но у меня практически никогда не было занято больше 20-23 гигабайт (то есть до 10гб свободных), если смотреть htop-ом, например. Причем я держу постоянно 2-3 проекта открытых, браузер, сервер компилятора (или даже несколько), докер и все остальное. И все это еще умудряется подтормаживать, не нагружая ни по процессору, ни по памяти полноценно.

Кстати, характеристики (требования к) GC еще очень зависят от того, какая семантика языка. Например, в х-ле благодаря иммутабельности достаточно простой moving & parallel сборщик, но вот недавно тоже оказалось, что паузы слишком долгие, совсем недавно смержили вот это: https://www.well-typed.com/blog/2019/10/nonmoving-gc-merge/

Наверное, рано или поздно в любом рантайме найдется проблема, которая не решается никакой комбинацией текущих костылей.

Тут работает закон, что природа не терпит пустоты. Как только компьютеры с 64-я гигабайтами станут массовыми, к гадалке не ходи, что и минимальные требования к программам подтянутся до гигабайт 32-х. Увы, такова тенденция всех последних десятилетий. Нельзя довольствоваться малым. Придумывается очередная перделка, которая резко поднимает планку в потреблении памяти почти для всех.

Только по всем тестам .Net просто быстрее Java всегда.

На первый тест взглянул, regex-redux:

• C#.NET core: используется PCRE через DllImport,
• Java: используется java.util.regex

Т.е. сравнение яблок с апельсинами. Думаю в остальных тестах там такая-же ситуация. Доверять benchmarks game себя не уважать.

Если ты идешь в программирование только ради денег - то ты разочаруешься. В соотношении потраченного времени и сил к полученному баблу - ситуация довольно печальная.

Любопытная мысль, я как то с этим не сталкивался никогда. Надо глядеть больше в сторону «популярной микро-жирно-сервисной архитектуры» :).

Мне что-то кажется, 30 лет назад, когда Кармак начал делать свои игры, рынок был немного другим. А вот насчёт Торвальдса соглашусь: тысячи школьников требуют у мамок денег на новые компы чтобы его очередную поделку туда взгромоздить.

Затем, чтобы не использовать IDE?

мда...

Net это перспективы. Java это деградантное болото.

большей глупости я еще не видел. ахахаха)) я знаю что каждый топит за свою прелесть, но то что ты написал это полный треш. я джава дев лет 8-9. также кодил неоднократно на шарпе апишки и более крупные микросервисы. если ты называешь постоянное использование велосипедов чем-то крутым в мире шарпа, то это твой выбор. это что касается сайтов. и о какой производительности идет речь? сайт на спринге в разы проще чем на .net и ни капли не уступает в скорости. не любишь джаву, бери ktor на котлине с полностью сопрограмными кишками. опять же все это делается в наиудобнейшей и быстрой intelij idea. простая апишка на ktor (kotlin) будет такая же быстрая с точки зрения юзабельности.

Фортран :)

Ну глупые ты вопросы задаёшь, ИМХО. Во-первых, важен не язык, а алгоритмы. Понимаешь их - пишешь на чем угодно. Во-вторых, я бы выбирал его не по принципу «так сказали в интернете», а то, к чему лежит твоя душа. За свои почти 20 лет с ПК я успел покодить для себя на всем, начиная от асма под микроконтроллеры и заканчивая го. Но тянуло меня всегда к джаве, ее я и выбрал как основной для себя язык: просто потому что нравится. Даже если абстрактный лисп удобнее и круче для местных красноглазых, мне все равно больше по душе джава.

Просто попробуй попиши на разных языках, и ты поймёшь, чего бы ты хотел. Выбирать себе на будущее инструменты по хотелкам других- путь вникуда.

Ага, спринг вообще на магию смахивает, настолько он прекрасен.

Ну в мкк без си и базового знания ассемблера не выйдет…

с и с++. Остальное - LEGO®land.