Вышел Golang 1.17

если это как раз подразумевает увеличение количества операций с памятью в текущем контексте

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

lazy8, проблемы readable синтаксиса во всех языках программирования - грамматики.

Не совсем. Есть ещё проблема «множество способов сделать одно и то же разными путями». Проблема множества сущностей. И даже когда называют типа __attribute__ или _class – из той же оперы.

Если объект освобождён, то и память под него освобождена

Не всегда так, есть замечательная работа на эту тему, правда касается плюсов.

Не всегда так, есть замечательная работа на эту тему, правда касается плюсов.

Спасибо!
Что в кладовочке еще полезного есть?

а что интересует благородного Дона?

а что интересует благородного Дона?

Аллокаторы, объекты, … - разработка.
Но не о том как это можно реализовать в C++, …

Дженерики обещают в версии 1.18. Ждать осталось недолго.

Про это можно бесконечно читать. Попробуй это и это.

Генерики просто перенесли на следующий релиз (1.18) и когда-нибудь они просто тихо переименуют 1.x в 2.

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

Вообще я стараюсь в яву не лезть, но я так понимаю, что именно этим онанизмом и занимаются. Т.н. gc-free.

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

Да, понял про какие пулы речь. Я имел ввиду sync.Pool и про него говорил.

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

И Го всё равно вызывает GC даже если не было ни выделения ни освобождения. Про это писали уже ребята из Discord, когда перетаскивали на Rust какой-то свой кэширующий сервис. Они всё оптимизировали, но получили огромную паузу. Сборщик просто обходил объекты в пустую, если не ошибаюсь.

Спасибо!

Эту https://archive.org/details/Software_Construction_Data_Structures_Ada_95_Michael_Feldman?view=theater&ui=embed&wrapper=false

качнул здесь
https://dokumen.pub/software-construction-and-data-structures-with-ada-95-2nd-edition-2nbsped-0201887959-9780201887952.html

По allocate конечно хорошая публикация.
Ныне allocate для своего API разрабатываю /но не для замены системного/.
Для Си /чтобы «не было стыдно за бесцельно прожитые»/ годы.

Кстати неплохая книженция «Data structures and algorithms with C 9781783323685».
В ней на каждый чих приведен код на Си /для начинающих ИМХО полезна/.

Не понимаю как можно жить без дженериков. Я как-то пробовал поиграться с го, мне тогда надо было работать с графом и хранить какую-то информацию в нодах, и я серьезно пожалел, конечно. То, что в языках с дженериками легко делается в одну конструкцию, в Go пришлось делать через страшные преобразования типов и ад. Бррр.

В джаве запили ForeignMemory для ручного управлению памятью, до этого ручное управление делалось через Unsafe. Так что можно обойтись без GC.

а что случилось с main?

И будет, как с питонами? Или код, написанный под 1, сможет без правок работать под 2?

Или какой-нибудь автопреобразователь добавят? Вида:

golang1to2 -p ./my_project/

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

И код заточенный под это дело уже будет выглядеть настолько отлично, что его нельзя будет назвать кодом на языке «Х» в полной мере.

Да, я так и написал. Ещё навеяло другой статьей с медиума: мы делаем финансовый low latency софт в клауде. Kernel bypass, по ядру под задачу. И на яве.

Статью про go -> rust тоже читал вроде. Интересная.

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

PS: Релиза 2.0 скорее всего никогда не будет. 2.0 – это такой running-gag.

lazy8 у вас хороший тред получился.
Что касаемо изначального текста, то опубликуйте на какой-нибудь файло-помойке.
Почитаем …

касаемо изначального текста

В основном касательно поддерживаемых архитектур

• добавлена архитектура windows/arm64
• маководы лишаются поддержки всех версий систем раньше High Sierra (обычно это ничего не значит, Windows XP давно дропнута, но работает как и раньше)
• openbsd/mips64 теперь поддерживает cgo
• указатель на стек для всех ARM64, для тех кто пишет на ассемблере
• зарезервирована архитектура loong64 (архитектура разработанная Академией наук Китая)

И про флаги -go и -compat для go mod tidy, например

• go mod tidy -go=1.17
• go mod tidy -compat=1.17

Как раз нужные для апгрейда.

У вас ссылка «Go 1.17 Release Notes» https://golang.org/doc/go1.17 приведена.
Скорее всего просто сократили немного заголовок треда …

Язык то в принципе нормальный. То что некоторые говорят что в нет нет ООП, просто утята. ООП на структурах и методах вполне норм.

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

package main

import (
	"fmt"
)

type Coord struct {
	x, y int
}

type A struct {
	name string
	coords []Coord
}

type B struct {
	v map[A]Coord // invalid map key type A
}

const b1 B = B{} // const initializer B{} is not a constant

func main() {
	b2 := B{}
	fmt.Println(b2)
}

Мономорфные, как в С++. У Пайка хватило мудрости не связываться с полиморфными java-like.

Дженерики не нужны. Go 2 не нужен. math.Min/Max ручками так и продолжишь писать?

Вон оно как. А я досихпор не понимаю зачем эти женерики нужны. За плечами магистратура CS и 10 лет жабы. Ни разу женерики не юзал. Все что с ними видел это пример функции сложения разных типов :D

Не понятно как у вас ваши сборщики, которые сразу вычищаются с короткоживущими объектами себя хорошо показывают,

Потому что они generational. Они устроены по принципу экспоненциально увеличивающегося размера арен, которые просматриваются реже и реже с ростом размера. Приложения, которые выделяют много короткоживущих объектов (например, парсинг XML/JSON) и не шарят объекты между потоками, будут сидеть в первой арене. Тут и выделение памяти очень быстрое (арена), и высвобождение — тоже.

Мы точно так же делаем и в С++. Если парсятся документы для RPC, то это делается в арене. Просто в С++ арену сделать очень просто, и контролировать её очень просто. А в Java всё по максимуму скрыто от приложения, и только несколько настраиваемых параметров (размеры арен и частота просмотра) торчат наружу.

тупо на потоках, и только для Линукс

Зато говорят, что интероп go<->c гораздо быстрее и им даже можно пользоваться.

до этого ручное управление делалось через Unsafe.

Один большой «UB в продакшене», с точки зрения С++-ника. Но джавистам не понять))

ForeignMemory

Не прошло и ста лет)) Годная вещь, я её юзаю и с нетерпением жду Panama.

А я досихпор не понимаю зачем эти женерики нужны. За плечами магистратура CS и 10 лет жабы. Ни разу женерики не юзал.

Коллекции доводилось юзать? Вот что бывает, когда рантайм не умеет в мономорфизацию классов.

Если у тебя есть достаточно гибкие мономорфные дженерики («как в С++») И есть value-семантика, то ты можешь конструировать кастомные раскладки данных по памяти, что есть data-oriented design (DoD). И что есть очень хорошо с точки зрения кэшей и иерархии памяти.

Делать DoD в Java очень сложно. Там этим в приципе не заморачиваются. Хотя годные дизайны (PrestoDB) иногда появляются.

Когда в гошечку завезут нормальную работу с raw сокетами и сборку/парсинг собственных tcp/ip пакетов? Dial не хватает даже нормальный порт сканер написать…

заточен под сетевое программирование, говорили они…

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

Когда в гошечку завезут нормальную работу с raw сокетами и сборку/парсинг собственных tcp/ip пакетов

Зачем?
Полно хороших библиотек.
Прикрутите и РАДУЙТЕСЬ!

Найдешь мне такую? И чтоб на mac os работало. Хотябы пресловутый SYN scan сделать.

Вопрос от дилетанта в Го. А заюзать С из Го для этого можно?

Найдешь мне такую? И чтоб на mac os работало. Хотябы пресловутый SYN scan сделать.

Зачем?
Вы и сами справитесь …

Я не справился и написал на BPF.

Ну, то есть как не справился, под линукс их есть, но вот с фрёй и макосью (= ворованная фря) облом, там Listen не работает, так как ядро не передает пакеты в raw сокеты. Тут-то нам и понадобится роутинг на datalink лейере OSI. Тут душные индусские макаки из гугола могли и поднапрячься. Хотя, кого мы обманываем, они же только христоматийные задачки с литкода умеют.

Ахаха, знакома я тема.

Дело в том, что в C++/Rust/Go(будут) инвариантные, и это накладывает определенные ограничения на парадигму их применения. В Java — ковариантные/контрвариантные, и поэтому могут вступать в иерархии наследования. Однако, реализация таких дженериков опять попала в «трясину Тьюринга». Они оказались полны по Тьюрингу, и на них можно выразить в принципе любые отношения обобщенных типов, но реально это сделать практически невозможно (term rewriting потому что, слишком сложно для человека).

Я, после 20 лет программирования на Java, её дженерики обхожу стороной и вещи уровня Tinkerpop API сдизайнить не смогу, потому что не хочу))

Т.е. они нужны, они важны. С ними можно много чего полезного делать даже в Java (вывод типов). Но пусть этим занимаются другие люди))

Но в Go будут инвариантные момноморфные дженерики. Т.е. это совсем другая парадигма и другие юзкейсы.

Фишка в том, что с мономорфными дженериками Go сможет еще сильнее закрепить себя как язык для разработки движков баз данных.

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

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

А как тебе такое?

MODULE Figures; (* Abstract module *)

TYPE
   Figure*    = POINTER TO FigureDesc;
   Interface* = POINTER TO InterfaceDesc;

   InterfaceDesc* = RECORD
      draw*  : PROCEDURE (f : Figure);
      clear* : PROCEDURE (f : Figure);
      mark*  : PROCEDURE (f : Figure);
      move*  : PROCEDURE (f : Figure; dx, dy : INTEGER);
   END;

   FigureDesc* = RECORD
      if : Interface;
   END;

PROCEDURE Init* (f : Figure; if : Interface);
BEGIN
   f.if := if
END Init;

PROCEDURE Draw* (f : Figure);
BEGIN
   f.if.draw(f)
END Draw;

(* Other procedures here *)

END Figures.

MODULE Rectangles;

IMPORT Figures;

TYPE
   Rectangle* = POINTER TO RectangleDesc;

   RectangleDesc* = RECORD
      (Figures.FigureDesc)
      x, y, w, h : INTEGER;
   END;

VAR
   if : Figures.Interface;

PROCEDURE New* (VAR r : Rectangle);
BEGIN
   NEW(r);
   Figures.Init(r, if)
END New;

PROCEDURE Draw* (f : Figure);
   VAR
      r : Rectangle;
BEGIN
   r := f(Rectangle); (* f AS Rectangle *)
   (* ... *)
END Draw;

(* Other procedures here *)

BEGIN (* Module initialisation *)
   NEW(if);
   if.draw  := Draw;
   if.clear := Clear;
   if.mark  := Mark;
   if.move  := Move
END Rectangles.

Смею предположить, что ты не из россии пишешь?

Я в Нью-Йорке сейчас.

На счет дергания си не знаю

Ну вот посмотри. Может быть, это проблему с сетевыми режимами порешает.

А если в C завезут defer, то он станет ещё лучше и количество ошибок деаллокации станет стремиться к нулю.

Зачем тогда вообще go, если я всё придется на си писать? Я имеено про go интересовался. Ведь он позиционируется как сетевой ЯП, а на деле с сетью работать не умеет.

Что это за язык? Паскаль?

Как там с коронавирусом?

Вот что бывает, когда рантайм не умеет в мономорфизацию классов.

Что там не так? Куда смотреть?

Там все так, просто куча коллекций вида MapIntLong для примитивных типов. Мономорфизация для бедных. Я бы даже сказал — для нищих. По сравнению с тем, что умеет делать мономорфизирующий компилятор, в который эта фича заложена изначально.

Я понимаю твой вопрос, могли бы такую фундаментальную вещь и сделать. С другой стороны, бесшовная интеграция с С там в языке заявлена изначально. Т.е. предполагается, что язык Го не совсем самостоятелен. Что-то придется писать на С.

Вроде живы пока. Хотя по началу, весной 2020-го, было страшно. А сейчас всё переоткрывается ударными темпами.