This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-11-01
Channels
ещё о ереси https://leanpub.com/purescript/read — отличная книга про PureScript, более мощную в плане возможностей языка альтернативу Elm (да-да, тайпклассы есть)
@az: программировать! “трейдинг” потому что самая крупная окамл-контора janestreet занимается как-раз всякими финансами
братцы объясните пожалуйста на пальцах что такое helm? и helm-clojure что то добавляет для удобства разработки?
@ul: Не помню обсуждали или нет - rust не смотрел? Или тебе под JS нужно? Пол книги про него уже прочитал, чем дальше тем больше кажется что он может стать вторым моим любимым языком после кложуры
смотрел немного ещё до релиза, но тогда не к чему было приложить. под JS в приоритете, потому я могу начать вводить язык в существующие проекты, а не менять сразу язык и доменную область
Если нода - то через FFI он отлично интегрируется https://doc.rust-lang.org/stable/book/rust-inside-other-languages.html
Я уже причём за хаскелеподобные языки не в первый раз берусь, но каждый раз становлючь похож на умную собаку. Абстракции выглядят понятными, но вот как код писать — хз )))
хаскель да - у меня на него мозгов не хватает чтоб даже понять монады( Emsscripter костыльно конечно, но вспоминая про WebAssembly это может быть временный костыль
ты если будешь играться с PureScript - отпишись потом, всегда интересно что там как у других
Да, конечно. Но там ужас какой-то, вот как ребята пишут на нём UI https://github.com/slamdata/purescript-halogen
ну дак, зато сейфти. Я не уверен вообще что на фронте есть смысл использовать статик тайп языки: все эти ресты, DOM/BOM слишком динамичны и тут внезапно закуток где все pure & safe… мм, не знаю. Для бека еще куда не шло, хотя там тоже с этими микросервисами никто гарантий никаких не дает
Тайп-сейфти - это всего лишь "всё стыкуется" от компилятора. Чем изощрённее система типов, тем больше программ компилятор может проверить на стыкуемость.
А что REST/DOM? Они-то хорошо типизированы: на входе URL, на выходе текст; у элемента 100500 методов, и три вида детей; etc.
Так что тайп-сейфети на фронтэнде -- это скорее про свой код, а не про взаимодействие с чужим.
@asolovyov: Бесперебойный сервинг статических файлов -- задача достаточно сложная для 2015 года
А кто-нибудь пользуется ленивыми последовательностями при доступе к данным?
Вроде само напрашивается, пишешь функцию вычисляющую некоторое следующее значение в последовательности, определяешь онную и вперед, доступ к огромным массивам данных с приятным синтаксисом.
DAtomic к примеру не позволяет таким образом делать доступ к данным?
привет. Он максимально простой. Пишешь sql, в кложе пишешь defquery, и потом вызываешь методы
читай в вики migration guide, а то на главной была дока устаревшая, когда я последний раз смотрел
--name: get-producers! -- retrieve a user given the id. SELECT * FROM producers WHERE name = 📛
(defqueries "sql/queries.sql" {:connection conn}) (checks.db.core/get-producers! {:name "test"} {:connection conn})
вызываю получаю Exception java.sql.BatchUpdateException: batch entry 0: query returns results
(jdbc/query conn ["SELECT * FROM producers where name = :name" "test"]) тут же вызываю, все ок
@abtv: У меня всё как-то получается, что куда ни сунусь -- ничего не работает. Откатываюсь на то, что знаю хорошо -- и язык, и тулинг - C99 и ES5.
@dottedmag: интересно, а на си ты в чем пишешь?
@dottedmag: не отчаивайся же
@dottedmag: Интересная у тебя связка. Нагруженный сервис? Кстати, интересно, а что еще сейчас может являться альтернативой JVM для бэкенда? Чтобы и community (либы) было и движуха? Community и движуха вроде у nodejs есть, а вот у Go мне так сдается только движуха. Но, в то же время, Google может баблом решить, если захочет, а не как с Dart.
@rm: Я в этом какой-то дзен ощущаю. Для сайд-проекта взял сначала cljs для хромового расширения, потом откатился до ES6, потом надоело ковыряться с gulp -- пишу теперь на чистом ES5, и получается проще, чем когда-либо.
я тут недавно услышал, что node может начать сильно тормозить в зависимости от типа передаваемых данных. Вроде как JIT может не справляться по каким-то причинам с объектами с разными полями. Насколько это верно? Кстати, а у тебя си из ноды вызывается?
@abtv: Си у нас с нодой только через сокеты общается -- несколько кусков осталось написано на C, а остальное переписано на JS.
Ну как бэ не надо менять прототип объектов налево и направо, тогда и JIT'у будет легко.
типа если ты передаешь что-то типа динамических объектов, то начинает тупить. Вот если у нас есть пользователь, а у него массив, скажем, объектов с сообщениями, это же не проблема? Если каждое сообщение имеет один и тот же набор полей.
Если у каждого пользователя свои поля в сообщении, то JIT не сможет ничего сделать, и будет generic-реализацию использовать, которая хэш-массив, а не кусок памяти со смещениями в нём. Тоже нормально, но не сверхбыстро.