Re[71]: MS забило на дотнет. Питону - да, сишарпу - нет? - Компьютерные священные войны

Здравствуйте, vdimas, Вы писали:

V>>>Статья от 2018-го.

I>>С разморозкой — нынче сентябрь 2021.
I>>Ты бы роадмап глянул? 2018й это выход 3.0. На сегодня актуальна 4.4

V>Это всё копейки и на суть обсуждаемого в той статье не влияет.

Это влияет на твоё утверждение "TypeScript с тех пор практически не изменился"
Изменился и очень сильно, благодаря чему переход на TypeScript теперь норма.

Основные претензии JS разработчиков были в том, что:
1 типы добавляют много дополнительного кода. Собственно, именно это препятствие теперь устранено благодаря улучшеному выводу типа и всяким плюшкам вокруг него построеным, type narrowing, control flow analysis и тд.
2 перформанс компилятора — улучшился в разы
3 слабоватая поддержка редакторами — compiles services теперь адекватные, навигация, рефакторинг, интеллисенс теперь заруливают любой жээс редактор.

Вот история версий, кликаешь в каждую с сегодняшнего дня и до 18го года, т.е. до 3.3
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-4.html

V>Особенно "более лучший вывод типов" и "туплы-генерики".

Туплы-генерики это крайне полезная фича:

type Parameters<T extends (...args: any) => any> = T extends (...args: infer P) => any ? P : never;

function x(a: string, b: number) {
...
}

type Params = Parameters<x>; // [string, number]

Здесь кроме infer есть conditional type. С помощью этой вещи можно объявить, например, какой нибудь хитрый рекурсивный тип, где у чилдренов правила могут меняться в зависимости от контекста. А можно сделать парсинг типа, примерно так http://rsdn.org/forum/philosophy/7967480.1

Вот еще:

type Readonly<T> = {
    readonly [P in keyof T]: T[P];
};

// теперь просто так не получится изменить x.

Таких комбинаторы крайне полезные!

Здравствуйте, Ikemefula, Вы писали:

V>>Это всё копейки и на суть обсуждаемого в той статье не влияет.
I>Это влияет на твоё утверждение "TypeScript с тех пор практически не изменился"

Верное утверждение.

I>Изменился и очень сильно, благодаря чему переход на TypeScript теперь норма.

Но суть изменений озвучить не в состоянии?

I>Основные претензии JS разработчиков были в том, что:
I>1 типы добавляют много дополнительного кода. Собственно, именно это препятствие теперь устранено благодаря улучшеному выводу типа

Т.е. исправили старые недостатки не повлияв на сам язык?
Рука-лицо.

I>и всяким плюшкам вокруг него построеным, type narrowing, control flow analysis и тд.

Не имеет отношения к языку.

I>2 перформанс компилятора — улучшился в разы

Не имеет отношения к языку.

I>3 слабоватая поддержка редакторами — compiles services теперь адекватные, навигация, рефакторинг, интеллисенс теперь заруливают любой жээс редактор.

Не имеет отношения к языку.

I>Вот история версий, кликаешь в каждую с сегодняшнего дня и до 18го года, т.е. до 3.3
I>https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-4.html

Из заметных изменений собсно языка — static blocks.
Остальное — исправление прошлых косяков с выводом типов, в т.ч. уточнение семантики генериков.

Я всё еще хочу услышать внятное объяснение, каким образом этот, допустим, новый static block отменяет написанное в статье от 2018-го?

V>>Особенно "более лучший вывод типов" и "туплы-генерики".

I>Туплы-генерики это крайне полезная фича:

Полезная для виляния? ))
Ты сделал утверждение — статья устарела.
Я прошу показать — в каком из своих утверждений?

I>Вот еще:
I>[code]
I>type Readonly<T> = {
I> readonly [P in keyof T]: T[P];
I>};

В статье речь примерно о таких вещах.
Ты статью-то читал?

После твоих ответов понятно что нет.
Т.е. даже не в курсе с чем споришь.
ОК.

Здравствуйте, Serginio1, Вы писали:

S>В 8.2 и 8.3 в управляемых формах работают только через сервер приложений.

Что такое "управляемая форма" 1С?

V>>А такого механизма заведомо нет, я смотрел схемы таблиц, которые создаёт на серваке 1С — в таблицах нет служебного поля для целей поддержки когерентности клиентских кешей.
S> Есть. Назыыватся версия.Это время.

Время не является надёжным токеном версии.

Здравствуйте, vdimas, Вы писали:

I>>Изменился и очень сильно, благодаря чему переход на TypeScript теперь норма.

V>Но суть изменений озвучить не в состоянии?

Cуть изменений, о которых я сказал, — препятствия для перехода устранены.

I>>Основные претензии JS разработчиков были в том, что:
I>>1 типы добавляют много дополнительного кода. Собственно, именно это препятствие теперь устранено благодаря улучшеному выводу типа

V>Т.е. исправили старые недостатки не повлияв на сам язык?
V>Рука-лицо.

Наоборот — изменили язык, добавив конкретные фичи.

I>>и всяким плюшкам вокруг него построеным, type narrowing, control flow analysis и тд.

V>Не имеет отношения к языку.

Наоборот. Язык это не только синтаксис.

I>>2 перформанс компилятора — улучшился в разы

V>Не имеет отношения к языку.

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

I>>3 слабоватая поддержка редакторами — compiles services теперь адекватные, навигация, рефакторинг, интеллисенс теперь заруливают любой жээс редактор.

V>Не имеет отношения к языку.

Наоборот — это инфраструктура для обозначеного языка. Связь более чем очевидная.

Еще одна причина — малое количество тайпингов для готовых либ. Она тоже решена. Часть проектов перешли на TypeScript, часть запилили руками и предлагают тайпинги искаропки, часть имеют 3d-party поддержку, которая стала проще.

I>>Вот история версий, кликаешь в каждую с сегодняшнего дня и до 18го года, т.е. до 3.3
I>>https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-4.html

V>Из заметных изменений собсно языка — static blocks.

А это фича как раз JavaScript, а не ТайпСкрипт

Основные фичи тайпскрипта находятся в тех самых типах — интерфейсы, дженерики, вывод типа и тд и тд и тд.

V>>>Особенно "более лучший вывод типов" и "туплы-генерики".

I>>Туплы-генерики это крайне полезная фича:

V>Полезная для виляния? ))
V>Ты сделал утверждение — статья устарела.
V>Я прошу показать — в каком из своих утверждений?

Читай сам:
"However, this comes at a cost. TypeScript, requires much more time to compile."

Похоже, что ты свою же ссылку то и не прочел

I>>Вот еще:
I>>

I>> type Readonly<T> = {
I>>  readonly [P in keyof T]: T[P];
I>> };
I>>

V>В статье речь примерно о таких вещах.

Смотрим вместе ту самую статью:
https://hackernoon.com/why-i-no-longer-use-typescript-with-react-and-why-you-shouldnt-either-e744d27452b4
И видим, что единственный кусочек кода это "javascript.implicitProjectConfig.checkJs": true
И никакого прямого упоминания вещей навроде Readonly нет и близко. Просто общие утверждения, что автору статьи неудобно то тут, то там.
И даже он утверждает, что ителисенс и прочие плюшки работают шикарно.
Собственно, теперь видно, кто из нас статью не читал

Здравствуйте, vdimas, Вы писали:
S>>Неожиданно оказалось, что драйвер с эквивалентным кодом таки существует.
V>Чё-та в голос уже...
V>Несерьёзный ты человек, однако.
V>Но за юмор спасибо.
Я описывал то, что можно сделать разработчику драйвера, оставаясь в рамках стандартной библиотеки, предполагая, что авторы драйверов к конкретным базам будут делать именно так.

А вам последовательно казалось, что
а) никто в реальности так не делает
б) при работе со всеми основными СУБД всё равно нужно пользоваться неэффективным ODBC-драйвером.

Ваши предположения оказались неверными, мои — верными.
Если для вас это — юмор, то ок. Я тоже посмеялся.

S>>Это не "простейшие" случаи; это смена типа поля при чтении. Надо полагать — не самый частый случай.

V>У кого как.
V>В дотнете типы short/ushort, sbyte/byte неудобны для оперирования, бо весь АПИ расписан на знаковом int, но в БД эти типы удобны и популярны для суррогатных ключей заведомо небольших справочных данных.
Дело даже не в API, а в том, что в дотнете в принципе нет никакой арифметики на коротких типах.
Не работает даже так:

short a = 1;
a = a + (short)1;

Но это совершенно не имеет отношения к взаимодействию с СУБД.
Достаточно писать код вот так:

int a = 0;
...
a += ds.GetShort(0); //

В данном случае вся арифметика на стороне клиента — в интах, в драйвере нет никаких преобразований, и при этом ещё и код — ровно такой же длины, как и c ds.GetInt(0).

Ну, и это всё — в предположении, что разработчики БД будут экономить байты. Сейчас в реальности для суррогатных ключей заведомо небольших справочных данных применяют ровно int32, для длинных данных — int64, для распределённой генерации — guid.

Здравствуйте, vdimas, Вы писали:

V>Какую именно МОЮ ошибку?
Вы перепутали два совершенно разных коннектора.

V>>>Т.е. одновременно и "помойка", и "что попало", и "надо было взять его".

S>>Ну нет конечно. Найдите десять различий в адресах:
S>>1. Помойка: https://github.com/mysql/mysql-connector-net
S>>2. Не помойка: https://github.com/mysql-net/MySqlConnector
V>Июль 2020.
V>И до этого жизни в дотнете не было, судя по всему?
А если копнуть в 2001 год, то там и генериков-то не было.
Мы же говорим про сейчас, а не про тёмное прошлое.

V>Разница в том, что я говорю как в дотнете обстоят дела де-факто, а ты даёшь что-то свежеиспечённое от двух неких чуваков:
V>https://github.com/bgrainger
V>https://github.com/caleblloyd
V>на коленке с 0-ля написавших альтернативу официальному драйверу от Оракла.

V>Теперь берём некий боевой новый проект и вот мелькнула мысль взять с гитхаба код этих двух чуваков...
Не, давайте так. Посмотрим, к примеру, на EntityFramework 6 и проект, который на три четверти написан каким-то чудиком с гитхаба. На какой сам сядешь, на какой маму посадишь?

V>Ничего против этой парочки не имею, конечно... но ты примерно представляешь объем тестов корректности, которые потребуется написать, чтобы принять решение — стоит рисковать брать самописный левый драйвер в боевую разработку или нет?
Конечно представляю. Вот они: https://github.com/mysql-net/MySqlConnector/tree/master/tests

V>Представь, что решения принимаешь ты и отвечаешь за них тоже ты, в т.ч. возможным банкротством.
V>Я так думаю, что ты никаких тестов писать не будешь, тихонько возьмёшь официальный драйвер, как это делают 99.99% разработчиков и забъёшь на разницу в эффективности болт.
Для начала: 99.99% разработчиков никаким банкротством ни за что не отвечают. Ну, вот взять хотя бы вас. Не сможете вы внести багу, которая вашу компанию к банкротству приведёт. И даже если сможете, то отвечать за это никак не будете — иначе вы были бы собственником, а не наёмным инженером.

Далее: бага может обнаружиться в любом коде. В том числе — и в оракловом. Что ж вы не боитесь ответить банкротством за баги Оракла?

V>Зато здесь ля-ля-ля разводить так удобно, потому что безопасно...
Пошёл уже феерический бред. Я правильно понимаю, что вам не пришло в голову то, что смена драйвера — это не самая сложная процедура? Ну, то есть если вдруг окажется, что нормальный драйвер вдруг уже оказался хуже, чем оракловое говно?

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Serginio1, Вы писали:

S>>В 8.2 и 8.3 в управляемых формах работают только через сервер приложений.

V>Что такое "управляемая форма" 1С?
Это трехзвенка. То есть нет прямого доступа к базе. Только через сервер приложений.
Но можно в модуле писать как клиентский так и серверный код

V>>>А такого механизма заведомо нет, я смотрел схемы таблиц, которые создаёт на серваке 1С — в таблицах нет служебного поля для целей поддержки когерентности клиентских кешей.
S>> Есть. Назыыватся версия.Это время.

V>Время не является надёжным токеном версии.
Ну думаю 10 миллионной части секунды хватит. Но в принципе они могут 8 байтов использовать как угодно. Они и Guid там где время используют как автоинкремент 32 элементов.
Но это не суть. Они его используют для проверки когерентности

Здравствуйте, Serginio1, Вы писали:

V>>Что такое "управляемая форма" 1С?
S>Это трехзвенка. То есть нет прямого доступа к базе. Только через сервер приложений.

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

V>>Время не является надёжным токеном версии.
S>Ну думаю 10 миллионной части секунды хватит.

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

S>Но это не суть. Они его используют для проверки когерентности

Ну, если их кеш считает объекты в течении 20 сек валидными в условиях конкурентного доступа к базе, то это очень широкое допущение, ес-но. ))

Здравствуйте, vdimas, Вы писали:

V>Ну, если их кеш считает объекты в течении 20 сек валидными в условиях конкурентного доступа к базе, то это очень широкое допущение, ес-но. ))
Как я писал у них есть кластеры на разных машинах. Если на одном то проблем нет, так все идет через сервер. Если 2 то может обмениваться измененными объектами.
https://habr.com/ru/company/1c/blog/493008/
http://www.gilev.ru/app1c/

Здравствуйте, Ikemefula, Вы писали:

V>>Но суть изменений озвучить не в состоянии?
I>Cуть изменений, о которых я сказал, — препятствия для перехода устранены.

Но в статье речь о другом.
О том, что обратный переход на JS даёт больше плюшек.

I>>>1 типы добавляют много дополнительного кода. Собственно, именно это препятствие теперь устранено благодаря улучшеному выводу типа
V>>Т.е. исправили старые недостатки не повлияв на сам язык?
I>Наоборот — изменили язык, добавив конкретные фичи.

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

Но фишка TS в том, что код без проблем можно писать и при недостаточном выводе типов, страдает только intellisense.

I>>>и всяким плюшкам вокруг него построеным, type narrowing, control flow analysis и тд.
V>>Не имеет отношения к языку.
I>Наоборот. Язык это не только синтаксис.

И всё же, это не имеет отношения к языку.
Это как пытаться называть улучшения Решарпера улучшением/развитием C#.
Т.е. бред сивой кобылы.

I>>>2 перформанс компилятора — улучшился в разы
V>>Не имеет отношения к языку.
I>В данному случае нет разницы язык или компилятор. Плохой компилер — нет возможности пользоваться языком. Проблема была решена.

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

I>>>3 слабоватая поддержка редакторами — compiles services теперь адекватные, навигация, рефакторинг, интеллисенс теперь заруливают любой жээс редактор.
V>>Не имеет отношения к языку.
I>Наоборот — это инфраструктура для обозначеного языка. Связь более чем очевидная.

Угу, как Решарпера и C#.

I>Еще одна причина — малое количество тайпингов для готовых либ. Она тоже решена. Часть проектов перешли на TypeScript, часть запилили руками и предлагают тайпинги искаропки, часть имеют 3d-party поддержку, которая стала проще.

"Проблема" была решена еще раньше тулзинами, дающими скелет такой типизации.

I>>>Вот история версий, кликаешь в каждую с сегодняшнего дня и до 18го года, т.е. до 3.3
I>>>https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-4.html

V>>Из заметных изменений собсно языка — static blocks.
I>А это фича как раз JavaScript, а не ТайпСкрипт

Основные фичи тайпскрипта находятся в тех самых типах — интерфейсы, дженерики, вывод типа и тд и тд и тд.

Это всё давно было на 2018-й.

V>>>>Особенно "более лучший вывод типов" и "туплы-генерики".

I>>>Туплы-генерики это крайне полезная фича:
V>>Полезная для виляния? ))
V>>Ты сделал утверждение — статья устарела.
V>>Я прошу показать — в каком из своих утверждений?
I>Читай сам:
I>"However, this comes at a cost. TypeScript, requires much more time to compile."

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

I>Похоже, что ты свою же ссылку то и не прочел

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

I>>>Вот еще:
I>>>

I>>> type Readonly<T> = {
I>>>  readonly [P in keyof T]: T[P];
I>>> };
I>>>

V>>В статье речь примерно о таких вещах.

I>Смотрим вместе ту самую статью:
I>https://hackernoon.com/why-i-no-longer-use-typescript-with-react-and-why-you-shouldnt-either-e744d27452b4
I>И видим, что единственный кусочек кода это "javascript.implicitProjectConfig.checkJs": true
I>И никакого прямого упоминания вещей навроде Readonly нет и близко. Просто общие утверждения, что автору статьи неудобно то тут, то там.

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

I>И даже он утверждает, что ителисенс и прочие плюшки работают шикарно.

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

I>Собственно, теперь видно, кто из нас статью не читал

Ты не прочитал до сих пор — в лучшем случае по диагонали пробежался.

Здравствуйте, Sinclair, Вы писали:

S>Если бы у нас не было значений переменного размера (string aka varchar aka ntext),

Туда же NULL даже для числовых полей.

S>то этой ненужной ботвы можно было бы избежать, выставляя в качестве внешнего API сразу внутреннее представление, т.е. структуры.

Но представление NULL-значений различно на разных этапах.
При хранении — вектор бит для всех полей.
При выдаче данных по сети для некоего "рекордсета" — тоже набор бит для всех полей.
При промежуточном оперировании — пара {is-null, value}, т.е. перед отправкой в сеть данные перепаковываются.
На клиенте потом происходит обратная "распаковка" nulllable-полей.

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

Здравствуйте, Serginio1, Вы писали:

S> Ну наружу то выставляются свойства, а уж внутри эти свойства будут обращаться через MemoryMarshal
Кажется, что это плохая идея.
Дело в том, что если я хочу вычислять предикат типа where Name like 'A%', то категорически не нужно реализовывать его через Name.Substring(0, 1) == "A", где Name — это свойство, которое внутри там что-то делает через MemoryMarshal.
Честное вычисление этого свойства протянет дохрена данных между диском и памятью (потенциально у нас там — строка длиной в мегабайт), и выбросит их большую часть.
То есть вот этот вот Name.Substring сразу должен быть преобразован в какой-то код, который вычисляет Substring поверх "сырых" данных, а не поверх уже восстановленной строки.
И крайне желательно вместо конверсии из ASCII/UTF8 перед сравнением сделать наоборот — конвертнуть "A" в ASCII/UTF8 и сравнивать сырые данные с ним.

Здравствуйте, vdimas, Вы писали:

V>Т.е., если речь о гипотетическом непосредственном взаимодействии с АПИ сервера в одном процессе, то этапы переупаковки хотелось бы минимизировать.
Да, верно. Внешнее взаимодействие можно строить разными способами, но я интуитивно ожидаю удобных типов вроде Json. Ситуаций двухзвенки у нас нету, а в тонком клиенте заниматься распаковкой чего-то проприетарного — да ну его.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>> Ну наружу то выставляются свойства, а уж внутри эти свойства будут обращаться через MemoryMarshal
S>Кажется, что это плохая идея.
S>Дело в том, что если я хочу вычислять предикат типа where Name like 'A%', то категорически не нужно реализовывать его через Name.Substring(0, 1) == "A", где Name — это свойство, которое внутри там что-то делает через MemoryMarshal.

S>Честное вычисление этого свойства протянет дохрена данных между диском и памятью (потенциально у нас там — строка длиной в мегабайт), и выбросит их большую часть.
S>То есть вот этот вот Name.Substring сразу должен быть преобразован в какой-то код, который вычисляет Substring поверх "сырых" данных, а не поверх уже восстановленной строки.
S>И крайне желательно вместо конверсии из ASCII/UTF8 перед сравнением сделать наоборот — конвертнуть "A" в ASCII/UTF8 и сравнивать сырые данные с ним.
Ну нынешними средствами C# пока так. Вот когда введут разного рода string как в Delphi например.
Почему нельзя ввести такие структуры непонятно.
А так вон 1С многое хранит в голых byte[] https://infostart.ru/1c/articles/402038/

Здравствуйте, Serginio1, Вы писали:
S>Почему нельзя ввести такие структуры непонятно.
Потому, что очень многое в дотнете и в существующих программах для него завязано на нынешнее устройство строк.
Например, есть такая договорённость, что fixed (char* ptr = "Hello") вернёт указатель на непрерывный буфер символов, заканчивающийся \0.
Можно, конечно, потребовать от альтернативных строк готовить буфер on-demand, при вызове GetPinnableReference(). Но это повлечёт за собой неожиданные расходы, O(1) операция внезапно становится (в лучшем случае) O(N).

Если хочется альтернативщины, то свои алгоритмы надо определять не в терминах string, а в терминах IReadOnlySequence<char>.

S>А так вон 1С многое хранит в голых byte[] https://infostart.ru/1c/articles/402038/

Здравствуйте, Sinclair, Вы писали:

V>>Т.е., если речь о гипотетическом непосредственном взаимодействии с АПИ сервера в одном процессе, то этапы переупаковки хотелось бы минимизировать.
S>Да, верно. Внешнее взаимодействие можно строить разными способами, но я интуитивно ожидаю удобных типов вроде Json.

JSON — это направленный граф, т.е. не самая неудачная для кортежей структура.

S>Ситуаций двухзвенки у нас нету, а в тонком клиенте заниматься распаковкой чего-то проприетарного — да ну его.

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

Здравствуйте, vdimas, Вы писали:
V>Тонкий клиент кушает данные малыми порциями, но сервер может ворочать большими порциями.
V>Причём, ворочать не на SQL-языке, бо он тормозной аки первый в мире калькулятор, а на каком-нить хотя бы на пару порядков более эффективном.
Ну, вот пока что, по мере погружения в тему, не видно перспектив сделать эффективнее на пару порядков

.
Даже если мы рассматриваем только pure и deterministic запросы, обеспечение ACID накладывает свои ограничения.
Т.е. при самом неоптимальном query plan, основные тормоза будут даже не на интерпретации выражений вроде GetIntFieldByOffset()*GetDecimalFieldByOffset(), а на захвате блокировок.
И если мы его скомпилируем в бинарь, устранив интерпретатор, то захват/отпускание блокировок никуда не денутся.
Ну, впрочем, это всё ещё такие, прикидки на пальцах.

Здравствуйте, Sinclair, Вы писали:

V>>Какую именно МОЮ ошибку?
S>Вы перепутали два совершенно разных коннектора.

Не, это ты перепутал и аки утопающий за соломинку хватаешься.
А я взял доку и нашел правильный драйвер.
Попытка обвинить меня в этом даже не смехотворна, а вызывающе тупа.

V>>Июль 2020.
V>>И до этого жизни в дотнете не было, судя по всему?
S>А если копнуть в 2001 год, то там и генериков-то не было.

Не прокатило.

S>Мы же говорим про сейчас, а не про тёмное прошлое.

Сейчас достоверно работает официальный.
По твоей ссылке пока мест неизвестно что.

V>>Теперь берём некий боевой новый проект и вот мелькнула мысль взять с гитхаба код этих двух чуваков...
S>Не, давайте так. Посмотрим, к примеру, на EntityFramework 6 и проект, который на три четверти написан каким-то чудиком с гитхаба.

linq2db пишется и используется, вроде бы, с 2002-го?
В его написании, тестировании, code review, обмена идеями и проч, и проч участвовали десятки если не сотни людей, и я в том числе в разные годы.
Помимо всего этого непосредственно привносили код и тесты тоже достаточно людей.
А использовали в реальных проектах многие тысячи, скорее всего, и я тоже в нескольких.
Ну и, ес-но, накопленная база тестов на порядки больше, чем по твоей ссылке.

Вот как доживёт тот проект до такого же покрытия тестами и людьми — приходи.

S>На какой сам сядешь, на какой маму посадишь?

Ты бы выплюнул, прежде чем говорить.

V>>Ничего против этой парочки не имею, конечно... но ты примерно представляешь объем тестов корректности, которые потребуется написать, чтобы принять решение — стоит рисковать брать самописный левый драйвер в боевую разработку или нет?
S>Конечно представляю. Вот они: https://github.com/mysql-net/MySqlConnector/tree/master/tests

Во-первых, вот они:
https://github.com/mysql-net/MySqlConnector/tree/master/tests/MySqlConnector.Tests

Во-вторых, в тесты ты не заглядывал.
Сравни с тестами linq2db, включая предыдущие две инкарнации, начиная с RDF.

Тестирование поделия по ссылке еще не начиналось от слова вообще, поэтому я и поставил вопрос как поставил — необходимо написать тонну тестов с 0-ля.
Потому что в отличие от тебя, я в имеющиеся "тесты" заглядывал.
Их нет.

V>>Представь, что решения принимаешь ты и отвечаешь за них тоже ты, в т.ч. возможным банкротством.
V>>Я так думаю, что ты никаких тестов писать не будешь, тихонько возьмёшь официальный драйвер, как это делают 99.99% разработчиков и забъёшь на разницу в эффективности болт.
S>Для начала: 99.99% разработчиков никаким банкротством ни за что не отвечают.

Кто не отвечает, тот и не принимает решения.
Или принимает такие решения, от последствий которых фирма не пострадает, т.е. орудует в песочнице того или иного вида.

S>Ну, вот взять хотя бы вас. Не сможете вы внести багу, которая вашу компанию к банкротству приведёт.

Я могу попытаться внести такую багу, которая приведёт к серьезным потерям для компании.
Если удастся такой релиз раздать приличному кол-ву клиентов — однозначно компании конец.

Одно но — эта бага до продакшена не дойдёт.
А в поделии по твоей ссылке до продакшена дойдёт любая бага.

S>Далее: бага может обнаружиться в любом коде. В том числе — и в оракловом.

Такого типа баги:

Unnamed parameter not supported by MySqlCommand.Prepare

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

А еще MS SQL ADO.Net драйвер тоже не поддерживет unnamed-параметры для обычных запросов, их подерживает только ODBC-драйвер.
Хотя MS SQL ADO.Net поддерживает ODBC-like вызовы хранимок, но Prepare для хранимок ничего не делает.
(хотя пофик, это всё ни о чём в любом случае)

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

В деле доступа к БД трясутся над тем, чтобы данные правильно выдавались, бо страшно.
И прецеденты с ошибками дров БД были.

S>Что ж вы не боитесь ответить банкротством за баги Оракла?

Ответил выше.

V>>Зато здесь ля-ля-ля разводить так удобно, потому что безопасно...
S>Пошёл уже феерический бред. Я правильно понимаю, что вам не пришло в голову то, что смена драйвера — это не самая сложная процедура?

Да нифига ты не понимаешь.
Перешёл на беспомощное блеяние, противно читать.

Я находил баги и в майкрософтном ADO.Net драйвере к MS SQL.
В дотнет Core тоже найдено и зарепорчено несколько багов.

А ты в этом плане никто и звать тебя никак.
Болтун-фантазёр, который вообразил себе будто дотнет бабочками какает, просто потому что это дотнет, а как дела обстоят на самом деле — ни сном ни духом.

Да, я помню, как ты чуть ли не громче всех орал примерно в 2005-м, что дотнет позволяет делать меньше ошибок.
Но на деле вышло наоборот — такого чудовищного кол-ва ошибок как в дотнетном коде еще поискать.
У багов в дотнетном коде гнездо by design.
Да и общее кач-во как высокоуровневого дизайна, так и конкретных воплощающих его сниппетов — отвратительное.
Такова реальность.
Плата за "низкую планку входа".

А как верещали, помнится: "Дотнет позволяет не отвлекаться на низкоуровневые подробности, но заниматься прикладными задачами!".
Оказалось ложью.
Не дотнет-среда или дотнет-языки позволяли, а тупо большой набор готовых либ в поставке.
Стоило поспеть аналогичным либам и в нейтиве примерно к 2007-2008-м годам — и дотнетный лозунг всё очевиднее стал читаться как "мозги теперь не нужны, программируйте на отгребись, оно всё-равно худо-бедно, но заработает!"

Чего далеко ходить, по твоей ссылке код каких-то конченных двух олигофренов, посмотри сам:

    public sealed class MySqlBatch 
...
    protected override async Task<DbDataReader> ExecuteDbDataReaderAsync(CommandBehavior behavior, CancellationToken cancellationToken)
    {
        ((ICancellableCommand) this).ResetCommandTimeout();
        using var registration = ((ICancellableCommand) this).RegisterCancel(cancellationToken);
        return await ExecuteReaderAsync(behavior, AsyncIOBehavior, cancellationToken).ConfigureAwait(false);
    }

Ничего тебя не смущает?

Приведение sealed this к интерфейсу.
В голове у авторов мусор вместо человеческих мозгов.

А лично у меня лёгкий ступор.
И от того, как много в дотнете профнепригодных дэбилов, прям гнездо.
И особенно когда этих дэбилов представляют в духе "полюбуйтесь на наших передовиков!".
Если передовики такие, какие ж остальные?

(вот-то не спеши торопиться никогда)

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

S>Ну, то есть если вдруг окажется, что нормальный драйвер вдруг уже оказался хуже, чем оракловое говно?

Хинт: чем очевидней спекуляция, тем больше тянет на зевоту.

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	28.09.21 07:15
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	28.09.21 08:34
Оценка:	+2 -1

	От:	vdimas
	Дата:	28.09.21 11:48
	Оценка:	-1

	От:	vdimas
	Дата:	28.09.21 11:51
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	28.09.21 12:05
Оценка:	+1 -1

От:	Sinclair	https://github.com/evilguest/
Дата:	28.09.21 12:17
Оценка:	+1