LINUX.ORG.RU

А числодробилки на Python пишут?

 


1

3

Не пинайте сильно, опять нубские вопросы

  1. Если мне нужно написать такую с веб интерфейсом, то я могу взять flask/django?

  2. Там где не хватит скорости придется потом на си переписывать?

  3. Вариант с ASP NET Core будет быстрее или С# умирающий язык?

Ответ на: комментарий от anonymous

дроби числа асинхронно

знатока алгоритмов и паралелизации на Pyton

Ой как тонко, что аж толсто.

WitcherGeralt ★★
()
Ответ на: комментарий от anonymous

Да вообще никакой разницы, на чем. Главное, дроби числа (если там действительно есть что дробить) асинхронно, а не в том же WEB запросе.

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

tz4678 ★★
()
Ответ на: комментарий от WitcherGeralt

Внушительно.У меня появилось неистовое желание потрогать Golang. Адекватно на нем писать backend для работы с БД (СУБД MySQL, Oracle, PostgreSQL)? В общем, для теста все то, что я писал на PHP? Видел как некоторые интернет магазины на Go делают. А еще, слышал такое утверждение: в Go на данный момент нихера нет - насколько это верно? Чего не хватает? Я понимаю, что язык относительно молодой.

jurgens
() автор топика
Ответ на: комментарий от jurgens

В качестве веб-фреймворка можно попробовать:

  • Gin — полноценный фреймворк (мне как-то не зашло).
  • fasthttp — суперлёгкая супербыстрая библиотека, в которой даже роутера нет (есть здесь). Но тут даже дефолтная поудобней. Да, в Go есть офигенный дефолтный веб-сервер.
  • go-macaron — фреймворк выделенный из богичного Gogs.

А вот с драйверами к базам данных грусновато на фоне, что питона, что пхп. Для постгреса смотри на pq и pgx.

WitcherGeralt ★★
()
Ответ на: комментарий от jurgens

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

tz4678 ★★
()

Лично я пришел к выводу, что мне по душе юзать больше языки со статической типизацией. Потому что код получается более качественным и более структурированным. Ну и приятно, что IDE всегда знает, что у тебя в той или иной переменной. Тут питон и пхп в пролёте. И тайпхинтинг особо не помогает, увы.

Писал на Go, использую его и сейчас - и могу сказать, что сырая параша. Да, кидайте в меня камни. Вот попробуйте запилить на Go, например, API с горой фильтров и сложной валидацией. Попробуйте реализовать работу с базой данных так, чтобы код не выглядел, как нечитабельная лапша. Это просто нереально, и дело тут не в квалификации. Я уж молчу про то, что на Django/Laravel и т.п. это пилится в разы проще.

Не аргумент? Ну ок, подскажите тогда, как в гошке подключиться к Sphinx? А ответ прост: никак. Нет ни одной нормальной библиотеки, которая была бы потокобезопасной и вообще пригодной для использования. А наличие годных библиотек как раз-таки определяют возможность использования языка для тех или иных задач. Что касается скорости, то, как ни странно, API, написанные на Go, работают не сильно-то и шустрее, чем написанные на каком-либо другом языке. Потому что большая часть времени в любом случае тратится на выполнение запросов к СУБД, сетевые задержки и т.п.

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

P.s. сейчас пробую NestJS - пока норм. Как дальше пойдет - не знаю. По крайней мере, там тайпскрипт - строгая типизация, соответственно.

dimuska139 ★★
()
Последнее исправление: dimuska139 (всего исправлений: 1)
Ответ на: комментарий от tz4678

описывать структуру JSON

Я когда в первый раз это попытался сделать go-way, так пофалломорфировал, что написал на питоне и вызвал сабпроцессом (нужно было просто распарсить и положить в бд).

заточен под веб как Java

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

WitcherGeralt ★★
()
Последнее исправление: WitcherGeralt (всего исправлений: 2)
Ответ на: комментарий от jurgens

Посмотрел, узнал в нём джангу, блеванул, больше никогда не вспоминал.

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

В книге 1997 года, которая перепечатка более раннего американского издания, язык Java назван языком для Интернета, а так же озвучена концепция IoT, интернета вещей, с которым сейчас носятся кау с криптой и машинным обучением гомностартаперы.

tz4678 ★★
()
Ответ на: комментарий от tz4678

Я сам не заметил как это произошло, но iot у меня во все поля. И это дико удобно.

Сначала у меня появился хромкаст. Оказалось дико удобно смотреть ютупчик (плюс PPV UFC и WWE) на телеке, управляя с планшета, и не включая для этого комп. Сейчас дугой телек и без хромкаста так может.

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

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

Потом купил датчик тепла и влаги для ванной, тоже шикарная вещь.

WitcherGeralt ★★
()
Ответ на: комментарий от dimuska139

Ну ок, подскажите тогда, как в гошке подключиться к Sphinx?

Не обязательно писать библиотеки к нишевым продуктам, которые мало кем используются. Я бы удивился, если бы у ElasticSearch не было библиотеки, а Sphinx ну вроде бы кто-то когда-то им пользовался, но чот это больше похоже на костыль, чем на решение.

Да, постоянные if’ы конечно создают мусор, но зато нет эксепшенов, которые могут создать куда больше проблем, чем if’ы.

xpahos ★★★★★
()
Последнее исправление: xpahos (всего исправлений: 1)
  1. Да
  2. Да, но лучше уложиться во всякие numpy и аналоги, которые уже созданы как обёртки над Си
  3. Никаким боком C# не сдался, но есть имплементация Питона на C#, можно его покурит, тоже будет быстро работать.
  4. Есть pypy, пиши сразу под него
menangen ★★★★★
()
Ответ на: комментарий от xpahos

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

Да не так и мало. Регулярно сталкиваюсь с проектами, где Sphinx есть. В совсем новых проектах его, возможно, и не юзают, но в легаси, которое нередко сейчас дробят на микросервисы - вполне. И менять Sphinx на Elastic там не слишком целесообразно. Тем более, что Эластик и Сфинкс, насколько я знаю, это не аналогичные программы. Гошка, кстати, появилась уже больше 10 лет назад. А тогда, замечу, Сфинкс был популярен, и широко использовался в качестве поисковой системе сайтов. И даже в то время никто из гошников не юзал сфинкс? Не поверю.

Да, постоянные if’ы конечно создают мусор

Я про if’ы и исключения ничего и не писал. Код на Go выглядит, как мусор, далеко не только из-за них. Нет нормальных ORM - разрабы пилят по-своему. Нет стандартов - все пилят, как хотят. Шаблоны проектирования в большинстве случаев - не, не слышал. Это все выглядит, как php лет 15 назад. Что уж говорить, даже валидаторы в API практически ни у кого нормально в Go не делаются. Можно заморочиться, но даже в том же Gin/Gonic валидация нормально не работает.

dimuska139 ★★
()
Ответ на: комментарий от dimuska139

И даже в то время никто из гошников не юзал сфинкс? Не поверю.

Судя по их форуму используют mysql драйвер.

Нет нормальных ORM - разрабы пилят по-своему.

Дай примеры ненормальных ORM. Я не видел проблем с тем что использовал.

Нет стандартов - все пилят, как хотят.

Стандартов чего?

Шаблоны проектирования в большинстве случаев - не, не слышал.

А зачем они? Ну вот реально я только в C++ сталкивался с тем, что они нужны. В python это часто приводит к тому, что код вообще невозможно понять.

Можно заморочиться, но даже в том же Gin/Gonic валидация нормально не работает.

Он просто не покрывает твой кэйс. Сделай как надо, отправь пулл реквест. Не вижу проблемы.

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

Судя по их форуму используют mysql драйвер

Верно, только это не работает) Я проверял

Дай примеры ненормальных ORM

По сути только Gorm. Удобно его юзать? Да ничуть. Особенно когда дело касается связей между таблицами.

Стандартов чего?

Стандартов проектирования приложений. Если в том же пыхе есть Симфони и всякие Ларавели, показывающие хоть какие-то примеры того, как надо и как не надо разрабатывать, то в Go этого нет. Возьми API на Go от 10 разрабов - и все они будут написаны абсолютно по-разному. Есть go-kit, но ему особо никто не следует. В пыхе тоже такое тоже есть, естественно, но в гораздо меньших масштабах.

А зачем они?

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

Он просто не покрывает твой кэйс.

Она ничей кейс не покрывает, кроме совсем простейших случаев. Если отправляешь на эндпоинт число в кавычках (JSON), а в структуре, на которую он биндится через метод Bind (MustBindWith и т.п.), в этом поле ожидается int, то невозможно это перехватить и выдать юзеру название поля, в котором ошибка. Пример: {"age:"10"}. Выдать юзеру ответ {"errors":{"age":"Number expected"}} не получится, потому что в Gin/Gonic сначала вызывается биндинг (который и валится в panic), а только потом валидация.

dimuska139 ★★
()
Ответ на: комментарий от dimuska139

Верно, только это не работает) Я проверял

Ну тогда используй Solr или ES, они хотя бы живыми выглядят. Даже во времена популярность Sphinx он жил только за счет того, что его автор появлялся на всех конференциях.

По сути только Gorm. Удобно его юзать? Да ничуть. Особенно когда дело касается связей между таблицами.

Ну Perload надо написать или что не так?

Стандартов проектирования приложений. Если в том же пыхе есть Симфони и всякие Ларавели, показывающие хоть какие-то примеры того, как надо и как не надо разрабатывать, то в Go этого нет.

Это не стандарты, а фреймворки, даже скорее CMS.

Возьми API на Go от 10 разрабов - и все они будут написаны абсолютно по-разному.

Не очень понимаю в чем тут проблема. Ну будут написаны по-разному и будут от этого никому хуже не станет.

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

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

Она ничей кейс не покрывает, кроме совсем простейших случаев.

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

xpahos ★★★★★
()
Ответ на: комментарий от xpahos

Это не стандарты, а фреймворки, даже скорее CMS.

Не CMS они ни разу, но не суть. А что касается стандартов, то как раз популярные фреймворки их частенько и задают. Народ смотрит код фреймворков и потом частично эти подходы переиспользует. Например, DDD, который используется в Symfony (и не только, естественно), часто используют вне его в том же php-slim.

Ну будут написаны по-разному и будут этого никому хуже не станет

Не станет, пока проект поддерживает один разработчик. Когда проект разрастается, другим разработчикам вникать в эти велосипеды, в которых даже service layer зачастую выделить невозможно - такое себе. Я бы сказал, что это примерно то же, что flat php - такая же мешанина неразбираемая по большей части.

Впервые слышу о том, что шаблоны проектирования как-то связаны с тестами.

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

Ты наверное имеешь в виду юнит тесты?

Да.

Ну и что значит не городить велосипеды для типовых ситуаций

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

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

Тот чувак - я и есть. И выложил я то issue потому как раз, что валидация gin/gonic по сути для json не покрывает стандартный кейс - проверку на число/строка. Точнее эта валидация работает, конечно, в каком-то смысле (потому что кидает ошибку), но не позволяет дать юзеру информацию о том, в каком именно поле ошибка. А в форме их может быть десяток. В чем тогда смысл такой валидации? Вот сравни просто это добро с каким-нибудь symfony/validator. День и ночь просто.

dimuska139 ★★
()
Ответ на: комментарий от grem

Я, как и все любители питона, сталкивался с его узкими местами, и решал их бывало с помощью любимого фортранчика, а именно f2py. Скажу честно, костыли это. Тута мне предлагают другие костыли, cython и numba. Не знаю, куда метаться.

yvv ★★☆
()

или С# умирающий язык?

Ты, видимо, прикалываешься.

Вариант с ASP NET Core будет быстрее

Конечно, будет быстрее.

KevlarBeaver
()
Ответ на: комментарий от jurgens

jquery

В 2020 году лапшичку писать и палочкой в DOM тыкать, ну такое…

KevlarBeaver
()
Ответ на: комментарий от dimuska139

Не CMS они ни разу, но не суть. А что касается стандартов, то как раз популярные фреймворки их частенько и задают. Народ смотрит код фреймворков и потом частично эти подходы переиспользует. Например, DDD, который используется в Symfony (и не только, естественно), часто используют вне его в том же php-slim.

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

Не станет, пока проект поддерживает один разработчик. Когда проект разрастается, другим разработчикам вникать в эти велосипеды, в которых даже service layer зачастую выделить невозможно - такое себе. Я бы сказал, что это примерно то же, что flat php - такая же мешанина неразбираемая по большей части.

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

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

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

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

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

Тот чувак - я и есть. И выложил я то issue потому как раз, что валидация gin/gonic по сути для json не покрывает стандартный кейс - проверку на число/строка. Точнее эта валидация работает, конечно, в каком-то смысле (потому что кидает ошибку), но не позволяет дать юзеру информацию о том, в каком именно поле ошибка. А в форме их может быть десяток. В чем тогда смысл такой валидации? Вот сравни просто это добро с каким-нибудь symfony/validator. День и ночь просто.

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

xpahos ★★★★★
()

Если мне нужно написать такую с веб интерфейсом, то я могу взять flask/django?

Да

Там где не хватит скорости придется потом на си переписывать?

Сначала пишут алгоритм. Отлаживают его.

Если медленно, то пытаются сделать это на numpy, pandas. Если получается медленно, то можно попробовать использовать numba. Или переписать на диалекте питона Cython.

Вариант с ASP NET Core будет быстрее или С# умирающий язык?

Я думаю, что то на то выйдет.

dicos ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.