Oberon space
General Category => Общий раздел => Тема начата: valexey от Апрель 05, 2012, 12:31:34 pm
-
http://www.opennet.ru/opennews/art.shtml?num=33534
Увидел свет релиз экспериментального языка программирования Rust 0.2, развиваемого проектом Mozilla. Rust является языком со строгой типизацией, сфокусированным на безопасной работе с памятью и обеспечении высокого параллелизма выполнения заданий. Об особенностях Rust можно прочитать в анонсе первой версии проекта. Во втором выпуске расширено число поддерживаемых целевых платформ, кроме Linux (x86 и x86_64), Mac OS X (x86 и x86_64) и Windows (x86), добавлена поддержка FreeBSD (x86_64). Всего с момента выхода версии 0.1 внесено около 1500 изменений.
Из улучшений можно отметить: поддержка callback-вызовов из программ на языке Си, увеличение производительности передачи сообщений между нитями, поддержка в языке перегрузки операторов, классов и указателей на регионы, реализация новых конструкций 'loop { ... }', 'crust fn ...', 'export foo::*;', новые модули core::{future, iter} и std::arena.
-
Эпоха безопасных языков прямо какая-то :)
-
Ну, он не шибко безопасный. Хотя конечно безопасней Оберона.
Кстати, почему то у всех этих новомодных языков (начиная с Оберона, но может кто и раньше был) взяли в моду забивать на модульность. Для человека, а не для компилятора. То есть нет даже возможности на элементарное разделение на спецификацию и реализацию модуля. Что весьма печально.
-
Про тыщщупятьсот изменений - напомнило старый анекдот: "Я как-то поймал рыбу, одна фотография которой весила 15 тонн" :)
-
Кстати, я тут на Go немного полезного для проекта пописал. Вполне себе язычок. Умеренно годный. Но из за отсутствия "обобщенки" там приходится делать в рантайме (посредством доступа к "метаинформации") то, что можно было бы сделать на этапе компиляции. Причем это на каждом шагу (по крайней мере в той области где я сейчас этот Go применяю). Поэтому ощущения от языка весьма похожи на ощущение от языка с динамической типизацией, хотя конечно все равно много лучше чем ощущения от того же питона например.
-
...элементарное разделение на спецификацию и реализацию модуля. Что весьма печально.
Чет я не очень понял. :) А с какой целью? (для человека)
-
...элементарное разделение на спецификацию и реализацию модуля. Что весьма печально.
Чет я не очень понял. :) А с какой целью?
С целью последующей вменяемой работы с исходниками. Когда я вижу тонну кода мне совсем не интересно лазить по потрохам реализаций и пытаться выцепить что же оно там экспортирует и зачем. Мне интересно пройтись по спецификациям модулей писаным ЧЕЛОВЕКОМ с человеческими же коментариями для вводимых сущностей.
Например по исходникам библиотеки писаной на Аде (благодаря наличиям спецификаций) я разбираюсь много быстрее (то есть понимаю какое место либы мне интересно, и как с этим работать) чем скажем в библиотеках на java. Документация в виде сгенерированных html'ей обычно есть и для того и для другого (причем для явы оно бывает чаще и подробней). Плюс адские исходники я смотрю обычно в каком-нибудь shell+cat|less/mc/far, а жабные - в IDE (eclipse/netbeans), которые таки генерируют нечто вроде спецификации и позволяют интерактивно по ней лазить. Но Адские спеки на модули все равно удобней и читаемей просто потому, что их пишет человек, а не генерит аццкая железка из реализации.
Более того, если есть по человечески писаные хедеры для С++ кода (то есть это когда там не аццкого фарша из #ifdef'ов) то по ним я тоже разбираюсь в сути того что там делает программа и какие её места мне нужны и важны быстрее, чем скажем в программе на Обероне. Ну и уж в коллекции модулей писаных на Модуле2/3 разбираться на порядок проще чем в обероновской аналогичной коллекции.
-
Кстати, я тут на Go немного полезного для проекта пописал.
На днях вышла 1 версия Go.
Какие еще впечатления от языка? Годится ли он как замена пхп, питона для написания, скажем, движка динамического сайта?
-
Кстати, я тут на Go немного полезного для проекта пописал.
На днях вышла 1 версия Go.
Какие еще впечатления от языка? Годится ли он как замена пхп, питона для написания, скажем, движка динамического сайта?
Я не великий знаток php/python и прочей ереси, опыта в использовании их у меня ну очень мало. Но использую сейчас Go как раз для сайта с ну о-очень динамическим контентом. С реалтаймовым контентом, я бы сказал. :-) И да, Go как раз версии 1.
-
спеки на модули все равно удобней и читаемей просто потому, что их пишет человек, а не генерит аццкая железка из реализации.
Теперь понял. В общем согласен, но справедливости ради хочу заметить, что в ЧЯ автоматически сгенерированную спецификацию на модуль человек тоже может документировать. Там правой кнопкой на имени модуля как раз оно и открывается. Но тут конечно еще остается вопрос удобства такого подхода, да и привычек тоже.
-
спеки на модули все равно удобней и читаемей просто потому, что их пишет человек, а не генерит аццкая железка из реализации.
Теперь понял. В общем согласен, но справедливости ради хочу заметить, что в ЧЯ автоматически сгенерированную спецификацию на модуль человек тоже может документировать. Там правой кнопкой на имени модуля как раз оно и открывается. Но тут конечно еще остается вопрос удобства такого подхода, да и привычек тоже.
Тут вопрос в том что первично, а что вторично. Если у нас спецификация пишется человеком, то она первична и на этапе компиляции проверяется соответствие реализации данной спецификации. В случае генерируемой спеки она вторична, и на процесс компиляции не влияет. То есть если ты потом возьмешь и поменяешь реализацию, то это обычно приводит лишь к генерации новой спецификации (из которой все написаное руками будет убрано).
В ряде сценариев разработки (это обычно когда действительно большие проекты пишутся, а не на 12 тыс строк кода) удобней именно такой подход - когда спецификация первична, а реализация вторична и обязана удовлетворять даденой спецификации.
Но вначале, когда пишем hello-world'ы разной сложности и когда у нас околоскриптовое применение языка, явная ручная спецификация модулей конечно же мешает и смотрится как у собаки пятая нога.
-
Я не великий знаток php/python и прочей ереси, опыта в использовании их у меня ну очень мало. Но использую сейчас Go как раз для сайта с ну о-очень динамическим контентом. С реалтаймовым контентом, я бы сказал. :-) И да, Go как раз версии 1.
Под Apache/ngnix или все самописное?
Это в этом проекте отсутствие обобщенки напрягает?
-
Я не великий знаток php/python и прочей ереси, опыта в использовании их у меня ну очень мало. Но использую сейчас Go как раз для сайта с ну о-очень динамическим контентом. С реалтаймовым контентом, я бы сказал. :-) И да, Go как раз версии 1.
Под Apache/ngnix или все самописное?
Это в этом проекте отсутствие обобщенки напрягает?
Используются стандартные либы Go. В том числе template/text и template/html. Ну, то есть они вне зависимости от сетевой части использовались бы (апач там или нет). Также используется модуль json. И там и там активно используется рефлекшн. То что могло бы делаться на этапе компиляции, делается в рантайме, со всеми растекающимися последствиями.
Да, а все крутится на google app engine.
-
Да, а все крутится на google app engine.
Жаль, хотелось бы узнать про опыт написания полноценного независимого приложения.
-
Да, а все крутится на google app engine.
Жаль, хотелось бы узнать про опыт написания полноценного независимого приложения.
Полноценное независимое приложение пишется в точности так же. То есть мне код менять не придется (кроме гуглоспецифичных вещей вроде гугловой авторизации). И там и там используется стандартный пакет http.
Грубо говоря, код hello world'a на gae и standalone http server будет один и тот же.
-
Впрочем, лучше один раз увидеть, чем много раз услышать.
Вот hello world писаный на Go и хостящийся на Google App Engine:
package hello
import (
"fmt"
"net/http"
)
func init() {
http.HandleFunc("/", handler)
}
func handler(w http.ResponseWriter, r *http.Request) {
fmt.Fprint(w, "Hello, world!")
}
А вот полный исходник hello world'a на Go без всякого Google App Engine, компилящийся в отдельный исполняемый файл и работающий в режиме "сам себе веб-сервер":
package hello
import (
"fmt"
"net/http"
)
func init() {
http.HandleFunc("/", handler)
http.ListenAndServe(":8080", nil) // < отличие тут
}
func handler(w http.ResponseWriter, r *http.Request) {
fmt.Fprint(w, "Hello, world!")
}
func main() { // < и тут
init()
}
Как видим, отличие только в точке входа (вместо init точкой входа является main) и собственно явным запуском главного цикла.