LINUX.ORG.RU

История изменений

Исправление Pwner, (текущая версия) :

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

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

Многие концепты сделаны в противоречии логики го.

Выходит зря Пайку предъявляли, что Go не привносит ничего нового, ведь он придумал новую логику, логику Go.

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

Это что-то про то, что статуя уже в камне, нужно просто найти её.

Вот есть у нас type SomeStruct {}. Если нам для создания типа достаточно &SomeStruct{}, то отдельную функцию-конуструктор создавать не надо.

А если не достаточно, то надо.

Можно жаловаться, нарекать и т.д.

Что можно делать?

Все эти врапперы над interface{}, либо List = []any - это все shallow abstractions. Ну не получится сделать так, как в расте, например.

Ты точно хочешь донести до нас какую-то осмысленную идею, а не чувство, которое у тебя возникло при написании поста?

Помимо редких исключений, мы принимаем интерфейс, а возвращаем всегда конкретный тип.

Конструкция такого рода является бредовой

Бредовым является твоё расстройство личности. Если автор использует рефлексию/кодогенерацию, возврат интерфейсов – элегантное и простое решение.

Я не понимаю, зачем встраивать какой-то тип в актора

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

Откуда вообще человек должен знать, что надо имплементировать такой метод?

Let me tell you about our lord and savior, convention.

И т.д., и т.п. ЛОР - не то место, где надо самоутверждаться, Микита.

Исправление Pwner, :

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

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

Многие концепты сделаны в противоречии логики го.

Выходит зря Пайку предъявляли, что Go не привносит ничего нового, ведь он придумал новую логику, логику Go.

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

Это что-то про то, что статуя уже в камне, нужно просто найти её.

Вот есть у нас type SomeStruct {}. Если нам для создания типа достаточно &SomeStruct{}, то отдельную функцию-конуструктор создавать не надо.

А если не достаточно, то надо.

Можно жаловаться, нарекать и т.д.

Что можно делать?

Все эти врапперы над interface{}, либо List = []any - это все shallow abstractions. Ну не получится сделать так, как в расте, например.

Ты точно хочешь донести до нас какую-то осмысленную идею, а не чувство, которое у тебя возникло при написании поста?

Помимо редких исключений, мы принимаем интерфейс, а возвращаем всегда конкретный тип.

Конструкция такого рода является бредовой

Бредовым является твоё расстройство личности. Если автор использует рефлексию/кодогенерацию, возврат интерфейсов – элегантное и простое решение (и ответ на твой следующий вопрос).

Я не понимаю, зачем встраивать какой-то тип в актора

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

Откуда вообще человек должен знать, что надо имплементировать такой метод?

Let me tell you about our lord and savior, convention.

И т.д., и т.п. ЛОР - не то место, где надо самоутверждаться, Микита.

Исправление Pwner, :

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

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

Многие концепты сделаны в противоречии логики го.

Выходит зря Пайку предъявляли, что Go не привносит ничего нового, ведь он придумал новую логику, логику Go.

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

Это что-то про то, что статуя уже в камне, нужно просто найти её.

Вот есть у нас type SomeStruct {}. Если нам для создания типа достаточно &SomeStruct{}, то отдельную функцию-конуструктор создавать не надо.

А если не достаточно, то надо.

Можно жаловаться, нарекать и т.д.

Что можно делать?

Все эти врапперы над interface{}, либо List = []any - это все shallow abstractions. Ну не получится сделать так, как в расте, например.

Ты точно хочешь донести до нас какую-то осмысленную идею, а не чувство, которое у тебя возникло при написании поста?

Помимо редких исключений, мы принимаем интерфейс, а возвращаем всегда конкретный тип.

Конструкция такого рода является бредовой

Бредовым является твоё расстройство личности. Если автор использует рефлексию/кодогенерацию, возврат интерфейсов – элегантное и простое решение.

Я не понимаю, зачем встраивать какой-то тип в актора

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

Откуда вообще человек должен знать, что надо имплементировать такой метод?

Let me tell you about our lord and savior, convention.

И т.д., и т.п. ЛОР - не то место, где надо самоутверждаться, Микита.

Исправление Pwner, :

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

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

Многие концепты сделаны в противоречии логики го.

Выходит зря Пайку предъявляли, что Go не привносит ничего нового, ведь он придумал новую логику, логику Go.

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

Это что-то про то, что статуя уже в камне, нужно просто найти её.

Вот есть у нас type SomeStruct {}. Если нам для создания типа достаточно &SomeStruct{}, то отдельную функцию-конуструктор создавать не надо.

А если не достаточно, то надо.

Можно жаловаться, нарекать и т.д.

Что можно делать?

Все эти врапперы над interface{}, либо List = []any - это все shallow abstractions. Ну не получится сделать так, как в расте, например.

Ты точно хочешь донести до нас какую-то осмысленную идею, а не чувство, которое у тебя возникло при написании поста?

Помимо редких исключений, мы принимаем интерфейс, а возвращаем всегда конкретный тип.

Конструкция такого рода является бредовой

Бредовым является твоё расстройство личности. Если автор использует рефлексию/кодогенерацию, возврат интерфейсов – элегантное и простое решение.

Я не понимаю, зачем встраивать какой-то тип в актора

встраивание - это вообще совершенно другое и с наследованием не имеет общего ровным счетом ни-че-го.

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

Откуда вообще человек должен знать, что надо имплементировать такой метод?

Let me tell you about our lord and savior, convention.

И т.д., и т.п. ЛОР - не то место, где надо самоутверждаться, Микита.

Исправление Pwner, :

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

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

Многие концепты сделаны в противоречии логики го.

Выходит зря Пайку предъявляли, что Go не привносит ничего нового, ведь он придумал новую логику, логику Go.

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

Это что-то про то, что статуя уже в камне, нужно просто найти её.

Вот есть у нас type SomeStruct {}. Если нам для создания типа достаточно &SomeStruct{}, то отдельную функцию-конуструктор создавать не надо.

А если не достаточно, то надо.

Можно жаловаться, нарекать и т.д.

Что можно делать?

Все эти врапперы над interface{}, либо List = []any - это все shallow abstractions. Ну не получится сделать так, как в расте, например.

Ты точно хочешь донести до нас какую-то осмысленную идею, а не чувство, которое у тебя возникло при написании поста?

Помимо редких исключений, мы принимаем интерфейс, а возвращаем всегда конкретный тип.

Конструкция такого рода является бредовой

Бредовым является твоё расстройство личности. Если автор использует рефлексию/кодогенерацию, возврат интерфейсов – элегантное и простое решение.

Я не понимаю, зачем встраивать какой-то тип в актора

встраивание - это вообще совершенно другое и с наследованием не имеет общего ровным счетом ни-че-го.

А зачем ты делаешь какие-то выводы, если о предмете не понимаешь?

Откуда вообще человек должен знать, что надо имплементировать такой метод?

Let me tell you about our lord and savior, convention.

И т.д., и т.п. ЛОР - не то место, где надо самоутверждаться, Микита.

Исходная версия Pwner, :

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

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

Многие концепты сделаны в противоречии логики го.

Выходит зря Пайку предъявляли, что Go не привносит ничего нового, ведь он придумал новую логику, логику Go.

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

Это что-то про то, что статуя уже в камне, нужно просто найти её.

Вот есть у нас type SomeStruct {}. Если нам для создания типа достаточно &SomeStruct{}, то отдельную функцию-конуструктор создавать не надо.

А если не достаточно, то надо.

Можно жаловаться, нарекать и т.д.

Что можно делать?

Все эти врапперы над interface{}, либо List = []any - это все shallow abstractions. Ну не получится сделать так, как в расте, например.

Ты точно хочешь донести до нас какую-то осмысленную идею, а не чувство, которое у тебя возникло при написании поста?

Помимо редких исключений, мы принимаем интерфейс, а возвращаем всегда конкретный тип.

Конструкция такого рода является бредовой

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

Я не понимаю, зачем встраивать какой-то тип в актора

встраивание - это вообще совершенно другое и с наследованием не имеет общего ровным счетом ни-че-го.

А зачем ты делаешь какие-то выводы, если о предмете не понимаешь?

Откуда вообще человек должен знать, что надо имплементировать такой метод?

Let me tell you about our lord and savior, convention.

И т.д., и т.п. ЛОР - не то место, где надо самоутверждаться, Микита.