Go 1.26

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

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

Всё так. Но что в этом плохого то? Это важная ниша.

Не знаю что может это изменить.

И не надо это менять.

PHP совершил качественный скачок став в 2–3 раза быстрее старых версий и в некоторых задачах вплотную приближается к компилируемым языкам.

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

высоконагруженные системы на PHP теперь обходятся дешевле в обслуживании, чем аналоги на Python или Ruby.

Думаю это и раньше так было. Питон и руби та же скриптота, только ещё и неудобная.

Помимо этого, PHP перестал быть языком «пиши как хочешь».

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

В общем случае нет. При смене мажорной версии обычно что-то ломают в обратной совместимости. Используется ли это что-то в конкретном проекте надо смотреть. Обычно в версии -1 это что-то было deprecated и писало в лог соответствующее предупреждение

Репорты

Мы делали фин отчёты на клике под прослойкой Go.

Это запрещено, чтобы не возникло указателей на стек. Которые потом уходят за пределы вызова.

А в примере с x := int64(300) из текста новости - какой именно механизм говорит что x размещается в куче, а не на стеке? (не знаю деталей go)

я думаю что предложенный синтаксис &int64(300) мог бы обеспечивать использование кучи для размещения возвращаемого из функции значения

Я не очень понимаю в чём вообще претензия к го. В го сборщик мусор. Это по-умолчанию не самый быстрый язык и, если упираться в сборку мусора, не самый удобный. Какие-то непредвиденные кейсы будут страдать. В этом, наверное, даже C будет удобнее. Но это нишевый кейс, который не делает язык C самым лучшим на свете.

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

А в примере с x := int64(300) из текста новости - какой именно механизм говорит что x размещается в куче, а не на стеке? (не знаю деталей go)

Это escape analyzer решает. Если он увидит, что объект уходит куда-то, то разместит его на куче. Иначе на стеке.

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

package main

import (
	"fmt"
)

type User struct {
	Name string
	Age  int
}

func Ptr[T any](a T) *T {
	return &a
}

func ptr(a int) *int {
	return &a
}

func get3() int {
	return 3
}

func alice() User {
	return User{"Alice", 19}
}

func some(x int, y User) {

	var (
		a = &User{"Alex", 21} // ok
		b = &x                // ok
		c = &y                // ok
		d = ptr(3)            // ok
		e = Ptr(3)            // ok
		f = &get3()           // invalid operation: cannot take address of get3() (value of type int)
		g = &3                // invalid operation: cannot take address of 3 (untyped int constant)
		h = &alice()          // invalid operation: cannot take address of alice() (value of struct type User)
	)

	fmt.Println("Hello,", a, b, c, d, e, f, g, h)
}

func main() {
	some(1, User{"Eva", 20})
}

go.dev/play

Прикол в том, что &User{} нормально. А &3 – нет. И об этом даже Роб Пайк уже писал, возмущался. И было предложение это всё разрешить делать.

Что касается &int64(300) и &300 – это запрещено, чтобы избежать дрисни вида t := &(a + 15 + x^10 + b&7).

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

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

И в каком файле там есть пример запредельно переусложнённых конструкций Java?

Во всех.

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

А на мой взгляд не верно.

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

Я на Java начал писать примерно через 5 минут после знакомства с ней. Будучи студентом, работающим на полставки. Я не знаю, о каком пороге входе речь. У джавы он точно околонулевой. У го чуть больше, но, конечно, тоже не намного, я лично го выучил примерно за час, полистав официальный сайт. Так что по личному примеру могу оценить порог входа в Го примерно в 12 раз выше чем в Java.

а если еще сравнить не только языковые конструкции, но и набор аргументов для jvm (в свое время намучался с тюнингом кассандры), то это как пушинка против бульдозера.

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

Java сложнее. Там непонятно как это запустить 🙂.

У джавы он точно околонулевой.

Поэтому в штатах она в школах преподавалась как у нас в свое время Pascal.

Нужно.

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

Раньше была мода на собеседованиях спрашивать про настройку ГЦ. Никто его не настраивал, но все спрашивали. Кажется, сейчас уже эта мода прошла.

Я на Java начал писать примерно через 5 минут после знакомства с ней.

А читать?

Попробовал я составить план объяснения hello world. Рассмотрел три языка: C, Go, Pascal (в последнюю очередь). Это невозможно сделать хорошо на C или Go. То, что программисту кажется просто — не просто для обычного человека. Вместо простой вводной приходится говорить «потом узнаешь что это такое» (а эта вещь имеет накопительный эффект). Объяснение на утках тоже не работает — оно не несёт никакой интеллектуальной пользы кроме склеивания плохого материала. Нужна осмысленная конкретика. Избирательное уклонение от ответов создаёт впечатление будто программирование — это запоминание магических слов.

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

(В целом, паскаль ведь для этой задачи и создавался. Только потом его сделали монстром. А Java — язык индустрии изначально. Простым его принято называть только между нами.)

А читал я её интуитивно.

Не, у меня был чит в виде хорошего знания C++. Но вроде его везде преподают, так что хз.

Я не очень понимаю в чём вообще претензия к го. В го сборщик мусор. Это по-умолчанию не самый быстрый язык и, если упираться в сборку мусора, не самый удобный. Какие-то непредвиденные кейсы будут страдать. В этом, наверное, даже C будет удобнее. Но это нишевый кейс, который не делает язык C самым лучшим на свете.

У меня пока в этом топике нет и не было претензий к Go, была претензия к конкретному утверждению, что переписав с Go на Go, но только мол ПРАВИЛЬНО, можно было бы добиться того же, что и на Rust + Tokio, разницы нет, а в условном Cloudflare сидят дураки, сервят треть интернета, а ПРАВИЛЬНО писать за 10 лет на Go так и не научились.

Появилась строгая типизация

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

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

высоконагруженные системы на PHP

Оксюморон. Высоконагруженные системы уже давно пишут на языках с (co_)async/(co_)await..

(co_)async

(co_) не нужно..