/u/ - Университет

Имя
Email
Тема
Комментарий
Файл
Пaроль (Для удаления файлов.)

File: 1706276261584.png (2,94 MB, 2480x3508, Ferris.png)

 No.333

Местечко, где всегда можно рассказать чем Rust лучше C++; посмеяться над Java программистами и в целом поделиться недавно выученной тривией и задать ответы по направлениям связаных с языками, да и не только.

 No.342

Каков исторический контекст у крайне мутной темы с указателями? 640Кб хватит всем? Или есть иные преимущества, недоступные начинающим быдлокодерам?
мимокрокодил

 No.344

>>342
>крайне мутной темы с указателями
А что там мутного? Вроде там всё просто.

 No.345

>>344
Зачем делать указатель, если можно сделать ещё одну переменную?

 No.346

>>345
Во-первых, да, память экономится, допустим если выделишь большой кусок и потом его копировать туда-сюда долго и прожорливо. Я понимаю, что сейчас можно всегда сказать чтобы пользователь докупил себе памяти, но в случае с всякими микроконтроллерами экономить приходится чаще.
Во-вторых (и я думаю что это главная причина зачем оно сделано), аргументы в функцию передаются через с стек. А стек у нас равен
>ulimit -s
>8192
8 мегабайт в моём случае. Ну и опять же копировать из стека и обратно дело не быстрое.
В третьих, если тебе надо в функции изменить несколько аргументов, то без указателей не обойтись. Одно значение ты ещё можешь вернуть (опять же копирование через стек со всеми вытекающими), а вот больше уже придется запихивать в структуры.

 No.347

>>345
Очень странный вопрос! И не очень понятно, как это связано с количеством памяти.

Без указателей ты далеко не уйдешь? Как делиться памятью между несколькими потоками? Как писать большинство алгоритмов, построенных на указателях (листы, деревья и.. леса), как работать с массивами, как изменять аргументы функций, да как даже делиться самими функциями? А вот никак без указателей!

 No.348

>>342
Некоторые высокоуровневые языки вполне себе успешно скрывают указатели за слоем абстракций. Однако чем ниже мы опускаемся, тем это становится сложнее. Причина этому кроется, внезапно, в самом устройстве компьютеров: у тебя есть процессор (калькулятор на стероидах) и отдельно память (не важно какая). Для того, чтобы процессор мог считать любые данные из памяти, ему сперва нужно знать где они в ней находятся: том 1, страница 100500, пятое слово сверху. Вот подобное описание местоположения и есть указатель. И без них никак.

 No.353

File: 1707392253640.webp (572,98 KB, 2560x1440, wp5057322.webp)

С какого языка лучше всего начинать вкатываться в программирование в 2024? Ваше мнение?

 No.354

>>353
Сначала ассемблер (ARM64 под малину), затем сишечка (K&R), потом схема (SICP). Это ни разу не шутка, если что.

 No.357

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

 No.358

в чем прикол раста чем он лучше с++? первое сообщение на доброчане

 No.359

>>358
Ну если прям совсем вкратце:
1. Строгая типизация.
2. ADT + pattern matching.
3. Трекинг лайфтаймов.
4. Трекинг инвариантов.
5. Человеческий async.
6. Человеческий параллелизм.

 No.360

>>359
офигеть думал тут никого)
на 0 чане меня сразу послали, думаю учить Раст дл общего развития

 No.361

>>360
Если хоть немного знаешь C++, то советую изучать по https://amazon.com/dp/1492052590 можно спиратить с libgen

 No.362

File: 1707614929347.png (523,68 KB, 828x539, 2.png)

>>361
А что там такого есть, чего не получить из официального раст бука и чтения парочки открытых проектов?

Я бы советовал не заморачивать голову книгами о языках и почитать вот это:
https://bfnightly.bracketproductions.com/
https://rust-unofficial.github.io/too-many-lists/index.html
https://rust-unofficial.github.io/patterns/intro.html

 No.363

>>362
Мне официальный раст бук показался, честно говоря, довольно поверхностным: из него непонятно как трейты представлены в памяти, как сделать свой итератор, ни слова про async (да, я в курсе про недоделанный async book) и т.п. Полноценные книги обычно более системны, плюс из них часто можно понять мотивацию выбранных решений в дизайне языка. На самом деле, чем больше ресурсов, тем лучше: всегда можно пару минут полистать и понять нравится тебе подача и стиль изложения или нет.

 No.364

>>363
Думаю ты прав!

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

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

 No.393

File: 1708872268580.jpg (94,27 KB, 573x892, luachan.jpg)

>>353
Зависит.
Lua - невероятно простой и эффективный, идеален для обучения. Питонисты завидуют, но быть на заработке в СНГ очень сложно, тк софта не делают почти, а язык не популярен.

Go - если хочешь получать деньги в бекэнде. Язык не плохой, опережает многие своей уникальностью и востребован, но с точки зрения дизайна нередко порицается - благо, на производительности и памяти (благодаря garbage collector) не сказывается.

Zig - язык будущего. Обожаем всеми кроме ржавых культистов, работу найти невозможно. Еще не дошел до 1.0, но уже опережает весь low-level по многим параметрам, будет востребован через 4 года когда всех программистов заменят неиросети. Bun сейчас лучший рантайм в вебе, так что это будущее может быть даже не за горами.

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

 No.395

File: 1708876452123.png (2,21 MB, 2018x1135, 35.png)

>>393
> опережает весь low-level по многим параметрам
По каким?

> кроме ржавых культистов

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

> скоро перейдет в разряд самодеятельности нежели оплачиваемой профессии

Глупости, все эти модельки не думают, а стохастически подбирают ожидаемые ответы. На таком далеко не уедешь, только пузыри надуешь и, возможно, заработаешь.

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

 No.397

File: 1708966139387.png (1,91 MB, 1649x2048, 1692287162534447.png)

>>395
>нет никакого ответа
Черно белый манямир, такой же как и картинка твоя, почитал бы хоть; у зига есть 4 build мода, которые можно друг с другом комбинировать в одном проекте: это build, ReleaseSafe(безопасность), ReleaseSmall(маленькость °-°) и ReleaseFast(скорость) под разные модули. Но суть не в этом.
Как ни крути, в low-level расту без unsafe не выкрутится и без него это нерабочий язык, а этот самый unsafe именно такой, как и предполагает имя - безопасность там не то что с алокаторами зига, она не может тягаться даже с плюсами 20+ годов (хотя синтаксис там напугал бы даже Ратлиффа). Безопасность зига осуществляется за счет отсуствием футганов и отстуствием скрытого "control flow", а не кастрированием и невменяемыми скоростями компиляции.
На высоком уровне раст же более менее себя прилично показывает, и если закрыть глаза на размеры бинарников, ужасное llwm-овское тульё и то какой кошмар он приносит мейнтейнерам в опенсорсе (не зря же в него микрософты амазоны и прочие сатанисты так много бабла вливали), очень даже неплохой. Только случаев выгорания от раста через чур ( http://way-cooler.org/blog/2020/01/09/way-cooler-post-mortem.html , очень много ожидал от проекта но получилось как получилось)

 No.555

File: 1710722523067.jpg (127,52 KB, 1000x1333, 22.jpg)

В детстве любил играть в Месть Карапузкиков.
Сейчас решил попробовать написать открытый движок для них.
Особо опыта с программированием такого у меня нет (надо и научиться реверсинженирить уже существующий exe, и разобраться с архитектурой движков), поэтому посмотрим, как далеко получится зайти.

Когда будет какой-либо прогресс, буду отписываться тут.
И вам хорошего дня!

 No.556

>>555
Удачи, анон!

 No.690

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

 No.692

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

 No.697

>>692
Почему не сосемблер??? Зиг более низкоуровневый и там ручное управление памятью, просто без футганов, зайди на сайт почитай, 5 минут займёт.

 No.698

>>697
Почитал https://ziglang.org/ru/learn/why_zig_rust_d_cpp/ https://ziglang.org/ru/learn/overview/ и не нашёл каких-то прорывных преимуществ ради которых стоит всё бросить и учить зиг хайль.

>Zig соперничает с C

вообще смехотура

Преимущества его перед сравненными языками сомнительны и выглядят натянутыми - перечисленными "фичами" обладает Си уже 50 лет как:
* Без скрытых потоков управления
* Без скрытых выделений памяти
* Первоклассная поддержка отсутствия стандартной библиотеки
* Встроенный статический анализатор для обнаружения потенциальных утечек памяти (берешь что-то типо pvs/valgrind и прогоняешь)
Теперь к минусам:
* Синтаксис объективно сложнее Сишного
* 0 востребованности на рынке - будущее языка сомнительно
* Вся мишура с
>отсутсвием выделений в куче без прямого указания
рассыпается как только подключаешь любую стороннюю библиотеку

Просто нинужно. Как альтернатива может быть, но профитов переход на него я абсолютно не вижу, а вот траханье с неудобным синтаксисом предстоит постоянное.

>Почему не сосемблер

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

 No.699

>>698
> * Без скрытых потоков управления
> * Без скрытых выделений памяти
Ясно, на C ты не писал.

 No.700

>>699
> * Без скрытых потоков управления
> * Без скрытых выделений памяти
Ясно, на Си ты не писал

 No.702

>>690
ИМХО оси конечно хорошо знать в общих чертах но для реального вката достаточно команд Линукс.

 No.703

File: 1712671358760.png (43,22 KB, 791x293, ClipboardImage.png)


 No.704

>>703
Таки я про С++ ничего в положительном ключе и не писал :3, к чему это?

 No.705


 No.706

>>353
Питон. Инфа сотка. Не обсуждается!



[Назад][Наверх] Catalog [Post a Reply]
удалить пост [ ]