Здравствуйте, Shmj, Вы писали:
S>Заметили ли вы, что C# уже не тот. Конечно, еще не догнал старшего собрата, но уже дофига концепций, которые вам могут показаться очевидными, но вот начинающим с нуля — доставят.
Нет, не заметил. Этот язык и всё остальное, что идёт к нему в комплекте, спроектированы так, чтобы сложность по возможности оставалась под капотом. Прямо чувствуется, что это один из принципов. Например, типичный программист не пишет алгоритмы и контейнеры, а пользуется ими. Можно всю жизнь программировать на Шарпе и не знать про ключевое слово `yield`. И не просто программировать, а продуктивно.
Что касается «старшего собрата», его нынешний дизайн определил человек, который этой границы в упор не видит. Достаточно прочесть знаменитую цитату про «методологически неверный» ООП.
А раз так, значит и сложность нечего сравнивать. Сама по себе она не решает.
Забыл сразу написать: вы сортировку в плюсах видели? Допустим, программисту надо отсортировать строки в файле. Чтобы успешно выполнить задачу, он уже должен осилить 1) концепцию итераторов и 2) дихотомию контейнеры/алгоритмы. А ведь это только вершина айсберга. Без неё можно было бы обойтись (и в других библиотеках обходились, однако стандартизировали самую упоротую). Но есть подводная часть айсберга, от которой трудно куда-то деться: например, контракт на разделение ответственности по управлению памятью. Про это программист тоже должен думать, знать и понимать, иначе он словит или утечку, или исключение.
Как можно после этого сравнивать толщину спецификаций? Какой в этом смысл? Сложность Шарпа упакована намного более разумно.
Здравствуйте, Философ, Вы писали:
Ф>Чтобы там улучшить читабельность, там надо как минимум не писать в одну строку:
Ф>
Ф>public int F() =>
Ф> (A is B b) && (b.C is C)?
Ф> C.D ?? 1
Ф> :FalseToNet ;
Ф>
Один хрен выглядит как perl.
Не надо так писать вообще.
Если можно написать более просто читаемый код — надо писать более просто читаемо, машине же всё равно.
Ф>Чтение и правка такого кода порождает ошибки. Поубивал бы!
Верно.
Здравствуйте, Shmj, Вы писали:
S>Заметили ли вы, что C# уже не тот. Конечно, еще не догнал старшего собрата, но уже дофига концепций, которые вам могут показаться очевидными, но вот начинающим с нуля — доставят.
Известный факт: уже в версии 3.0 спека C# была раза в полтора толще спеки С++.
Но в освоении С# всё же проще, т.к. проектировался изначально для более прикладных целей.
Вообще, опасность, конечно же, есть — сейчас язык развивается community, и многие решения принимаются не на основе взвешенного вдумчивого анализа, а просто потому, что кому-то взбрело в голову их принять, а остальным не хватило упорства противостоять энтузиазму.
Многие фичи языка, добавленные в 7/8/9/10, плохо или никак работают друг с другом.
Например, те же Expression Trees не поддерживают почти ничего из добавленного после C# 3.0.
Какие-то провалы потихонечку подтягивают — вот, к примеру, async enumerable. До него сочетать async pattern и enumerable pattern было невозможно.
Но это происходит медленнее, чем добавление новых фич.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Заметили ли вы, что C# уже не тот. Конечно, еще не догнал старшего собрата, но уже дофига концепций, которые вам могут показаться очевидными, но вот начинающим с нуля — доставят.
Просто смотрю С++ и уже не кажется таким уж сложным, т.к. в C# навязано множество концепций, которые тоже не просты.
Здравствуйте, Shmj, Вы писали:
vsb>>В Java тоже сложности накручивают потихоньку. Видимо это жизненный цикл любого языка. Я бы с удовольствием писал на Java 1.4-подобном языке. Считаю, что больше этого ничего не нужно.
S>Язык C появился в 1972 году и до сих пор не оброс всем этим хламом.
А ты уверен, что хорошо знаешь все фичи последних версий C? Про _Generic слышал?
S>Видимо потому что его взяли под покровительство люди, умеющие думать на десятилетия вперед — Национальный институт стандартов США и Международная организация по стандартизации.
Я считаю, что C де факто умер и заменён С++. Кто его там развивает, зачем, это вообще непонятно. По сути сейчас это какое-то достаточным произвольным образом взятое подмножество С++ (с кучкой несовместимостей, я в курсе, сути это не меняет).
Ф>>public int F() =>
Ф>> (A is B b) && (b.C is C)?
Ф>> C.D ?? 1
Ф>> :FalseToNet ;
Ф>>
CC>Один хрен выглядит как perl. CC>Не надо так писать вообще. CC>Если можно написать более просто читаемый код — надо писать более просто читаемо, машине же всё равно.
Ф>>Чтение и правка такого кода порождает ошибки. Поубивал бы! CC>Верно.
Долго думал, откуда у меня странное ощущение, что я одновременно согласен и не согласен.
Потом понял. Мне кажется, рассматривая псевдокод, можно доказать всё, что угодно: и что так нельзя писать, и что можно, и что нужно. Особенно такой, где заглавная A это инстанс, заглавная B — тип, а заглавная C — одновременно тип и свойство.
Здравствуйте, Serginio1, Вы писали:
S> Ну много они добавили для увеличения скорости те же Span.
При этом Span<> и Async несовместимы. Ну, это ещё можно простить. Но вот Span<> и генерики несовместимы; то есть нельзя построить тип, параметризованный каким-нибудь Span<int>.
Так что если вы хотите описать сигнатуру "функции, которая принимает Span<char> и возвращает нужный мне тип T", то использовать Func<Span<char>, T> нельзя — надо честно писать delegate T Parse<T>(Span<char> arg):
using System;
public class Program
{
public delegate T Parse<T>(ReadOnlySpan<char> span);
public static void Main()
{
Parse<DateTime> p = (ReadOnlySpan<char> c)=>DateTime.Parse(c);
Func<ReadOnlySpan<char>, DateTime> t = p; // oops!
}
}
никак не введут
Ну, не знаю. С одной стороны, роли нафиг не нужны при наличии static abstract members в интерфейсах.
С другой стороны, иногда хочется приклеить операторы к "чужим" типам.
Ну вот, скажем, если бы можно было как-то сделать B operator |(A value, Func<A, B> transform) => transform(value), то получился бы тот самый pipe operator, Math.PI | Math.Sin | Math.Cos == 1
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vsb, Вы писали:
vsb>В Java тоже сложности накручивают потихоньку. Видимо это жизненный цикл любого языка. Я бы с удовольствием писал на Java 1.4-подобном языке. Считаю, что больше этого ничего не нужно.
Язык C появился в 1972 году и до сих пор не оброс всем этим хламом. Видимо потому что его взяли под покровительство люди, умеющие думать на десятилетия вперед — Национальный институт стандартов США и Международная организация по стандартизации.
Здравствуйте, Shmj, Вы писали:
vsb>>В Java тоже сложности накручивают потихоньку. Видимо это жизненный цикл любого языка. Я бы с удовольствием писал на Java 1.4-подобном языке. Считаю, что больше этого ничего не нужно.
S>Язык C появился в 1972 году и до сих пор не оброс всем этим хламом. Видимо потому что его взяли под покровительство люди, умеющие думать на десятилетия вперед — Национальный институт стандартов США и Международная организация по стандартизации.
Здравствуйте, Jack128, Вы писали:
J> да дело не в скобках, а однобуквенных именах. Замени A,B,C,D на что нить типа Customer/Order/Price и всё нормально будет читаться.
Не будет. Будет нагромождение идентификаторов. Выкинуть элементы обеспечивающие семантическую связанность могут только оторванные от жизни утырки, которые кроме своих пятистрочников ничего больше не читали.
Здравствуйте, vsb, Вы писали:
vsb>Я считаю, что C де факто умер и заменён С++. Кто его там развивает, зачем, это вообще непонятно. По сути сейчас это какое-то достаточным произвольным образом взятое подмножество С++ (с кучкой несовместимостей, я в курсе, сути это не меняет).
А я вот, например, не вижу ниши, в которой выбор однозначно был бы в пользу C++, а ни какого-нибудь другого языка. А вот нишу для C вижу: всякое там внутриядерное программирование. В ядре редко встречаются хитрые алгоритмы и структуры данных, и в то же время, в ядре хочется очень точно понимать, что именно происходит.
Очень маловероятно, чтобы в новом проекте, не отягощенном наследственностью, в бы выбрал в качестве основного языка C++.
Так что на мой взгляд, это скорее C++ умер, а не C. Разлагатся он будет, конечно, еще очень долго.
В Java тоже сложности накручивают потихоньку. Видимо это жизненный цикл любого языка. Я бы с удовольствием писал на Java 1.4-подобном языке. Считаю, что больше этого ничего не нужно.
Здравствуйте, vsb, Вы писали:
S>>Язык C появился в 1972 году и до сих пор не оброс всем этим хламом.
vsb>А ты уверен, что хорошо знаешь все фичи последних версий C? Про _Generic слышал?
При этом, на тех платформах, на которых кроме Си — ничего другого нет, там и Си хорошо если соответствует стандарту Си 89, или какой там был последний лохматый стандарт
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, rudzuk, Вы писали:
R>>Здравствуйте, Serginio1, Вы писали:
S>>> Но вот читабельность пока значительно проще.
R>>Ога-ога,
читабельность прет! Надо больше сокращать! Долой синтаксический оверхед! S> Ну в принципе то читабельно. Это с непривычки. S>Но таких конструкций можно и на любом языке S> Конечно скобочки проставить лучше S>
S> public int F() =>
S> (A is B b) && (b.C is C) ? C.D ?? 1:FalseToNet ;
S>
да дело не в скобках, а однобуквенных именах. Замени A,B,C,D на что нить типа Customer/Order/Price и всё нормально будет читаться.
Здравствуйте, Serginio1, Вы писали:
S>читаемост только увеличивается.
Дык нет жеж
S> А то, что с непривычки не удобно, так менять мышление надо.
И опять напомню про Perl
Здравствуйте, CreatorCray, Вы писали: S>>читаемост только увеличивается. CC>Дык нет жеж
Увеличивается. Это — вполне органичная конструкция, значительно лучше, чем всякие "?.".
Так и читается: if (animal is Elephant e) e.Trumpet() => "если животное — это слон е, то пусть е протрубит"
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>> А то, что с непривычки не удобно, так менять мышление надо. CC>И опять напомню про Perl
Вот не надо сравнивать с перлом и регулярными выражениями!
Что тут непонятно? все прекрасно читается!
public int F() =>
(A is B b) && (b.C is C)
? C.D ?? 1
:FalseToNet ;
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Shmj, Вы писали:
S>Заметили ли вы, что C# уже не тот. Конечно, еще не догнал старшего собрата, но уже дофига концепций, которые вам могут показаться очевидными, но вот начинающим с нуля — доставят.
Здравствуйте, yenik, Вы писали:
S>>Можно всю жизнь программировать на Шарпе и не знать про ключевое слово `yield`. И не просто программировать, а продуктивно. Y>Только если програмировать в одиночку. А иначе молодые и горячие коллеги непременно ознакомят со всеми новейшими свистками и звночками.
Не соглашусь.
Это не свисток и не звонок, это языковой функционал, нужный для… как бы его назвать… менее прикладного кода (более системного или более хелперного). Перефразируя старый фильм, в командах может быть два типа людей, мой друг: одни заряжают yield, другие пользуются foreach.
Здравствуйте, Shtole, Вы писали:
.
S>Долго думал, откуда у меня странное ощущение, что я одновременно согласен и не согласен.
S>Потом понял. Мне кажется, рассматривая псевдокод, можно доказать всё, что угодно: и что так нельзя писать, и что можно, и что нужно. Особенно такой, где заглавная A это инстанс, заглавная B — тип, а заглавная C — одновременно тип и свойство.
Никогда бы не подумал, что этот пример кода вызовёт такую дискуссию
Конечно, не стоит писать в таком стиле как вы заметили
vaa>Вроде тоже неплохо, при этом кучу вещей(сертификат, пароль, привязки...) можно задать 3-я способами (env, cli, appsettings.json) vaa>На практике за простотой может скрываться примитивность(т.е. банальное отсутствие кучи возможностей, доступных из коробки в других каркасах и библиотеках).
А теперь собери это дело в контейнеры. С go можно уложиться в 6-7 Мб, с .net понадобится 100-200.
Здравствуйте, vsb, Вы писали:
vsb>В Java тоже сложности накручивают потихоньку. Видимо это жизненный цикл любого языка. Я бы с удовольствием писал на Java 1.4-подобном языке. Считаю, что больше этого ничего не нужно.
Джава была убога ещё тогда, когда C++ застыл в развитии. В джава мире котлин выглядит довольно интересным, но после плюсов — тоже скучен и неудобен
Здравствуйте, Sinclair, Вы писали:
S>Но это происходит медленнее, чем добавление новых фич.
Ну много они добавили для увеличения скорости те же Span. Немерлисты так долго ждали и разочаровались в Source Generator и в PM. А вот Reles http://rsdn.org/forum/dotnet/7749568.flat
Здравствуйте, Shmj, Вы писали:
S>Заметили ли вы, что C# уже не тот. Конечно, еще не догнал старшего собрата, но уже дофига концепций, которые вам могут показаться очевидными, но вот начинающим с нуля — доставят.
S>Просто смотрю С++ и уже не кажется таким уж сложным, т.к. в C# навязано множество концепций, которые тоже не просты.
S>Лет через 15 будет тот же вавилон, имхо.
S>Как то все по одному сценарию идет.
На самом то деле С# наверное уже сложнее. Одни деревья выражений чего стоят и еще больше хочется. Но все нововведения это увеличение скорости программирования и скорости выполнения.
Но вот читабельность пока значительно проще. Ну в конце то концов деньги то получать нужно не за сам факт программирования!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Marty, Вы писали:
M>При этом, на тех платформах, на которых кроме Си — ничего другого нет
Колво таких платформ уже исчезающе мало и стремительно уменьшается.
читабельность прет! Надо больше сокращать! Долой синтаксический оверхед!
Ну в принципе то читабельно. Это с непривычки.
Но таких конструкций можно и на любом языке
Конечно скобочки проставить лучше
public int F() =>
(A is B b) && (b.C is C) ? C.D ?? 1:FalseToNet ;
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Ну много они добавили для увеличения скорости те же Span. S>При этом Span<> и Async несовместимы. Ну, это ещё можно простить. Но вот Span<> и генерики несовместимы; то есть нельзя построить тип, параметризованный каким-нибудь Span<int>.
Ну стек и Async не совместимы Memory<T> S>Так что если вы хотите описать сигнатуру "функции, которая принимает Span<char> и возвращает нужный мне тип T", то использовать Func<Span<char>, T> нельзя — надо честно писать delegate T Parse<T>(Span<char> arg): S>
S>using System;
S>public class Program
S>{
S> public delegate T Parse<T>(ReadOnlySpan<char> span);
S> public static void Main()
S> {
S> Parse<DateTime> p = (ReadOnlySpan<char> c)=>DateTime.Parse(c);
S> Func<ReadOnlySpan<char>, DateTime> t = p; // oops!
S> }
S>}
S>
public static string Create<TState>(
int length, TState state, SpanAction<char, TState> action);
...
public delegate void SpanAction<T, in TArg>(Span<T> span, TArg arg);
Этот метод реализован для выделения строки, а затем предоставления доступного для записи промежутка, в который вы можете писать, чтобы заполнить содержимое строки во время ее создания. Обратите внимание, что в этом случае полезна только стековая природа Span<T>, гарантирующая, что span (который относится к внутреннему хранилищу строки) перестанет существовать до завершения конструктора строки, что делает невозможным использование span для изменения строки после завершения построения:
int length = ...;
Random rand = ...;
string id = string.Create(length, rand, (Span<char> chars, Random r) =>
{
for (int i = 0; chars.Length; i++)
{
chars[i] = (char)(r.Next(0, 10) + '0');
}
});
Теперь вы не только избежали выделения, но и записываете непосредственно в память строки в куче, что означает, что вы также избегаете копирования и вас не ограничивают ограничения по размеру стека.
никак не введут S>Ну, не знаю. С одной стороны, роли нафиг не нужны при наличии static abstract members в интерфейсах.
нее это как использоваие существующих операторов +,-,*,/,++, итд для алгеброических типов
S>С другой стороны, иногда хочется приклеить операторы к "чужим" типам. S>Ну вот, скажем, если бы можно было как-то сделать B operator |(A value, Func<A, B> transform) => transform(value), то получился бы тот самый pipe operator, Math.PI | Math.Sin | Math.Cos == 1
Ну вот Roles для этого и нужны
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Shmj, Вы писали:
S>Заметили ли вы, что C# уже не тот. Конечно, еще не догнал старшего собрата
эээ шта? КОГО ИМЕННО ты считаешь "старшим братом" C#? Жабу штоле??
S> но уже дофига концепций, которые вам могут показаться очевидными, но вот начинающим с нуля — доставят.
Можно подумать, кого-то волнуют "начинающие с нуля"! Начинаешь — пиши на Васике и не прыгай!
S>Просто смотрю С++ и уже не кажется таким уж сложным
А, ну да... совсем простой! Если одни хелловорлды писать Ты чтоб так говорить, написал ХОТЬ ЧТО-ТО больше 10 тыщ строк?
Здравствуйте, vsb, Вы писали:
vsb>В Java тоже сложности накручивают потихоньку. Видимо это жизненный цикл любого языка. Я бы с удовольствием писал на Java 1.4-подобном языке. Считаю, что больше этого ничего не нужно.
Здравствуйте, Shmj, Вы писали:
S>Заметили ли вы, что C# уже не тот. Конечно, еще не догнал старшего собрата, но уже дофига концепций, которые вам могут показаться очевидными, но вот начинающим с нуля — доставят.
Сам язык простой. Еще проще процесс компиляции. Это его плюсы.
Большинство нововведений косметические. легко выводятся из базовых случаев.
Взять хотя бы новую фишку field в свойствах.
нет ничего сложного. новичок ее скорее всего не будет использовать.
S>Просто смотрю С++ и уже не кажется таким уж сложным, т.к. в C# навязано множество концепций, которые тоже не просты.
В плюсах плюсов только два S>Лет через 15 будет тот же вавилон, имхо.
S>Как то все по одному сценарию идет.
Было бы неплохо, т.к. современные плюсы кажись попроще чем те что были в начале нулевых.
Здравствуйте, Serginio1, Вы писали:
S> Ну в принципе то читабельно. Это с непривычки. S>Но таких конструкций можно и на любом языке S> Конечно скобочки проставить лучше
прочитать можно всё что угодно. Я одно время бинари в hex-редакторе раглядывал. Только это не быстро.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Shtole, Вы писали:
S>Например, типичный программист не пишет алгоритмы и контейнеры, а пользуется ими. Можно всю жизнь программировать на Шарпе и не знать про ключевое слово `yield`. И не просто программировать, а продуктивно.
Даже не представляю как это возможно.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Serginio1, Вы писали:
Ф>>>прочитать можно всё что угодно. Я одно время бинари в hex-редакторе раглядывал. Только это не быстро. S>> Ну это разные вещи. Давай разберем
Ф>Если ты думаешь, что я это не разобрал, ты заблуждаешься — я умею читать код. Только я отличаю хорошо читаемый код от нечитабельного.
Ф>Чтобы там улучшить читабельность, там надо как минимум не писать в одну строку:
Ф>
Ф>public int F() =>
Ф> (A is B b) && (b.C is C)?
Ф> C.D ?? 1
Ф> :FalseToNet ;
Ф>
Ф>Чтение и правка такого кода порождает ошибки. Поубивал бы!
Ну я говорю, что код нужно правильно форматировать. Проблема в итоге не в операторах! Не в усложнении языка.
А вот по форматированию лучше уже вырабатывать стандарты. Мне так больше нравится
public int F() =>
(A is B b) && (b.C is C)
? C.D ?? 1
:FalseToNet ;
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Философ, Вы писали:
S>>Например, типичный программист не пишет алгоритмы и контейнеры, а пользуется ими. Можно всю жизнь программировать на Шарпе и не знать про ключевое слово `yield`. И не просто программировать, а продуктивно.
Ф>Даже не представляю как это возможно.
Это полбеды. Беда, когда не представляют люди из комитета по стандартизации.
Здравствуйте, vsb, Вы писали:
vsb>В Java тоже сложности накручивают потихоньку. Видимо это жизненный цикл любого языка. Я бы с удовольствием писал на Java 1.4-подобном языке. Считаю, что больше этого ничего не нужно.
Здравствуйте, Pzz, Вы писали:
Pzz>Очень маловероятно, чтобы в новом проекте, не отягощенном наследственностью, в бы выбрал в качестве основного языка C++. Pzz>Так что на мой взгляд, это скорее C++ умер, а не C. Разлагатся он будет, конечно, еще очень долго.
Если посмотреть, то всякие производительные библиотеки постоянно начинают писать на плюсах и нормально пишут. Потом для них пишут обёртки на Питоне и отдают математикам и data scientist'ам. С++ под капотом очень многих современных разработок, которые потом крутятся в том числе и на кластерах под управлением уже упоминавшегося Питона, но не только. И Альтернатив для плюсов тут не видно, никто ни на чём другом их и не пишет. Хотя новые языки разрабатываются под это дело регулярно.
S>>>Можно всю жизнь программировать на Шарпе и не знать про ключевое слово `yield`. И не просто программировать, а продуктивно. Y>>Только если програмировать в одиночку. А иначе молодые и горячие коллеги непременно ознакомят со всеми новейшими свистками и звночками.
S>Не соглашусь.
S>Это не свисток и не звонок, это языковой функционал, нужный для… как бы его назвать… менее прикладного кода (более системного или более хелперного). Перефразируя старый фильм, в командах может быть два типа людей, мой друг: одни заряжают yield, другие пользуются foreach.
Значит, у нас разный опыт. Я давно уже не сталкивался с теми, кто не использует yield, притом во вполне прикладном коде.
Здравствуйте, yenik, Вы писали:
Y>Значит, у нас разный опыт. Я давно уже не сталкивался с теми, кто не использует yield, притом во вполне прикладном коде.
Как я понимаю, yield тут только в качестве примера. Слово такое.
Могу привести другой пример, правда, ретроградский и из Фортрана. В нем есто несколько типов GOTO: безусловный, вычисляемый, назначаемый. О двух последних я знаю только то, что они существуют. Сам, когда работал на Фортране, их не использовал никогда. В реальном коде видел, может, дважды за всю жизнь.
Подобные редко используемые вещи можно найти в любом языке. В шарпе тоже.
Здравствуйте, mrTwister, Вы писали:
vsb>>В Java тоже сложности накручивают потихоньку. Видимо это жизненный цикл любого языка. Я бы с удовольствием писал на Java 1.4-подобном языке. Считаю, что больше этого ничего не нужно.
T>Бери GO
Да, прикольный язык, если бы я сейчас начинал, возможно это был бы хороший совет, а так с 10 лет опыта на жаве уже сложно куда-то дёргаться. Хотя они там тоже шаблоны какие-то прикрутили и вроде как тоже кривовато, в общем подозреваю, что и Go не минет чаша сия, просто он пока слишком молодой.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Serginio1, Вы писали:
S>> Вот не надо сравнивать с перлом и регулярными выражениями! S>> Что тут непонятно? все прекрасно читается!
Ф>Понятно всё, но читается не очень.
Ну что мне сказать стареешь. Элементарные вещи. Это как пришли замыкания в язык. Большинство по первости были категорически против.
Прошло время и все прекрасно их используют.
Но Проще конечно Pattrn matching вместо
public int F() =>
(A is B b) && (b.C is C)
? C.D ?? 1
:FalseToNet ;
напишем так
public int F() =>
A swith
{
B b when b.C is C => C.D ?? 1,
_=>FalseToNet;
};
Здравствуйте, vsb, Вы писали:
vsb>Да, прикольный язык, если бы я сейчас начинал, возможно это был бы хороший совет, а так с 10 лет опыта на жаве уже сложно куда-то дёргаться. Хотя они там тоже шаблоны какие-то прикрутили и вроде как тоже кривовато, в общем подозреваю, что и Go не минет чаша сия, просто он пока слишком молодой.
Go ценен не столько даже самим языком, сколько комьюнити, сформировавшим идиомы языка, в которых простота является основной ценностью. В Go все крутится вокруг простоты: стандартные библиотеки, 3-party библиотеки, и реальный production код. Просто для примера, это код http сервера на го:
В примере нет никаких тебе IoC контейнеров, фабрик, аннотаций, фреймворков. И там весь код такой: простой и прямолинейный. Все задачи принято решать в лоб, ценится максимально простое и прямолинейное решение.
Здравствуйте, vsb, Вы писали:
vsb>Да, прикольный язык, если бы я сейчас начинал, возможно это был бы хороший совет, а так с 10 лет опыта на жаве уже сложно куда-то дёргаться. Хотя они там тоже шаблоны какие-то прикрутили и вроде как тоже кривовато, в общем подозреваю, что и Go не минет чаша сия, просто он пока слишком молодой.
У меня 20 лет основной 1С был. Да немного на Delphi и C# программировал. Бросил 1С перешел на C# и не жалею.
Всегда можно параллельно что то изучать и в итоге сменить ориентацию (не половую)!
и солнце б утром не вставало, когда бы не было меня
T>Go ценен не столько даже самим языком, сколько комьюнити, сформировавшим идиомы языка, в которых простота является основной ценностью. В Go все крутится вокруг простоты: стандартные библиотеки, 3-party библиотеки, и реальный production код. Просто для примера, это код http сервера на го: T>
T>В примере нет никаких тебе IoC контейнеров, фабрик, аннотаций, фреймворков. И там весь код такой: простой и прямолинейный. Все задачи принято решать в лоб, ценится максимально простое и прямолинейное решение.
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Run();
Вроде тоже неплохо, при этом кучу вещей(сертификат, пароль, привязки...) можно задать 3-я способами (env, cli, appsettings.json)
На практике за простотой может скрываться примитивность(т.е. банальное отсутствие кучи возможностей, доступных из коробки в других каркасах и библиотеках).