Не имею ничего против compile-time. Даже более чем уверен, что рано или поздно в синтаксических конструкциях появится что-то подобное.
Мне пока неясен один момент: если реализация MyList подразумевает в основе своей работу с неким непростым хранилищем данных серьезного объема — как эта конструкция отработает в реальности?
Теперь давайте поговорим о фильтрах. Если спросить у гугла, то выяснятся любопытные подробности:
1) Роб Пайк год назад набросал (я так понимаю на коленке) простенькую библиотеку, которая реализует концепцию apply/filter/reduce.
2) Комментарий самого Пайка в вольном переводе звучит так: «Я ЭТО не использую. И вам не советую».
3) Тем кого напрягает отсутствие встроенного в язык кейворда, можно посоветовать заглянуть внутрь функций: там все сделано достаточно близко к потрохам самого Go и даже при добавлении в стандартную библиотеку или даже сам язык — вряд ли сильно изменится.
4) Глядя на то, что имеем в итоге, становится ясно — проще цикла-фильтра пока ничего не придумали. Да и тот можно завернуть в красивую обертку при желании.
Поддержу. Даже более того, скажу что go в принципе пригоден для более интересных задач, нежели написание просто бизнес-логики.
Проект, которым я занимаюсь, связан с обработкой видео на FPGA. И вы, возможно, удивитесь, но высокоуровневый софт в количестве 2-х утилит (для экспериментального образца устройства) изначально мы начали создавать на go. В набор функций софта в том числе входит веб-интерфейс, работа с памятью, работа с аппаратным кодеком, управление железом, передача данных, различные алгоритмы обработки видеоданных.
Пока я еще ни разу не пожалел о том, что go был выбран для разработки. И причин тому несколько.
Во-первых, он позволяет быстро прототипировать алгоритмы не отвлекаясь на синтаксические и прочие особенности непосредственно языка и библиотек.
Во-вторых, у него достаточно возможностей и быстродействия для общения с нижележащим железом.
В-третьих, имеются достаточно любопытные инструменты, позволяющие профилировать и оптимизировать софт.
Так вот по поводу синтаксической простоты языка — это преимущество в основном в начале работы в проекте — как при старте проекта, так и при добавлении новых участников разработки.
Далее куда более важно понимание архитектуры и логики проекта. И тут сам язык отступает на второй план. Без такого понимания неважно на каком языке вы пишите код — хоть на go, хоть на rust'е.
Так что мой вывод для топикстартера — учите любые языки, но в первую очередь лучше учитесь проектировать проекты, а затем уже программировать программы )
Спасибо за ответ. Извиняюсь если кого случайно задел, вопрос прозрачной трансляции действительно интересовал, особенно в свете пока слабого знакомства с Go.
Ну ладно — разные архитектуры, так разные. Будем частями переписывать пробовать :)
Расскажите, а за что минусы?
Лично мне Go нравится и я планирую использовать его в дальнейшем. При этом есть большое количество рабочего отлаженного кода на php, который взять и переписать в один заход сложно. Классно было бы оттранслировать его хотя бы в качестве эксперимента.
И лексический анализатор php тут недавно был.
Или у нас тут только идеология на кону, а практические вопросы миграции не интересны?
Мне тоже непонятно как технически сменили пароль на виртуальном сервере, но то что у ряда хостеров такая возможность присутствует — это факт. Я не спец по виртуальным технологиям, но насколько я понимаю — получить доступ к содержимому виртуальной машины проще, чем к физическому серверу.
У нас была ситуация, когда взломали впс, положили туда ключ для ssh и сменили рутовый пароль. На сервере ничего не крутилось, кроме nginx и почтовика. Вернули рутовую учетную запись, но буквально на следующий день ситуация повторилась.
Разбираться не стали, просто съехали тут же с этого хостера.
Не могу ничего утверждать насчет манипуляций, кроме того, что у них есть все инструменты для этого. Как и у любой форексовской кухни.
Но я обратил внимание на интересный момент — последний сутки или двое (до вчерашнего вечера), на Биткоинике были минимальные объемы торговли (~8000BTC), при этом на МтГоксе объемы были в районе 30-40 тыс. BTC.
Как только на Биткоинике объемы восстановились до ~40 тыс BTC, на МтГоксе произошел скачок объемов в два раза.
Из этого я могу пока сделать два вывода — либо у всех одновременно появился дикий интерес к торговле биткоинами, либо Биткоиника генерирует от трети до половины объемов торгов на МтГоксе.
Чтобы защищаться с помощью api — нужно делать как минимум две независимые дублирующие системы учета баланса/транзакций внутри сервиса. Тогда сбой в одной из них, должен блокировать все операции по вводу/выводу до завершения ручного разбора ситуации. Но, разумеется, такая система не защитит от банального взлома сервера, на котором крутится bitcoind.
Про Slush'а я ничего не говорю, я могу ему только посочувствовать в данной ситуации и восхититься его решением компенсировать все потери за свой собственный счет. Это о многом говорит.
Про пиар я говорил относительно Bitcoinica. Хороший инфоповод заявить о том, чего на самом деле могло и не быть.
Максимум что компенсирует — это стоимость услуги хостинга. На форуме народ уже нашел цитату из ToS — там явно указано, что в объеме стоимости услуг и не больше.
Суть не в корректности формулировок. Суть в том, что чужой виртуальный сервер — это наихудший вариант, который только можно было придумать. Я считаю, что имея на руках эквивалент нескольким сотням (и даже десяткам) тысяч долларов клиентских средств — это уже хороший повод потратить $100-200 в месяц на аренду физического сервера, либо озадачиться запуском такого сервера на своих собственных мощностях. Благо к нему не требуется 100% аптайма и широкого канала.
Мне одному кажется, что «пропажа» Биткоиники это всего лишь пиар? Если в случае со Slush такая ситуация действительно могла быть, то в случае с Биткоиникой — это либо выдумка, либо невероятная глупость. Потому как хранить такое количество Биткоинов на виртуальном сервере — это еще постараться придумать такое надо.
Мне пока неясен один момент: если реализация MyList подразумевает в основе своей работу с неким непростым хранилищем данных серьезного объема — как эта конструкция отработает в реальности?
1) Роб Пайк год назад набросал (я так понимаю на коленке) простенькую библиотеку, которая реализует концепцию apply/filter/reduce.
2) Комментарий самого Пайка в вольном переводе звучит так: «Я ЭТО не использую. И вам не советую».
3) Тем кого напрягает отсутствие встроенного в язык кейворда, можно посоветовать заглянуть внутрь функций: там все сделано достаточно близко к потрохам самого Go и даже при добавлении в стандартную библиотеку или даже сам язык — вряд ли сильно изменится.
4) Глядя на то, что имеем в итоге, становится ясно — проще цикла-фильтра пока ничего не придумали. Да и тот можно завернуть в красивую обертку при желании.
Ссылка на саму библиотеку от Роба Пайка
Ссылка на тестовый пример на Go Playground
Проект, которым я занимаюсь, связан с обработкой видео на FPGA. И вы, возможно, удивитесь, но высокоуровневый софт в количестве 2-х утилит (для экспериментального образца устройства) изначально мы начали создавать на go. В набор функций софта в том числе входит веб-интерфейс, работа с памятью, работа с аппаратным кодеком, управление железом, передача данных, различные алгоритмы обработки видеоданных.
Пока я еще ни разу не пожалел о том, что go был выбран для разработки. И причин тому несколько.
Во-первых, он позволяет быстро прототипировать алгоритмы не отвлекаясь на синтаксические и прочие особенности непосредственно языка и библиотек.
Во-вторых, у него достаточно возможностей и быстродействия для общения с нижележащим железом.
В-третьих, имеются достаточно любопытные инструменты, позволяющие профилировать и оптимизировать софт.
Так вот по поводу синтаксической простоты языка — это преимущество в основном в начале работы в проекте — как при старте проекта, так и при добавлении новых участников разработки.
Далее куда более важно понимание архитектуры и логики проекта. И тут сам язык отступает на второй план. Без такого понимания неважно на каком языке вы пишите код — хоть на go, хоть на rust'е.
Так что мой вывод для топикстартера — учите любые языки, но в первую очередь лучше учитесь проектировать проекты, а затем уже программировать программы )
Ну ладно — разные архитектуры, так разные. Будем частями переписывать пробовать :)
Лично мне Go нравится и я планирую использовать его в дальнейшем. При этом есть большое количество рабочего отлаженного кода на php, который взять и переписать в один заход сложно. Классно было бы оттранслировать его хотя бы в качестве эксперимента.
И лексический анализатор php тут недавно был.
Или у нас тут только идеология на кону, а практические вопросы миграции не интересны?
Разбираться не стали, просто съехали тут же с этого хостера.
Но я обратил внимание на интересный момент — последний сутки или двое (до вчерашнего вечера), на Биткоинике были минимальные объемы торговли (~8000BTC), при этом на МтГоксе объемы были в районе 30-40 тыс. BTC.
Как только на Биткоинике объемы восстановились до ~40 тыс BTC, на МтГоксе произошел скачок объемов в два раза.
Из этого я могу пока сделать два вывода — либо у всех одновременно появился дикий интерес к торговле биткоинами, либо Биткоиника генерирует от трети до половины объемов торгов на МтГоксе.
Про пиар я говорил относительно Bitcoinica. Хороший инфоповод заявить о том, чего на самом деле могло и не быть.