R
а трейдеры не добывают нефть, продавать её это не мешает
ну что такое нефть я знаю, а про эти ваши хуки впервые слышу.
Size: a a a
2020 April 21
DS
мне хаватет traceShowId для всего 🤷♂️
Там вроде добавили возможность недавно генерить человеческие дебаг символы для желающих, чтобы можно было через gdb работать:
https://gitlab.haskell.org/ghc/ghc/-/wikis/debugging/compiled-code
https://gitlab.haskell.org/ghc/ghc/-/wikis/debugging/compiled-code
B
предвидя ваши возражения - интерпретируемость все же должна быть фундаментом для разработки. кодер будет хотеть иметь возможность всегда покрутить что ему пришло, побрутфорсить обьект таким образом чтобы получить своё. да я понимаю что те кто вышел из статики привыкли без этого обходится, эта тема уже поднималась с @mersinvald и я понял что можно писать мини тесты но это не совсем катит. бывает так что стейт слишком крупный или жирный, бывает так что воспроизвести стейт затратно, нужно писать механизм типа "просто дампни текущий стейт в файлик и воспроизведи", вобщем я понял что это удобный хороший способ но это все же недостаточно гибко и требует всю архитектуру делать "рекаверабле"
короче есть две нерешенные проблемы
- брейк он паник
- возможность в отладчике вызывать методы
и я уже столько лютого треша на эти темы нагуглил. вот например https://gist.github.com/spacejam/15f27007c0b1bcc1d6b4c9169b18868c
вобщем есть у меня ряд задач где просто страшно отказываться от какого то низового уровня, страх потерять контроль, страх потерять возможность отладить. причем это же не просто так, это вот буквально в любом ботике, любом кравлере - вот происходит отсос - можно вытащить стейт всех обьектов, изучить, потраить какието рантайм тулзы
короче есть две нерешенные проблемы
- брейк он паник
- возможность в отладчике вызывать методы
и я уже столько лютого треша на эти темы нагуглил. вот например https://gist.github.com/spacejam/15f27007c0b1bcc1d6b4c9169b18868c
вобщем есть у меня ряд задач где просто страшно отказываться от какого то низового уровня, страх потерять контроль, страх потерять возможность отладить. причем это же не просто так, это вот буквально в любом ботике, любом кравлере - вот происходит отсос - можно вытащить стейт всех обьектов, изучить, потраить какието рантайм тулзы
ну раст это же нативный язык, прямая работа с памятью, указатели на ф-и
проблемно с интерпритатором
проблемно с интерпритатором
B
Тут все потоки не атомарно работают, есть что.
IORef гарантирует только атомарность операций записи и чтения отдельно. Т.е. запись атомарна, чтение атоморно, но не они вместе.
Он не даёт гарантий того, что сделанные автором
запись, ожидание и потом чтение будут вместе выполнены атомарно.
IORef гарантирует только атомарность операций записи и чтения отдельно. Т.е. запись атомарна, чтение атоморно, но не они вместе.
Он не даёт гарантий того, что сделанные автором
запись, ожидание и потом чтение будут вместе выполнены атомарно.
а как-же
?
atomicModifyIORef :: IORef a -> (a -> (a, b)) -> IO b?
DS
а как-же
?
atomicModifyIORef :: IORef a -> (a -> (a, b)) -> IO b?
У неё свои проблемы:
-- This function is useful for using 'IORef' in a safe way in a multithreaded
-- program. If you only have one 'IORef', then using 'atomicModifyIORef' to
-- access and modify it will prevent race conditions.
--
-- Extending the atomicity to multiple 'IORef's is problematic, so it
-- is recommended that if you need to do anything more complicated
-- then using 'Control.Concurrent.MVar.MVar' instead is a good idea.
B
У неё свои проблемы:
-- This function is useful for using 'IORef' in a safe way in a multithreaded
-- program. If you only have one 'IORef', then using 'atomicModifyIORef' to
-- access and modify it will prevent race conditions.
--
-- Extending the atomicity to multiple 'IORef's is problematic, so it
-- is recommended that if you need to do anything more complicated
-- then using 'Control.Concurrent.MVar.MVar' instead is a good idea.
типо говррят — в нутри колбека не дергайте другие иорефы?
B
не пойму почему нут банального CAS, только обертка с колбеком :(
DS
Так со скалой всё понятно, если хочешь писать на языке с нормальной системой типов в прод и не на хаскеле - есть только один вариант, и это скала
PK
Clojure? OCaml? Erlang? Elixir?
DS
Ну и да, брать скалу, если ты страдаешь спрингом головного мозга - бесмысленно.
DS
Clojure? OCaml? Erlang? Elixir?
1. Нет нормальной системы типов - в топку.
2. Нет либ.
3. Нет нормальной системы типов - в топку.
4. Нет нормальной системы типов - в топку.
2. Нет либ.
3. Нет нормальной системы типов - в топку.
4. Нет нормальной системы типов - в топку.
DS
Вот и весь ответ
p
Clojure? OCaml? Erlang? Elixir?
Rust
G
Нет нормальной системы типов - в топку
PK
На Rust программы работают медленно 😅
DS
Rust
1. Нет нормальной системы типов - в топку.
2. Низкоуровневость головного мозга - это для очень специфичных случаев
2. Низкоуровневость головного мозга - это для очень специфичных случаев
DS
Хотя шансы на нормальную систему типов есть, если у кор тимы совесть проснется наконец-таки
p
1. Нет нормальной системы типов - в топку.
2. Низкоуровневость головного мозга - это для очень специфичных случаев
2. Низкоуровневость головного мозга - это для очень специфичных случаев
1. нормальная
PK
Хаскель для системщиков?))