Два вопроса.

1. Дженерики уже завезли, или 11й год всё обсуждают?
2. Если Go - ЯП со сборщиком мусора, почему он не собрал Go?

Жду, когда завезут классы или прототипы как в JS, очень не хватает… чтобы полноценные сетевые игровые движки писать

А ещё в GCC там какая-то кривая реализация горутин, тупо на потоках, и только для Линукс, тоже мне, GNU

Дженерики завезут только в Go 2

На тот случай, если будет срач

Да, это всё нужно. Нет, плюсовое ООП не обязательно для написания нормальных программ. Хватит тут флудить, сперва дебейся.

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

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

class Entity {
  var position
  function move(to) {
     this.position = to
  }
}

// наследуем
class Cat(Entity) {
  this.position = Position(x: 0, y: 100)

  function inPosition() {
    this.position.y != 0
    and
    this.position.x != 0
  }
}

https://play.golang.org/p/TycWw_GygfL

package main

import (
	"fmt"
)

type entity struct {
	position int
}

func (e *entity) move(x int) {
	e.position = x
}

type cat struct {
	entity
}

func (c *cat) inPosition(x int) bool {
	if c.position == x {
		return true
	}
	return false
}

func main() {
	c := &cat{}
	c.move(5)
	fmt.Println("in position 3: ", c.inPosition(3))
	fmt.Println("in position 5: ", c.inPosition(5))
}

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

Страшненько. Я не критикую решение, а про то как выглядит Go в целом.

да, когда аргументы заканчиваются, наступает субъективщина :). лично мне нравится его лаконичность и простота чтения. такой код можно буквально читать, а не «что хотел сказать автор».

когда аргументы заканчиваются

У меня их вообще нет. Просто мимокрокодил и косо поглядываю, а вдруг «на потыкать».

Второй из лучших языков программирования (первый — C) стал еще лучше.

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

А вот этот кусок в go не перенесся никак?

this.position = Position(x: 0, y: 100)

чтобы полноценные сетевые игровые движки писать

Алё, гараж! Сборщик мусора же. Какие такие игровые движки?

А где его нет? Либо ты руками его собираешь, либо за тебя это делает робот, либо в гибридном режиме. Minecraft Server написан же под Java, а там ваще память не жалеют и не парятся насчёт тормозных GC

А где его нет?

Я уже хотел возразить, но потом подумал, что реальность-то на твоей стороне, а я становлюсь слишком стар.

Писать игровые сервера на Go, Java или даже Python можно, если SLA по задержкам можно выдержать. А вот игровые дивижки, которые графику рисуют, — это надо, чтобы в event loop память бралась только из пулов.

Но ты, наверное, имел в виду игровые сервера, так?

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

да, когда аргументы заканчиваются, наступает субъективщина :) лично мне нравится его лаконичность и простота чтения. такой код можно буквально читать, а не «что хотел сказать автор».

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

:= &cat{}

какой-то перл напоминает и не кажется удобным для чтения.

пример menangen кажется короче и легче читаемым. субъективно.

джавский gc это просто batch оптимизация тяжелых операций, которые выполняют все другие сборщики

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

Сборщики более-менее неплохо себя показывают на сетевых приложениях, где (почти) все объекты короткоживущие и сразу вычищаются. А вот базу данных или кэш делать в управляемой сборщиком куче — это нарываться на задержки в минуты и более. Что в Java, что в Go.

Когда ++ завезут? Или содомитов из гугла от крестов воротит?

Когда ++ завезут?

Все пути ведут в C++

type entity struct {
	position int
}

func (e *entity) move(x int) {
	e.position = x
}

type cat struct {
	entity
}

func (c *cat) inPosition(x int) bool {
	return c.position == x
}

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

Люди пишут, что в некоторых реальных приложениях 40% ускорение за счёт передачи аргументов в регистрах. Вот это да.

Для игр используется пул. Объекты, созданные в течение отрисовки кадра, потом хлопаются все разом. Тут и выделение очень быстрое и удаление очень быстрое.

GC делает удаление долгим и, что самое страшное, непредсказуемым. Если у тебя есть 144 FPS, у тебя есть примерно 6 мс на каждый кадр. Из них, скажем, 5 уйдут на обработку логики. Ни один GC не гарантирует, что он не потратит больше 1 мс.

Точней есть реалтаймовые GC, но это экзотика.

На самом деле в теории, думаю, можно сделать GC, затюненный именно на игровой движок. Но на практике проще пользоваться C++.

Дженерики уже завезли, или 11й год всё обсуждают?

Некротема. Каждый, кто хотел это дерьмо уже взял в рот это дерьмо.

Насколько я знаю, GC в Go вполне хорошо оптимизирован, и быстрее того, что в JVM по дефолту

Когда уже нормальный язык придумают

Нет смысла множить сущности.

По стопам Go уже придумали https://github.com/vlang/v

кому и COBOL нормальный язык. На вкус и цвет фломастеры разные, каждый ЯП подчеркивает индивидуальность программиста и многое о нём говорит. Упёртые используют плюсы, растаманы ruby, шарпом мажоры, java родители этих мажоров, педанты использую паскаль, анархисты обмазываются сями и нодойжс и т.д.

А ещё в GCC там какая-то кривая реализация горутин, тупо на потоках, и только для Линукс, тоже мне, GNU

Есть реализация на LLVM.

Дженерики завезут только в Go 2

Дженерики не нужны. Go 2 не нужен.

У меня их вообще нет. Просто мимокрокодил и косо поглядываю, а вдруг «на потыкать».

Тыкайте на здоровье https://tour.golang.org/welcome/1

Если бы дженерики были не нужны, то их бы не делали. С Go 2 такая же логика, просто так ничего не делается, разве что Just for fun.

Кстати, а какие там будут дженерики: как в Java, когда тип приводится к общему, или как в раст/C++ templates, когда для каждого типа генерируется своя функция?

только в Go 2

Который будет Go 1.18

А вот как! Я просто только иногда интересуюсь как там у go, видимо новость про 1.18 пропустил.

Если бы дженерики были не нужны, то их бы не делали.

Да, и какого-то хрена они наполовину пересекаются с интерфейсами. «Общественный запрос», что ещё сказать.

… анархисты обмазываются сями и нодойжс и т.д.

Намек на Linux?

Го 1.х не может выйти за рамки, из-за обещания совместимости.

А Go 2 может:

https://go2goplay.golang.org/

(хоть и выглядит это довольно глупым и лапшевидным переписыванием интерфейсов под какую-то новую странную сущность)

(Или я просто не понял в чём там юмор \0/)

https://go2goplay.golang.org/

Светлое будущее

func Print[T any](s []T) {

 for _, v := range s {
  fmt.Print(v)
 }

}

https://go2goplay.golang.org/p/0DWHgVVsX5P

Так светлее

А вообще, вот более менее https://threkk.medium.com/go-2-generics-in-4-minutes-fa50dda91d7c по теме.

какой-то перл напоминает и не кажется удобным для чтения

Go ещё ничего, вот Rust в этом смысле полный отстой.

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

Поэтому там, где важна latency (игры и трейдинг, как минимум) нельзя выделять память на пути обработки данных.

Поэтому я вообще не понимаю прикола использования языков, сильно заточенных на gc без этого самого gc (как объяснили, через пулинг всего и вся). То есть это получается какой-то убогий и абсолютно неестественный сабсет, в разы хуже чем «С++ без исключений».

В плюсах хотя бы можно арены делать или через деструкторы нормально следить за ресурсами.

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

Поэтому я вообще не понимаю прикола использования языков, сильно заточенных на gc без этого самого gc (как объяснили, через пулинг всего и вся). То есть это получается какой-то убогий и абсолютно неестественный сабсет, в разы хуже чем «С++ без исключений».

А пуллинг не спасает от GC-паузы. Пуллинг спасает от выделения у системы памяти больше чем надо.

Это работает так

• нужен объект
• если памяти нет, запрос у системы
• объект освободился, но пока GC его не собрал он ещё есть

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

Ключевое здесь «между GC-паузами», потому что сборщик всё равно его соберёт. И возвращать системе память он не торопиться.

Это имеет смысл, например, когда в коротком промежутке создаётся и освобождаются множество объектов.

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

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

Вот в чем вопрос

Из говна и палок дворец не построишь …