Comments 107
Мало сторонних библиотек — кроме как к MySQL, PostgreSQL и NoSQL-базам не подключишьсяПарсер сломался, что значит эта фраза?
Если быть честным, Go — это первый язык со статической типизацией, где она не очень мешает программировать и не заставляет писать в 2-3 раза больше кода, чем на PHP или Javascript.Наверное, не «это первый язык со статической типизацией», а «это первый язык со статической типизацией, который я знаю». Вывод типов в Haskell и Nemerle помогает не писать простыни описания типов.
Сравнивать framework для разработки веб приложений (ASP.NET) с ситемным языком — это сильно.
Наверное, не «это первый язык со статической типизацией», а «это первый язык со статической типизацией, который я знаю». Вывод типов в Haskell и Nemerle помогает не писать простыни описания типов.
Поправил, я действительно не имел ввиду, что это вообще первый язык со статической типизацией, в которой это сделано достаточно удобно :)
Мало сторонних библиотек — кроме как к MySQL, PostgreSQL и NoSQL-базам не подключишься
Парсер сломался, что значит эта фраза?
Это значит, что для подключения к MS SQL Server или Oracle требуется использовать библиотеки на Си, что на Go не очень удобно.
Эта библиотека ужасно неудобна в использовании, по крайней мере на первый взгляд. Мне кажется, для Go можно было бы придумать более удобный API… Уж проще тогда подключить нативную библиотеку на Си для работы с соответствующей СУБД и написать к ней простенькую обертку, чем использовать такой код, хоть и универсальный :)
Сделайте сравнение с языком со статической типизацией, плз. С той же Java, к примеру.
Единственное, с чем я могу сравнить — это с Си, поскольку ни с Java, ни с .NET я особо не работал (инструменты для написания на Java (например Eclipse) или .NET (Visual Studio) работают уж очень неповоротливо, что меня ужасно раздражает).
Если кратко, то Go — это Си со сборщиком мусора и сравнимый по удобству с PHP. Для меня этого было достаточно :).
Если кратко, то Go — это Си со сборщиком мусора и сравнимый по удобству с PHP. Для меня этого было достаточно :).
Неповоротливо на вашем допотопном компе вы хотели сказать? У всех ничего не тормозит.
Строгая типизация это то что останавливает попробывать python или ruby — я хочу контролировать и видеть какой тип у обьекта
Строгая типизация это то что останавливает попробывать python или ruby — я хочу контролировать и видеть какой тип у обьекта
Джава вообще никогда ни разу не тормозит. А скажете, что где-то тормозит — Оракл вас засудит.
Вы не поверите, но есть Real-Time Java. От того же Oracle. И она действительно сертифицирована на real time
На очень, очень медленный риал-тайм.
(real time != быстро, real time == фиксированное время реакции).
(real time != быстро, real time == фиксированное время реакции).
Ну, справедливости ради, надо отметить, что пиковая производительность у Java выше, чем у Go в текущей реализации языка и с текущими реализациями часто используемых алгоритмов (см. довольно популярный бенчмарк). Но производительность программ на Java лично меня обычно не воодушевляет, наверное я что-то не так делаю :)
Кстати, в этом бенчмарке Go не так и плох, сравнимо с Java/C#, местами лучше, но так нехило просаживается на тестах binary-trees и regex-dna. Интересно бы узнать, почему.
На двоичных деревьях там есть альтернативная реализация с free list, которая не показывает такого провала в производительности, что дает основания полагать, что это проблема в GC. А regex-dna тормозит из-за того, что библиотека регулярных выражений написана с нуля на самом Go
А, точно, сами разработчики пишут, что у них какая-то затычка вместо нормальной библиотеки регулярок. Странно это, уж что-что, а регулярки-то могли отдельной эффективной библиотекой добавить, чтобы так в тестах не сливать. Видимо, у них другие цели.
Проблема та же самая, что в C# с взаимодействием между managed code и unmanaged code — в Go есть сборщик мусора, в остальных языках, вроде Си, его нет, и взаимодействие между кодом на Си и на Go немного затруднено. Вроде как была раньше обертка для PCRE на Go, но разработчики Go действительно очень любят решения на самом Go, а не привязываться к библиотекам на Си (что можно понять, в общем-то :))
Так в данном случае не нужно мешать управляемый код с неуправляемым, просто позвать внешнюю динамическую библиотеку. Учитывая нацеленность Go на скорость, было бы логичнее и в этом случае ориентироваться на неё, а не на то что там разработчики любят :)
Честно — не знаю :). В конце концов, на Go можно позволить себе такую роскошь, как посимвольный разбор там, где пришлось бы иначе писать очень сложные регулярные выражения, и лично мне это нравится :). А простенькая библиотека для регулярных выражений в Go итак есть. Если хочется сочинять какие-то очень сложные реги, надо подумать о том, какой смысл тогда вообще писать на Go, ведь сложные регулярные выражения работают в целом очень медленно…
А код библиотеки разве не в текущем процессе выполняется? Если так, то эти «простые» вызовы могут привести к потере памяти.
Не поверите: в Java библиотека регулярных выражений написана на Java.
Странно, но NYSE использует JBoss, который написан на java. А у них там до 100000 транзакций в секунду.
>> real time == фиксированное время реакции
О противоположном никто не говорит. Но RT для java есть.
А вот какие характеристики у GC в Go?
О противоположном никто не говорит. Но RT для java есть.
А вот какие характеристики у GC в Go?
Вопрос не в том, что Оракл засудит. В работе с Java надо учитывать две особенности:
— время старта и «разогрева» VM, и
— неродной для операционной системы GUI.
В целом серверные приложения на Java работают очень быстро, из десктопных быстрыми можно назвать монстров-IDE. Если вам кажется, что они работают медленно, то могу вас заверить — если бы их написали на C++, они бы работали точно также (правда, багов в них было бы на порядок больше).
А еще со временем Java становится быстрее. Пять лет назад на моем ноутбуке IDEA и Eclipse еле ворочались, а сейчас фактически летают, и железо я не обновлял — только JDK :)
— время старта и «разогрева» VM, и
— неродной для операционной системы GUI.
В целом серверные приложения на Java работают очень быстро, из десктопных быстрыми можно назвать монстров-IDE. Если вам кажется, что они работают медленно, то могу вас заверить — если бы их написали на C++, они бы работали точно также (правда, багов в них было бы на порядок больше).
А еще со временем Java становится быстрее. Пять лет назад на моем ноутбуке IDEA и Eclipse еле ворочались, а сейчас фактически летают, и железо я не обновлял — только JDK :)
UFO just landed and posted this here
У Ruby и Python динамическая типизация.
UFO just landed and posted this here
чё?:)
UFO just landed and posted this here
Разницу между строгой типизацией(статической) и динамической типизацией представляете? То что у ruby написано строгая динамическая типизация не означает что она статическая.
Вообщем присваивать тип переменной во время присваивания значения — меня не устраивает.
Вообщем присваивать тип переменной во время присваивания значения — меня не устраивает.
Термин не очень-то строгий, много значений:
en.wikipedia.org/wiki/Strongly_typed_programming_language
en.wikipedia.org/wiki/Strongly_typed_programming_language
UFO just landed and posted this here
the term strong typing is used to describe those situations where programming languages specify one or more restrictions on how operations involving values having different data types can be intermixed. Its antonym is weak typing
Прочитайте еще раз процитированное. Внимательно. Это никак не относится к статической типизации, то есть к типизации во время компиляции. Это только лишь о том, что есть связанные с типами ограничения. В рантайме они применяются, или во время компиляции — не уточняется.
Прочитайте еще раз процитированное. Внимательно. Это никак не относится к статической типизации, то есть к типизации во время компиляции. Это только лишь о том, что есть связанные с типами ограничения. В рантайме они применяются, или во время компиляции — не уточняется.
Пардон, не понял сразу, на какой вы стороне.
UFO just landed and posted this here
Строгая динамическая типизация, что не есть статическая типизация
>Язык и компилятор не вызывают ощущения чего-то монстрообразного и неповоротливого, как Java или .NET (что, собственно, и является основной причиной, почему я не пишу на Java).
Не знаю, как у вас, у меня csc (C# compiler) за секунды отрабатывает, ни разу не вызывая ощущения монстрообразности, в отличие от компании Google…
Компилятор C или Java там рядом не валялись по скорости… C — из-за инклюдов, а Java — из-за jar-файлов…
В языке PHP удобства, как и у многих на даче, на улице… :)
Не знаю, как у вас, у меня csc (C# compiler) за секунды отрабатывает, ни разу не вызывая ощущения монстрообразности, в отличие от компании Google…
Компилятор C или Java там рядом не валялись по скорости… C — из-за инклюдов, а Java — из-за jar-файлов…
В языке PHP удобства, как и у многих на даче, на улице… :)
Компилятор C# может и работает быстро, а вот зато сами приложения на C# высокой скоростью работы (а особенно первоначальной загрузки программы) как-то не отличаются…
Помимо этого, в Go компиляция всего package tree занимает порядка 5 секунд (а там полтыщи только .go-файлов)…
Хм, для своих задач — разработка веб-страниц, ИМХО, PHP отлично подходит, в основном благодаря очень богатым встроенным возможностям. Дальше троллить на эту не очень хочу, если честно.
Помимо этого, в Go компиляция всего package tree занимает порядка 5 секунд (а там полтыщи только .go-файлов)…
В языке PHP удобства, как и у многих на даче, на улице… :)
Хм, для своих задач — разработка веб-страниц, ИМХО, PHP отлично подходит, в основном благодаря очень богатым встроенным возможностям. Дальше троллить на эту не очень хочу, если честно.
а вот зато сами приложения на C# высокой скоростью работы (а особенно первоначальной загрузки программы) как-то не отличаются
Ну это, строго говоря, неправда.
Ну это, строго говоря, неправда.
>Компилятор C# может и работает быстро, а вот зато сами приложения на C# высокой скоростью работы (а особенно первоначальной загрузки программы) как-то не отличаются…
Ngen при инсталляции вашей программы вам в помощь… Сразу все летать будет, главное, не лениться, добавить строчку в инсталляционный скрипт.
Ngen при инсталляции вашей программы вам в помощь… Сразу все летать будет, главное, не лениться, добавить строчку в инсталляционный скрипт.
1) Visual Studio 2010, по моим ощущениям, не тормозит;
2) Игры на XNA вообще летают.
2) Игры на XNA вообще летают.
Java-компилятор, несмотря на то, что пробегается по jar'ам, тоже очень быстр, срабатывает за секунды даже в больших проектах. Проблема в первую очередь касается C++ и C, из-за того, как обрабатываются include-файлы.
А чо не с Фортраном?
Если с чем-то сравнивать, я голосую за Nemerle (CLR) и Scala (JVM). А там и смотреть на результаты
Если с чем-то сравнивать, я голосую за Nemerle (CLR) и Scala (JVM). А там и смотреть на результаты
Фреймворки есть какие-то или или написание любого проекта начинается с «биндимся к 80-му порту, слушаем, разбираем запрос, формируем ответ начиная с „HTTP/1.1 200 OK“, ...»?
>для каждого хоста приходится писать целый веб-сервер и следить за тем, чтобы он случайно не упал
Это требование языка? Нельзя написать сервер, обслуживающий несколько хостов?
>для каждого хоста приходится писать целый веб-сервер и следить за тем, чтобы он случайно не упал
Это требование языка? Нельзя написать сервер, обслуживающий несколько хостов?
Фреймворки есть какие-то или или написание любого проекта начинается с «биндимся к 80-му порту, слушаем, разбираем запрос, формируем ответ начиная с „HTTP/1.1 200 OK“, ...»?
Встроенный package http делает бОльшую часть «грязной работы» за вас, за исключением того, что он пока что не умеет парсить multipart/form-data (в моем backend для JsHttpRequest это по сути единственная вещь, которую мне пришлось реализовывать вручную).
Т.е. простейший веб-сервер выглядит вот так:
package main
import (
"http"
"io"
"log"
)
// hello world, the web server
func HelloServer(c *http.Conn, req *http.Request) {
io.WriteString(c, "hello, world!\n")
}
func main() {
http.HandleFunc("/hello", HelloServer)
err := http.ListenAndServe(":12345", nil)
if err != nil {
log.Exit("ListenAndServe: ", err.String())
}
}Как видно, работы с сокетами тут не требуется :). Но для поддержки виртуальных хостов надо самому парсить заголовок Host: (т.е. прочитать req.Header[«Host»]) и использовать соответствующий switch/case :).
Спасибо за ответ и пост, надо будет попробовать. По идее в связке с nginx должен летать
Я думаю, что если у Вас есть отдельный свободный IP, то лучше повесить веб-сервер прямо на него, а не через nginx — я не уверен, что, к примеру, WebSocket будет работать нормально через reverse proxy от nginx.
Отдельный IP не проблема, к тому же можно какой-нить 8080 порт использовать для чистой статики (графика, css, js), но тут вопрос, смогу ли я написать веб-сервер, выбирающий из кэша (на ФС ли, или, например, memcached) кэш динамических страниц также эффективно как nginx.
О вебсокетах пока не думал, хотя пора, но, наверное, в случаях со сложностями в проксировании именно обработчик сокетов лучше повесить на отдельный IP/порт, а сообщения от сервера к клиенту при необходимости кэшировать на уровне приложения
О вебсокетах пока не думал, хотя пора, но, наверное, в случаях со сложностями в проксировании именно обработчик сокетов лучше повесить на отдельный IP/порт, а сообщения от сервера к клиенту при необходимости кэшировать на уровне приложения
Так все-таки, зачем нужен язык Go с точки зрения PHP-разработчика? Откройте секрет:)
Для написания высокопроизводительных демонов или системных утилит — в качестве альтернативы PHP с высокой производительностью
Как альтернатива PHP для написания системных утилит?? Видимо, я что-то пропустил в этой жизни… о_О
На PHP тоже можно писать системные утилиты, но он для этого плохо подходит — банально приходится больше кода писать :). Демоны тоже можно писать, но это тоже считается не айс (и часто это действительно так).
На брейнфаке тоже «можно», но если кто-то вдруг напишет «язык Go — хорошая альтернатива брейнфаку для написания системных утилит», то его точно упекут в дурку. Ну либо (в зависимости от контекста высказывания) будут очень плохого мнения о языке Go, раз уж он является хорошей альтернативой лишь брейнфаку %)
Теперь серьёзно: если рассматривать язык в качестве кандидата на написание системных утилит, то сравнивать нужно с языком, который используется для этой цели в 95% случаев, а не с языком, на котором «можно» их писать.
Теперь серьёзно: если рассматривать язык в качестве кандидата на написание системных утилит, то сравнивать нужно с языком, который используется для этой цели в 95% случаев, а не с языком, на котором «можно» их писать.
попробуйте node.js ;)
А почему просто не компилировать код связкой HipHop+C-compiler? Я в соседнем посте про него уже заикался, но повторюсь.
На нём только консольные приложения писать можно, или графический GUI тоже есть?
Давно пора, миру необходим новый статический язык с компиляцией в нативный код. Идеальный такой язык должен унаследовать синтаксис от c/c++, а типизацию от pascal'я и избавится от нетривиальных конструкций.
> типизацию от pascal
очень смешно :-)
очень смешно :-)
А что, типизация в си/с++ это настоящий цирк, там ее нет по сути. Динамическая типизация для такого языка не подходит.
Ну, есть как бы и гораздо более современные и полезные системы типов, чем примитивнейшая паскалевская.
Стоит поучится теории построения компиляторов, а потом говорить какая система примитивная, а какая нет.
Вы это мне говорите?!? Не, серьёзно?
В паскале самый примитивный вариант type propagation. Проще вообще ничего не бывает, даже в Си система типов сложнее, потому как там есть этот гнусный неявный array to pointer decay.
Хотите узнать, что такое сложные и мощные системы типов? Хотите поучиться сначала, а потом говорить другим, чему им стоит учиться? Ну начинайте, вперед:
www.cse.chalmers.se/~ulfn/papers/afp08/tutorial.pdf
coq.inria.fr/doc/toc.html
www.lambdassociates.org/Book/page143.htm
В паскале самый примитивный вариант type propagation. Проще вообще ничего не бывает, даже в Си система типов сложнее, потому как там есть этот гнусный неявный array to pointer decay.
Хотите узнать, что такое сложные и мощные системы типов? Хотите поучиться сначала, а потом говорить другим, чему им стоит учиться? Ну начинайте, вперед:
www.cse.chalmers.se/~ulfn/papers/afp08/tutorial.pdf
coq.inria.fr/doc/toc.html
www.lambdassociates.org/Book/page143.htm
Почти у всех у них ноги растут из паскаля. А точнее, из оберона и модулы.
у паскаля собственные ноги растут из алгола =)
из того же алгола проросла симула, а из симулы проросло ОО в других языках.
системы типов а-ля ML (и уж тем более мощные системы типов а-ля Haskell) это вообще фрукты другого дерева.
из того же алгола проросла симула, а из симулы проросло ОО в других языках.
системы типов а-ля ML (и уж тем более мощные системы типов а-ля Haskell) это вообще фрукты другого дерева.
Да да, расскажите мне, где это у типизации по Карри ноги из Паскаля растут. И что общего между алгоритмом Хиндли-Милнера и Паскалем.
Haskell, OCaml, Scala, C# :-)
Давно уже есть D, так же известный как Dолгострой. :)
Есть язык D
Спасибо, интересно было почитать, а были бы хоть какие-нибудь маленькие примеры кода — было бы вообще замечательно.
Go — это первый язык со статической типизацией, который я видел, где она не очень мешает программировать и не заставляет писать в 2-3 раза больше кода, чем на PHP или Javascript.
Scala?
Scala?
Скажу честно — не смотрел, ибо JVM.
Ну, например, смотрите (код приводится в пример в Introduction к Scala):
Scala:
В Go, чтобы переменные или константы (в данном случае это должно быть константой) не были глобальными, их имя просто не должно начинаться с большой буквы. Итак, тот же код на Go (я добавил подчеркивание в начале):
Хммм ;)
Scala:
private val CMD_ADD = 0
private val CMD_REMOVE = 1
private val CMD_ADDX = 2
private val CMD_REMOVE_TENTATIVE = 3
private val CMD_SAVE_XID = 4
private val CMD_UNREMOVE = 5
private val CMD_CONFIRM_REMOVE = 6
private val CMD_ADD_XID = 7В Go, чтобы переменные или константы (в данном случае это должно быть константой) не были глобальными, их имя просто не должно начинаться с большой буквы. Итак, тот же код на Go (я добавил подчеркивание в начале):
const
(
_CMD_ADD = iota
_CMD_REMOVE
_CMD_ADDX
_CMD_REMOVE_TENTATIVE
_CMD_SAVE_XID
_CMD_UNREMOVE
_CMD_CONFIRM_REMOVE
_CMD_ADD_XID
)Хммм ;)
Разве это не тот же enum в c++ или делфи? Приведение в тип int перечисляемого типа дает число от 0 до N.
Да, если в таком простом случае, это тот же enum. А если написать вместо просто iota, скажем, iota*iota, то получим список квадратов чисел, вроде такого:
Выражение с использованием iota может быть сколь угодно сложным, лишь бы оно было константным
const (
_1_2 = iota*iota // 1
_2_2 // 4
_3_2 // 9
_4_2 // 16
// ...
)Выражение с использованием iota может быть сколь угодно сложным, лишь бы оно было константным
Короче, ваша правда :)
Но! Глобальные переменные — это ересь! Область жизни переменной не должна превышать одного экрана.
Но! Глобальные переменные — это ересь! Область жизни переменной не должна превышать одного экрана.
Для средне-больших проектов конечно. Для скриптов и глобальные хороши.
Мой пример — это объявление приватной константы, потому что имя константы не начинается с большой буквы (приватной по отношению к файлу).
>Но! Глобальные переменные — это ересь! Область жизни переменной не должна превышать одного экрана.
Что считаем переменной — область памяти со значением или один из указателей на неё? Область жизни или область видимости? А как быть с теми значениями, которые действительно нужны везде, особенно в языках в которых фактически нет разницы между, например, целым числом и синглтон классом, или он тоже должен жить не более одного экрана? Или предлагаете какой-нибудь параметр, например, кодировку передавать по значению во все функции/методы?
Что считаем переменной — область памяти со значением или один из указателей на неё? Область жизни или область видимости? А как быть с теми значениями, которые действительно нужны везде, особенно в языках в которых фактически нет разницы между, например, целым числом и синглтон классом, или он тоже должен жить не более одного экрана? Или предлагаете какой-нибудь параметр, например, кодировку передавать по значению во все функции/методы?
Этот код с iota мне не нравится. Например, у меня есть мегабайты кода. Встретил я в них где-то _CMD_CONFIRM_REMOVE. Кликнул по ней с Ctrl, перешёл на определение. И мне надо высчитывать чему она равна в уме? Это замедляет работу.
Сдаётся мне, что тут дело не в типизации
Да банально C#. Всё подряд он не выводит, как та же Скала, но даже и с его простеньким выводом типов пишется довольно-таки легко и ненавязчиво. Ну или, например, JavaFX script (жаль только там нет поддержки generics).
> Язык Go с точки зрения PHP-разработчика
Pascal с точки зрения программиста на Basic…
Изобразительное искусство с точки зрения маляра…
Нейрохирургия с точки зрения дентиста…
Pascal с точки зрения программиста на Basic…
Изобразительное искусство с точки зрения маляра…
Нейрохирургия с точки зрения дентиста…
> мне хотелось увидеть какой-нибудь язык, который бы принципиально чем-то отличался от PHP, но при этом был пригоден для веба
Наверное меня закидают камнями, но ещё пригоден для веба Python и Ruby. Сам писал на PHP 3 года, после знакомства с Python, хочется писать только на нём.
P.S. После краткого знакомства с Ruby, уже лень и на Python писать, но производительность в некоторых моментах, отстутствие опыта не дает перейти.
Наверное меня закидают камнями, но ещё пригоден для веба Python и Ruby. Сам писал на PHP 3 года, после знакомства с Python, хочется писать только на нём.
P.S. После краткого знакомства с Ruby, уже лень и на Python писать, но производительность в некоторых моментах, отстутствие опыта не дает перейти.
Sign up to leave a comment.
Язык Go с точки зрения PHP-разработчика