Луч поноса авторам HomeBrew

Довольно давно, а если говорить точнее, то уже лет как 5 я использую MacPorts. Порты, конечно, не без багов, но все же они достаточно хорошо спроектированы и удобны в использовании. В них всегда можно найти несколько версий компиляторов и т.д. И тут, внезапно, мне понадобился HomeBrew. Да, я знаю, что писать пакеты для MacPorts трудно, а для HomeBrew легко. Да, я в курсе того, что заставить работать MacPorts через прокси не так уж и просто, а HomeBrew очень легко. Но…

КАКОГО ХЕРА HomeBrew требует что бы пользователь был Admin?! Что за жопорукий дебил это придумал?! Системное приложение ОБЯЗАНО уметь работать через sudo или каким-то иным способом повышать свои права!

Слегка разочаровался в Scala

Когда-то, довольно давно, я взялся за поиск альтернативы для C++, который во все времена был и, как мне думается на данный момент, будет моим основным рабочим инструментом. Само собой, эта альтернатива мне была нужна не для того, что бы перейти в какую-то иную сферу, а для тех случаев, когда либо хочется написать что-то свое, либо нужно быстро создать какой-то прототип, проверить ту или иную концепцию. В такой ситуации JVM-based язык очень удобен и, по большому счету, безальтернативен, конкуренцию может составить разве что Python со своим простым синтаксисом и безграничным набором библиотек. Continue reading

Поговорим об акторах

Лично мне очень нравится концепция акторов. Что интересно, познакомился я с ней куда раньше повальной моды на функциональщину, в году так 2003, когда начал плотно работать с библиотекой ACE (это та, которая The ADAPTIVE Communication Environment). Ну а сейчас акторами никого не удивишь, все про них только и говорят. И это хорошо, так как данная модель сильно упрощает отладку и разработку, при относительно не большой просадке по производительности и памяти.

В последнее время я присматриваюсь у относительно экзотическим языкам программирования, таким как Rust и Scala, а для обоих языков модель акторов является родной. При этом, на данный момент, Rust ничего не может предложить сравнимого с библиотекой AKKA, хотя даже в текущем своем состоянии его представление модели акторов не безынтересно. Continue reading

Задачи в Rust. Подводные камни.

Все написанное в данной заметке актуально для компилятора Rust версии 0.7

Более-менее глубокой информации о задачах в Rust не много, поэтому, для того что бы разобраться в том, как же это работает, приходится экспериментировать “на кошках”. Посидев некоторое время за исходниками Rust, я открыл для себя много нового.
Самое неожиданное: на данный момент планировщиков задач аж два! Один старый, более функциональный, правда, на данный момент находящийся в довольно непотребном состоянии и новый, который еще не дописан. Подобная ситуация приводит к тому, что поведение задач, запущенных при помощи методов TaskBuilder отличаются от поведения задач, запущенных при помощи функций из модуля task.
Ну а после “оптимистичного” введения, небольшой рассказ о планировщиках Rust и том, как с ними работать на данный момент.

Старый планировщик

Если зайти на сайт Rust, то в разделе посвященном модулю Task можно найти информацию о ряде доступных типах планировщиков, заявленное поведение которых расходится с реальным: Continue reading

Взаимодействие между задачами в Rust

Модель памяти Rust, в общем случае, не допускает совместного обращения к одной и той же памяти (shared model) предлагая вместо этого обмениваться сообщениями (mailbox model). При этом существует возможность работать с общей памятью в режимах “только для чтения” и “один писатель много читателей”. На данный момент в Rust существует несколько способов организации взаимодействия между задачами:

  • Низкоуровневые каналы и порты из модуля core::comm;
  • Высокоуровневая абстракция над каналами и портами std::comm;
  • Каналы предназначенные для передачи бинарных данных из std::flatpipes;
  • Новая инфраструктура для обмена сообщениями core::pipes.

Continue reading

Модель памяти Rust

Модель памяти Rust довольно сильно отличается как от управляемых языков типа Java или C#, так и от не управляемых языков типа C и C++. Так как Rust является совершенно новым языком программирования и не ограничен какими-либо требованиями совместимости с предшественниками, он реализует наиболее удобную модель памяти для решения следующих целей:
Безопасность. Предотвращение возникновения утечек памяти или ошибок сегментации.
Производительность. Сборщик мусора управляет указателями а не объектами. Нет необходимости замораживать все задачи для очистки памяти, так как каждая из них имеет собственный хип.
Многопоточность. Предотвращение возникновения гонок в памяти, так как каждая из задач имеет собственный хип и передаваемые между задачами данные должны копироваться. Наличие хипа обмена для избежания лишних операций копирования с семантикой владения. Continue reading

Кроссплатформенность в современном мире

Очередное обсуждение недостатков Nemerle на РСДНе навело меня на интересную мысль о связи между успешностью того или иного инструмента и его кроссплатформенностью.
По большому счету, Nemerle это язык с интересными концепциями и идеями, который не нужен практически никому, кроме его разработчиков. Почему я делаю такое утверждение? Тут все просто, возьмем для сравнения его ровесников Scala, Groovy и даже совсем молодежь Clojure. Для того что бы понять, нужен ли язык кому-то, кроме его авторов, можно воспользоваться следующей информацией:

  1. На каких языках присутствует информацию о языке в Википедии
  2. На какой строчке находится язык в индексе TIOBE;
  3. Участвует ли язык в индексах The Computer Language Benchmarks Game;
  4. Написал ли кто-то книги по этому языку.

Continue reading

var VS val

В Scala существуют два типа переменных, константные и изменяемые. На фоне большинства мэйнстрим языков, подход выглядит довольно странно: константные “переменные” декларируются посредства ключевого слова val, для создания изменяемых переменных используется ключевое слово var.

Столкнувшись с таким подходом, первый заинтересовавший меня вопрос был “есть ли какая-то разница на уровне JVM в var и val?”. Возьмем простейший пример:

    val str1 : String = "String1";
    var str2 : String = "String2";

Что будет скомпилированно в:

   0:   ldc #23; //String String1
   2:   astore_2
   3:   ldc #25; //String String2
   5:   astore_3

Итого: как и ожидалось, никакой разницы нет, просто проверка на этапе компиляции.

И еще пара моментов. Параметр функции всегда константа:

  def fn(arg : String) {
//    arg = "Test"; // error: reassignment to val
  }

В отличие от параметров конструктора, которые могут быть как константными, так и изменяемыми переменными. Для получения изменяемого параметра, необходимо явно это указать при помощи var.

class TestClass(v1 : String,  var v2 : String) {
//  v1 = "NewVal" // error: reassignment to val
  v2 = "NewVal"
}

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

В поисках альтернатив C++

В связи со своим вынужденным переходом в разработчики Java я получил довольно интересную возможность посмотреть на C и C++ со стороны. В целом, мне нравится то что я вижу глядя на C++ с позиции Java разработчика, но, само собой, нашлось одно «но», которое, если быть честным, мне и раньше не давало покоя: C++ совершенно не подходит для быстрого прототипирования. По большому счету это единственный недостаток который я отмечаю на данный момент.

Если говорить про Java, то с быстрым прототипированием тут все нормально, в то время как скорость разработки приложений приблизительно такая же•• как и в случае с C++, ну может на 10% быстрее. При этом язык крайне ограниченный, практически до убогости, что после 10 лет разработки на C++ вызывает довольно ощутимое отторжение.

Понимая, что так дело не пойдет, я взялся за поиск приличной альтернативы C++. Изначально подумывал про Erlang, ведь в основном я пишу что-то сетевое, но в итоге от этого варианта решил отказаться, потому как за пределами сетей Erlang мягко говоря бесполезен, а в самих сетях, зачастую, ограничен в плане набора доступных библиотек. В результате довольно долгих поисков выбор остановился на JVM, ведь JVM — это действительно кроссплатформенное решение (в отличие от того же CLR) с большой базой библиотек под нормальными лицензиями (MIT, BSD и, в худшем случае, LGPL). Плюс, в JDK, начиная с 7-й версии, появилась поддержка асинхронного ввода/вывода, т.е. возникла вполне реальная возможность писать не тормозящие где попало сетевые приложения.

К основным языкам базирующимся на JVM, само собой за исключением самой Java, относятся Clojure, Groovy и Scala. Clojure — Lisp-подобный язык, так что отмел его сразу. Да, я к Lisp отношусь хорошо, но вот куча народу вокруг — нет, так что никакой возможности реально использовать что-то Lisp-подобное я не вижу. Groovy — хороший язык, но без чего-то действительно цепляющего. А вот Scala… Да, Scala — это язык с довольно крутой кривой вхождения, при этом богатым синтаксисом и отличными возможностями.

У всех разные способы оценить пригодность языка для своих нужд. Кто-то первым делом реализует быструю сортировку, кто-то пишет Hello World. А я, обычно, пишу Echo-сервер с клиентом. Continue reading