The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Бета-выпуск языка программирования Rust 1.0, opennews (??), 04-Апр-15, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


25. "Бета-выпуск языка программирования Rust 1.0"  –7 +/–
Сообщение от Аноним (-), 04-Апр-15, 14:44 
Зачем нужен Rust если есть Ди?
Ответить | Правка | Наверх | Cообщить модератору

26. "Бета-выпуск языка программирования Rust 1.0"  –1 +/–
Сообщение от Аноним (-), 04-Апр-15, 14:57 
Дык... вестимо зачем - для неосиляторов С/C++. Им видите-ли сложно offset по указателю посчитать, все время бедняжки за границу выходят. А еще после того как покакают в штан^W в память, забывают подтеретьс^W очистить ее. Вот и нужна этим детям мамочк^W GC, который их обкаканые штанишки менять будет.
Ответить | Правка | Наверх | Cообщить модератору

28. "Бета-выпуск языка программирования Rust 1.0"  +4 +/–
Сообщение от Аноним (-), 04-Апр-15, 15:25 
в Rust нет GC, только опциональный подсчет ссылок
Ответить | Правка | Наверх | Cообщить модератору

29. "Бета-выпуск языка программирования Rust 1.0"  –2 +/–
Сообщение от Аноним (-), 04-Апр-15, 15:28 
Ну в Go есть, разница то, блин.
Ответить | Правка | Наверх | Cообщить модератору

69. "Бета-выпуск языка программирования Rust 1.0"  +4 +/–
Сообщение от Аноним (-), 04-Апр-15, 21:43 
Главное, что мнение имеешь - подробности фигня :)
Ответить | Правка | Наверх | Cообщить модератору

30. "Бета-выпуск языка программирования Rust 1.0"  +7 +/–
Сообщение от Аноним (-), 04-Апр-15, 15:39 
Ну давай разберем по порядку тобой написанное.
> Им видите-ли сложно offset по указателю посчитать, все время бедняжки за границу выходят.

Ошибки делают абсолютно все. Если ты думаешь, что ты их не делаешь, то у тебя проблемы. Это хорошо, когда язык защищает от части ошибок.
> А еще после того как покакают в штан^W в память, забывают подтеретьс^W очистить ее.

В С++ так не делают. См. RAII.
> Вот и нужна этим детям мамочк^W GC

В расте нет GC. Там используется тот же самый RAII.


Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

33. "Бета-выпуск языка программирования Rust 1.0"  –1 +/–
Сообщение от Аноним (-), 04-Апр-15, 15:48 
> В С++ так не делают. См. RAII.

Т.е. в декструкторе не надо delete вызывать? А если я пишу на С++ без классов, но использую перегрузку функций (потому и С++, а не Си).

Ну и потом... если я создал объект класса динамически через "new", то кто за меня delete вызовет? Пушкин? Или может Google?

Ответить | Правка | Наверх | Cообщить модератору

35. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от XXasd (?), 04-Апр-15, 16:08 
Известно кто -- shared_ptr .. Если только нет циклических ссылок :-)
Ответить | Правка | Наверх | Cообщить модератору

36. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Аноним (-), 04-Апр-15, 16:12 
> Т.е. в декструкторе не надо delete вызывать?

Нет. Деструкторы unique_ptr, shared_ptr, string и контейнеров уже написаны и сами вызовутся из деструктора твоего класса.
Иногда нужно освобождать какие-то другие ресурсы. Но один раз написать это в специально предназначенной для этого функции – это не то же самое, что писать delete по всему коду для каждого объекта. Вероятность ошибки сводится к минимуму, и найти такую ошибку проще.

> А если я пишу на С++ без классов, но использую перегрузку функций (потому и С++, а
> не Си).

Нельзя считать недостатком языка то, что ты по известным тебе одному причинам не пользуешься его возможностями. И нет, "С++ без классов" - это не С++.

> Ну и потом... если я создал объект класса динамически через "new", то
> кто за меня delete вызовет?

См. выше про unique_ptr, shared_ptr, string и контейнеры. Кроме того, начиная с С++14 ты _вообще_ не создаешь объекты через new, т.к. там появилась функция make_unique.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

38. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Аноним (-), 04-Апр-15, 16:27 
> Нет. Деструкторы unique_ptr, shared_ptr, string и контейнеров уже написаны и сами вызовутся из деструктора твоего класса

Это всё шаблоны-обертки из boost`а (перекочевавшие в стандарт), в операторе присваивания которого просто счетчик указателей инкрементируется и декрементируется в деструкторе. Под капотом все тот же new/delete.

Ответить | Правка | Наверх | Cообщить модератору

40. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Аноним (-), 04-Апр-15, 16:37 
Я знаю, лол. И что с того? Пользователям языка больше не нужно руками работать с памятью.
Ответить | Правка | Наверх | Cообщить модератору

44. "Бета-выпуск языка программирования Rust 1.0"  –1 +/–
Сообщение от Аноним (-), 04-Апр-15, 17:11 
> Я знаю, лол. И что с того? Пользователям языка больше не нужно руками работать с памятью.

В С++ можно так писать что не нужно руками работать. Читать надо умные книги, эффективные техники программирования на С++ уже сто лет как известны нам, но похоже не вам.

Ответить | Правка | Наверх | Cообщить модератору

46. "Бета-выпуск языка программирования Rust 1.0"  –2 +/–
Сообщение от Аноним (-), 04-Апр-15, 17:17 
o_O
Ответить | Правка | Наверх | Cообщить модератору

117. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от клоун (?), 06-Апр-15, 17:57 
Просвети.

Есть класс Геометрические фигуры, от него унаследованы классы Круг, Треугольник, Квадрат.

Создаём L1 из геометрических фигур.

Нужно:
1. реализовать единый метод Нарисовать() без хранения переменной типа геометрической фигуры внутри класса
2. реализовать корректное освобождение памяти при вызове delete

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

119. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от iZEN (ok), 06-Апр-15, 19:35 
> Просвети.
> Есть класс Геометрические фигуры, от него унаследованы классы Круг, Треугольник, Квадрат.

Ещё для разнообразия: Точка, Окружность, Эллипс, Многоугольник.

Ответить | Правка | Наверх | Cообщить модератору

129. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от клоун (?), 06-Апр-15, 23:32 
Это не шутка. Меня в какое-то время надоело бодаться с ООП, которое якобы что-то там должно упрощать, но вместо этого задалбывает синтаксисом сильнее, чем облегчает работу. В итоге я вернулся к функциональному программированию с С++'овым синтаксисом.

Тут чувак корчит из себя эксперта, может он знает решение.

По факту получается, что невозможно реализовать Нарисовать() не храня тип фигуры. А хранение типа фигуры ставит крест на всяком наследовании, ибо нахрена козе баян и ручное жонглирование классами, когда можно тупо создать файл НарисоватьФигуру.cpp и запихать в него всё рисование, а в НарисоватьФигуру.h уйдут все макроопределения. В ООП то же самое будет разбросано (как после взрыва) по десятку файлов в каждом из которых по 2-5 строчек кода.

И зачем мне деструктор класса, если я должен сам хранить какого он типа и преобразовывать тип к правильному лишь чтобы вызвался правильный деструктор, когда я могу сразу запихать всё это в switch.

Хранить тип Строка в классе лишь чтобы не забыть в конце освободить память - я амнезией не страдаю. А там где страдаю (как в примере выше), там мне ООП ничем не помогает.

Как был код команда-условие-переход, таковым он и остался. А всякие MMX, лямбда-функции, квантовые вычисления, ООП (в большинстве случаев) и пр. - попытки поиграть в игру "сломай мозг" и не более того.

Ответить | Правка | Наверх | Cообщить модератору

131. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от ........................ (?), 07-Апр-15, 00:52 
> И зачем мне деструктор класса, если я должен сам хранить какого он
> типа и преобразовывать тип к правильному лишь чтобы вызвался правильный деструктор,
> когда я могу сразу запихать всё это в switch.

http://cpp-reference.ru/articles/virtual-destructor/

Ответить | Правка | Наверх | Cообщить модератору

137. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от клоун (?), 07-Апр-15, 11:51 
Когда речь о переменных, это работает, т.к. компилятор отслеживает человеческую глупость. Когда речь об L1 - нет, т.к. никакой дополнительной информации о типе класса при выделении памяти компилятор не добавляет и следовательно тип класса при удалении не знает.
Ответить | Правка | Наверх | Cообщить модератору

139. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от ........................ (?), 07-Апр-15, 15:14 
> никакой дополнительной информации о типе класса
> при выделении памяти компилятор не добавляет
> и следовательно тип класса при удалении не знает.

http://www.ycshao.com/?p=338

Effective C++ item 7: Declare destructors virtual in polymorphic base classes

Reference: “Effective C++” Third Edition by Scott Meyers.

Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

48. "Бета-выпуск языка программирования Rust 1.0"  +1 +/–
Сообщение от Аноним (-), 04-Апр-15, 17:20 
Понимаешь в чем прелесть С++ - эти шаблоны опциональны и по сути своей реализации являются просто wrapper'ом надо new/delete. Хочешь - руками работай с памятью, не хочешь - юзай shared_ptr. Более того любой С++ программист знакомый с С++ больше года и знающий что можно перегружать operator=, легко сам такой shared_ptr напишет.
Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

55. "Бета-выпуск языка программирования Rust 1.0"  +1 +/–
Сообщение от Аноним (-), 04-Апр-15, 17:49 
Во-первых, у меня уже сомнения в том, что ты напишешь полноценный shared_ptr, и даже в том, что ты нормально знаешь его устройство. Но речь не о том.
Напомню, речь шла о том, что якобы в С++ надо писать delete, а неосиляторы забывают. Потом я сказал, что хорошие погромисты в хороших программах на С++ не пишут delete вообще. Что ты хотел сказать своим комментарием применительно к исходному топику?
Ответить | Правка | Наверх | Cообщить модератору

61. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Аноним (-), 04-Апр-15, 18:12 
> Во-первых, у меня уже сомнения в том, что ты напишешь полноценный shared_ptr,
> и даже в том, что ты нормально знаешь его устройство. Но
> речь не о том.
> Напомню, речь шла о том, что якобы в С++ надо писать delete,
> а неосиляторы забывают. Потом я сказал, что хорошие погромисты в хороших
> программах на С++ не пишут delete вообще. Что ты хотел сказать
> своим комментарием применительно к исходному топику?

Раньше я как-то писал, а теперь разучился что ли? Ты ведь полюбому и сам знаешь принцип работы shared_ptr, так сказать, на моллекулярном уровне, и явно понимаешь, что я лишь написал самый базовый принцип его работы основанный на инкрементированнии счетчика и присвании указателя в перегруженном operator=? А потом я ниже тебе ответил, что И РАНЬШЕ не надо было руками работать с памятью, а достаточно было лишь один раз реализовать свой собственный аналог shared_ptr (ну не было тогда boost). То, что за тебя кто-то в бусте обернул new/delete в шаблон, не означает что ручное управление памятью куда-то делось, он просто скрыто под одеялом.

Ответить | Правка | Наверх | Cообщить модератору

57. "Бета-выпуск языка программирования Rust 1.0"  +1 +/–
Сообщение от Аноним (-), 04-Апр-15, 18:03 
Я это собственно к тому, что и раньше не надо было руками работать - написал один раз класс-шаблон со приватным членом-счетчиком ссылок и инкрементируешь его в operator=. Это техника известна хер знает сколько лет и, как я выше уже писал, любой С++ программист ее всегда применял. Но для всяких недопрограммистов на Rust и особенно на Go, это видимо какая-то инопланетная магия. Так что твоё "теперь не надо руками работать" - мимо, никогда не надо было, если один раз сделать. Такими тенденциями как в Go и Rust через лет 5 ручное управление памятью станет в разряд эдакого супер-пупер-хардко-профи скиллом, хотя это ваще тривиальнейшая вещь, которой нас еще в школе обучали.
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

59. "Бета-выпуск языка программирования Rust 1.0"  +1 +/–
Сообщение от Аноним (-), 04-Апр-15, 18:08 
Сам чего-то придумал – сам поговорил. Ок.
Ответить | Правка | Наверх | Cообщить модератору

73. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Orduemail (ok), 04-Апр-15, 23:19 
Так я не понял -- что тебе надо от языка? Работа с памятью напрямую, или возможность избежать работы с памятью напрямую при помощи всяких костылей?
Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

123. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Аноним (-), 06-Апр-15, 21:06 
> Так я не понял -- что тебе надо от языка? Работа с
> памятью напрямую, или возможность избежать работы с памятью напрямую при помощи
> всяких костылей?

И то и другое. Хорошо когда инструмент гибкий.


Ответить | Правка | Наверх | Cообщить модератору

126. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Orduemail (ok), 06-Апр-15, 21:58 
>> Так я не понял -- что тебе надо от языка? Работа с
>> памятью напрямую, или возможность избежать работы с памятью напрямую при помощи
>> всяких костылей?
> И то и другое. Хорошо когда инструмент гибкий.

Тогда твоим выбором должен быть rust.

Ответить | Правка | Наверх | Cообщить модератору

148. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Аноним (-), 08-Апр-15, 21:48 
> Тогда твоим выбором должен быть rust.

Странно, мой выбор ни у кого не занимал.

Ответить | Правка | Наверх | Cообщить модератору

151. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Orduemail (ok), 08-Апр-15, 22:34 
>> Тогда твоим выбором должен быть rust.
> Странно, мой выбор ни у кого не занимал.

Что в этом странного? Обычно занимает?

Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

79. "Бета-выпуск языка программирования Rust 1.0"  –1 +/–
Сообщение от Krozemail (??), 05-Апр-15, 01:01 
> Т.е. в декструкторе не надо delete вызывать?

Послушай, ну, если ты настолько суров, что даже в деструкторе не вызываешь delete, то попрограммируй пока на Бейсике.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

85. "Бета-выпуск языка программирования Rust 1.0"  +2 +/–
Сообщение от Аноним (-), 05-Апр-15, 06:52 
Пожалуйста, позвольте мне не вызывать в деструкторе delete, если конструктор у меня ничего в кучу не аллоцирует. Можно?
Ответить | Правка | Наверх | Cообщить модератору

41. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Аноним (-), 04-Апр-15, 16:53 
Дык, осиляторов в живой природе пока никто не наблюдал, в комментах разве что...
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

43. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Аноним (-), 04-Апр-15, 17:08 
> Дык, осиляторов в живой природе пока никто не наблюдал, в комментах разве что...

Я наблюдал.

Ответить | Правка | Наверх | Cообщить модератору

47. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Аноним (-), 04-Апр-15, 17:17 
> Я наблюдал.

Что они написали?

Ответить | Правка | Наверх | Cообщить модератору

51. "Бета-выпуск языка программирования Rust 1.0"  +1 +/–
Сообщение от Аноним (-), 04-Апр-15, 17:26 
>> Я наблюдал.
> Что они написали?

Компиляторы и линкеры пишут, которыми потом неосиляторы свой код компилят/линкуют.

Ответить | Правка | Наверх | Cообщить модератору

98. "Бета-выпуск языка программирования Rust 1.0"  +1 +/–
Сообщение от Аноним (-), 05-Апр-15, 12:32 
Вечно дырявая JRE тому подтверждение.
Ответить | Правка | Наверх | Cообщить модератору

54. "Бета-выпуск языка программирования Rust 1.0"  +1 +/–
Сообщение от Аноним (-), 04-Апр-15, 17:46 
Я наблюдал как команда писала ядро проекта на С++ и код был очень ровным. Вот тогда меня и научили "вменяемому" программированию на С++ и научили ненавидеть Java :)
Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

60. "Бета-выпуск языка программирования Rust 1.0"  +5 +/–
Сообщение от Аноним (-), 04-Апр-15, 18:11 
От жабки мало кто в восторге, но это не делает плюсокодеров сверхлюдьми, они ошибаются, как и все остальные, постоянные фиксы уязвимостей в тех же браузерах тому доказательство.
Ответить | Правка | Наверх | Cообщить модератору

62. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Аноним (-), 04-Апр-15, 18:29 
Сверхлюди тоже не идеальны и бывает, что ошибаются, Таков уж мир.
Ответить | Правка | Наверх | Cообщить модератору

101. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Аноним (-), 05-Апр-15, 19:56 
На Java ругаются только дети-максималисты, в жизни не писавшие вещей сложнее университетских лаб, это если еще профильное образование имеется, а то и вообще Hello, world - предел. Вменяемые люди знают отличительные черты профессиональных инструментов и умеют пользоваться ими к месту.
Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

106. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Crazy Alex (ok), 05-Апр-15, 23:57 
Проблема в том, что жабка (точнее - весь стек J2EE) на своём месте в проектах такой величины,  которых не так уж много. А в более мелких её практики - суровый оверкилл. Биллинг опсоса на ней написать - да, нормально. А небольшой application server или движок веб-приложения - хочется взять что-нибудь, где соотношение "количество смысла/количество строк" получше.
Ответить | Правка | Наверх | Cообщить модератору

108. "Бета-выпуск языка программирования Rust 1.0"  –1 +/–
Сообщение от csdoc (ok), 06-Апр-15, 01:00 
> Проблема в том, что жабка (точнее - весь стек J2EE) на своём
> месте в проектах такой величины,  которых не так уж много.
> А в более мелких её практики - суровый оверкилл. Биллинг опсоса
> на ней написать - да, нормально. А небольшой application server или
> движок веб-приложения - хочется взять что-нибудь, где соотношение
> "количество смысла/количество строк" получше.

Java EE уже не нужен,

http://projects.spring.io/spring-framework/ подходит для проектов практически любой сложности,

если хочется в начале не тратить много времени на конфигурирование приложения - тогда http://projects.spring.io/spring-boot/ - здесь "количество смысла/количество строк" будет максимальным.

Ответить | Правка | Наверх | Cообщить модератору

112. "Бета-выпуск языка программирования Rust 1.0"  +1 +/–
Сообщение от Crazy Alex (ok), 06-Апр-15, 12:31 
Вполне возможно. Я, в общем-то, говорил о том, откуда пошли традиции писать на джаве, а потом на плюсах громоздкий код. Если появилось что-то вменяемое - прекрасно, теперь бы оно стало ещё мейнстримом... Хотя как по мне - джава всё равно крайне некомфортный язык. Те же get/put в коллекциях, к примеру.
Ответить | Правка | Наверх | Cообщить модератору

115. "Бета-выпуск языка программирования Rust 1.0"  +1 +/–
Сообщение от csdoc (ok), 06-Апр-15, 16:47 
> Вполне возможно. Я, в общем-то, говорил о том, откуда пошли традиции писать
> на джаве, а потом на плюсах громоздкий код. Если появилось что-то
> вменяемое - прекрасно, теперь бы оно стало ещё мейнстримом...

Spring Framework уже давно популярнее Java EE во многих областях,
Spring Boot они активно пиарят и продвигают на своем сайте и конференциях.

> Хотя как по мне - джава всё равно крайне некомфортный язык.
> Те же get/put в коллекциях, к примеру.

С другой стороны - будет ли комфортно писать и читать программу,
в которой используется много различных библиотек и каждая из этих
библиотек по своему перегружает арифметические операторы ?

Ответить | Правка | Наверх | Cообщить модератору

132. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Crazy Alex (ok), 07-Апр-15, 00:56 
Ок, спринг стал мейнстримом. Учту. Если ещё Hybernate заменяется чем-то менее монструозным - вообще сочту, что чудо случилось. Но накопленные традиции и привычки всё делать, как будто пишешь пакет на сто миллионов строк - укоренились крепко, это и по вашим ответам видно.

По перегрузке - так не берите неудобные библиотеки. Собственно, по причине неудобства те, кто персетарался с перегрузкой, уже повымирали (лет пятнадцать назад). Арифметику сейчас никто не перегружает без нужды. А вот не дать возможности сделать нормальное индексирование или сравнение - это скотство, по-моему. Я вообще в этом плане предпочитаю подход D - пользовательский тип должен иметь возможность сделать абсолютно всё,  что делает встроенный в язык. Это, во-первых, сильно упрощает обобщённое программирование, а во-вторых позволяет легко заменить в любой момент в приложении встроенный тип на что-то более подходящее для данного случая. А вот как будут выглядеть на джаве вычисления в 256-битовых целых, буде понадобится - мне и представлять не хочется.

Ответить | Правка | Наверх | Cообщить модератору

135. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от csdoc (ok), 07-Апр-15, 02:26 
> Ок, спринг стал мейнстримом. Учту.

По крайней мере, в рунете на Java-конференциях про спринг говорят очень много,
а про Java EE - практически ничего. В других частях света может быть ситуация иная.

> Если ещё Hybernate заменяется чем-то менее монструозным
> - вообще сочту, что чудо случилось.

Есть несколько реализаций интерфейса Java Persistence API,
Hibernate - это только одна из таких реализаций.

Кстати, в презентации https://www.youtube.com/watch?v=YzOTZTt-PR0
рассказывается для каких проектов от Hibernate / JPA будет
больше вреда, чем пользы, начиная с #t=48m15s

Если не ограничивать себя рамками Hibernate
- есть много других способов работы с базой данных,
например, спринговый JdbcTemplate или http://jdbi.org/ или вообще,
голый JDBC, если надо выжать из базы данных максимум производительности:
http://samolisov.blogspot.com/2014/01/dao-jdbc-spring-framew...

> По перегрузке - так не берите неудобные библиотеки.

Иногда библиотеки пишутся своими силами. И если язык не будет ничем
и никак ограничивать полет творческой мысли - там могут написать такого...

Вот например, Perl - очень удобный язык, 5-й версии и особенно 6-й,
ничем и никак программиста не ограничивает. Писать на таком языке очень удобно.
А читать потом написанный код на перле? А ведь там полная свобода самовыражения.

> Арифметику сейчас никто не перегружает без нужды. А вот не дать возможности
> сделать нормальное индексирование или сравнение - это скотство, по-моему.

Это минимализм. Такой же подход, который был применен и при создании UNIX.
Реализовывать только то что необходимо без лишнего синтаксического сахара.

Интерфейс
https://docs.oracle.com/javase/7/docs/api/java/util/Collecti...
или
https://docs.oracle.com/javase/7/docs/api/java/util/Map.html
не выглядит сложным или неудобным.

И если используем метод из интерфейса - можно быть уверенным,
что он делает именно то, что написано в описании интерфейса.

> А вот как будут выглядеть на джаве вычисления
> в 256-битовых целых, буде понадобится - мне и представлять не хочется.

Строить программу и модель прикладной области на таких понятиях,
как "256-битовые целые" - это изначальная ошибка в архитектуре программы.

ООП подразумевает, что будут использоваться более высокоуровневые понятия,
а детали реализации будут скрыты внутри класса и интересны только его разработчикам.

Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

146. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от iZEN (ok), 08-Апр-15, 21:45 
>> Ок, спринг стал мейнстримом. Учту.
> По крайней мере, в рунете на Java-конференциях про спринг говорят очень много,
> а про Java EE - практически ничего. В других частях света может быть ситуация иная.

То же самое: про GNU/Linux (Git) "вони" больше, чем по Windows (Mercurial), хотя, казалось бы, должно быть наоборот. Почему? Всё дело в (НЕ)ОЧЕВИДНОСТИ тех или иных ситуаций с точки зрения практического применения.

Java EE — это стандарт и масса реализаций ("хуже-лучше", "быстрее-медленнее"). Spring — это частичная неполная реализация элементов Java EE и собственные суб-фреймворки, заменяющие стандартные реализации там, где это видится разработчиками более подходящим и востребованным.


Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

150. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от csdoc (ok), 08-Апр-15, 22:29 
>>> Ок, спринг стал мейнстримом. Учту.
>> По крайней мере, в рунете на Java-конференциях про спринг говорят очень много,
>> а про Java EE - практически ничего. В других частях света может быть ситуация иная.
> То же самое: про GNU/Linux (Git) "вони" больше, чем по Windows (Mercurial),
> хотя, казалось бы, должно быть наоборот. Почему? Всё дело в (НЕ)ОЧЕВИДНОСТИ
> тех или иных ситуаций с точки зрения практического применения.

Git - более популярная система, чем Mercurial, поэтому про него говорят больше.
Аналогично и Linux / Windows.

Если через http://www.google.com/ncr погуглить "Linux"
и "Windows", то будут такие результаты:

Результатов: примерно   455 000 000 - Linux
Результатов: примерно 2 280 000 000 - Windows

Аналогичные результаты получаются и по Git / Mercurial:

Результатов: примерно 220 000 000 - Git
Результатов: примерно  27 000 000 - Mercurial

> Java EE — это стандарт и масса реализаций

"масса" - это две, если брать Java EE 7 Web Profile Compatible Implementations

и аж четыре разных для Java EE 7 Full Platform Compatible Implementations,
две из которых малоизвестны, то есть по факту получается только так же - две.

то есть на деле эта "масса реализаций" выливается только в то,
что силы тратятся впустую на создание конкурирующих решений.

Чем-то это напоминает ситуацию с операционными системами,
Linux - всего одна система, которая развивается очень быстро,
BSD - раздробилась на много мелких систем, которые конкурируют между собой.

> Spring — это частичная неполная реализация элементов Java EE
> и собственные суб-фреймворки, заменяющие стандартные реализации там,
> где это видится разработчиками более подходящим и востребованным.

То же самое можно сказать и про Linux, сравнивая его с UNIX Compatible Implementations.

Которых тоже было масса реализаций ("хуже-лучше", "быстрее-медленнее").

Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

153. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от iZEN (ok), 09-Апр-15, 00:28 
>[оверквотинг удален]
>>> а про Java EE - практически ничего. В других частях света может быть ситуация иная.
>> То же самое: про GNU/Linux (Git) "вони" больше, чем по Windows (Mercurial),
>> хотя, казалось бы, должно быть наоборот. Почему? Всё дело в (НЕ)ОЧЕВИДНОСТИ
>> тех или иных ситуаций с точки зрения практического применения.
> Git - более популярная система, чем Mercurial, поэтому про него говорят больше.
> Аналогично и Linux / Windows.
> Если через http://www.google.com/ncr погуглить "Linux"
> и "Windows", то будут такие результаты:
> Результатов: примерно   455 000 000 - Linux
> Результатов: примерно 2 280 000 000 - Windows

Разница — 5 раз.

> Аналогичные результаты получаются и по Git / Mercurial:
> Результатов: примерно 220 000 000 - Git
> Результатов: примерно  27 000 000 - Mercurial

Разница — 8 раз.

>> Java EE — это стандарт и масса реализаций
> "масса" - это две, если брать Java EE 7 Web Profile Compatible
> Implementations
> и аж четыре разных для Java EE 7 Full Platform Compatible Implementations,
> две из которых малоизвестны, то есть по факту получается только так же
> - две.
> то есть на деле эта "масса реализаций" выливается только в то,
> что силы тратятся впустую на создание конкурирующих решений.

На деле создаются два решения на одной общей спецификации: эталонное (и медленное) открытое и быстроее (масштабируемое) закрытое, соответствующее эталонной реализации.

> Чем-то это напоминает ситуацию с операционными системами,
> Linux - всего одна система, которая развивается очень быстро,
> BSD - раздробилась на много мелких систем, которые конкурируют между собой.

Мне не напоминает, потому что FreeBSD, например, вырождается в GNU/FreeBSD. А Linux без системы приложений GNU — только ядро и чего-то там "конкурировать" с целостной системой не способно в принципе.

> То же самое можно сказать и про Linux, сравнивая его с UNIX
> Compatible Implementations.
> Которых тоже было масса реализаций ("хуже-лучше", "быстрее-медленнее").

Как правило, в последние годы "мы это уже проходили" и "зачем множить сущности".

Ответить | Правка | К родителю #150 | Наверх | Cообщить модератору

155. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от csdoc (ok), 09-Апр-15, 03:02 
>>> Java EE — это стандарт и масса реализаций
>> то есть на деле эта "масса реализаций" выливается только в то,
>> что силы тратятся впустую на создание конкурирующих решений.
> На деле создаются два решения на одной общей спецификации: эталонное (и медленное)
> открытое и быстроее (масштабируемое) закрытое, соответствующее эталонной реализации.

То есть, основная цель создания Java EE была одна - зарабатывать деньги.
Демо-версия - берите бесплатно, а полноценная версия - уже надо платить.

Spring - это open source, имеет всего одну версию для платных и бесплатных
пользователей, а деньги зарабатывает не продажей лицензий (как майкрософт)
а продажей поддержки (как Red Hat) - это более честный и справедливый вариант.

>> Чем-то это напоминает ситуацию с операционными системами,
>> Linux - всего одна система, которая развивается очень быстро,
>> BSD - раздробилась на много мелких систем, которые конкурируют между собой.
> Мне не напоминает, потому что FreeBSD, например, вырождается в GNU/FreeBSD.

Да ладно, они наоборот, вытесняют из своей системы все что было под лицензией GPL
и замещают proprietary-friendly лицензиями, например, вот - gcc меняют на clang.

> А Linux без системы приложений GNU — только ядро

когда говорится Linux при сравнении с FreeBSD - подразумевается GNU/Linux.
и даже более точно говоря, - GNU/Linux CentOS 7.1 или GNU/Linux RHEL 7.1
- это есть очень даже целостная система от одного вендора, как и FreeBSD.

>> То же самое можно сказать и про Linux,
>> сравнивая его с UNIX Compatible Implementations.
>> Которых тоже было масса реализаций ("хуже-лучше", "быстрее-медленнее").
> Как правило, в последние годы "мы это уже проходили"
> и "зачем множить сущности".

Они всеравно множатся: https://en.wikipedia.org/wiki/List_of_BSD_operating_systems
И это только те, которые выложены в открытый доступ, а ведь есть еще десятки,
если не сотни проприетарных операционных систем созданных на базе BSD,
тут же и различные макоси и даже виндовс (TCP/IP стек первых версий).

А отличие - только лишь в лицензии. У Linux она оказалась более удачной.

Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

118. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от iZEN (ok), 06-Апр-15, 19:25 
> Java EE уже не нужен,

Смело. Вы Java EE 7 смотрели?
http://habrahabr.ru/company/piter/blog/229213/


> http://projects.spring.io/spring-framework/ подходит для проектов практически любой сложности,

А Spring какую спецификацию, по-вашему, реализует?!

Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

120. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от csdoc (ok), 06-Апр-15, 20:07 
>> Java EE уже не нужен,
> Смело.

Я пока что не нашел ни одной задачи, которую нельзя решить с помощью спринга.

Также не понимаю в чем и где Java EE лучше за Spring. Кроме того случая,
когда есть древний проект написанный на Java EE и его надо поддерживать.

> Вы Java EE 7 смотрели?
> http://habrahabr.ru/company/piter/blog/229213/

"научитесь обращаться с веб-службами SOAP" - без комментариев.

"исследуете и научитесь использовать API EJB и JPA — от компонентов-сущностей, компонентов-сеансов до компонентов, управляемых сообщениями, и многого другого"

- про EJB 2.1 много уже написано и сказано,
а про JPA - есть очень хорошая презентация
https://www.youtube.com/watch?v=YzOTZTt-PR0
Николай Алименков — Босиком по граблям Hibernate
- рекомендую.

>> http://projects.spring.io/spring-framework/
>> подходит для проектов практически любой сложности,
> А Spring какую спецификацию, по-вашему, реализует?!

Ставить знак равенства между спрингом и Java EE - это слишком.

чтобы долго не рассказывать:
http://www.slideshare.net/reza_rahman/java-ee-and-spring-sid...
3 и 4 слайды.

Ответить | Правка | Наверх | Cообщить модератору

125. "Бета-выпуск языка программирования Rust 1.0"  –3 +/–
Сообщение от iZEN (ok), 06-Апр-15, 21:55 
>>> Java EE уже не нужен,
>> Смело.
> Я пока что не нашел ни одной задачи, которую нельзя решить с
> помощью спринга.
> Также не понимаю в чем и где Java EE лучше за Spring.

В унификации и стандартизации.

> Кроме того случая, когда есть древний проект написанный на Java EE и его надо поддерживать.

Java EE 7 это далеко не J2EE.

>> Вы Java EE 7 смотрели?
>> http://habrahabr.ru/company/piter/blog/229213/
> "научитесь обращаться с веб-службами SOAP" - без комментариев.

SOAP уже отменили?

> "исследуете и научитесь использовать API EJB и JPA — от компонентов-сущностей, компонентов-сеансов
> до компонентов, управляемых сообщениями, и многого другого"

Это учебник.

> - про EJB 2.1 много уже написано и сказано,

Сейчас актуальны EJB 3.2 как бы.

> а про JPA - есть очень хорошая презентация
> https://www.youtube.com/watch?v=YzOTZTt-PR0
> Николай Алименков — Босиком по граблям Hibernate
> - рекомендую.

В видео нет JPA, а рассказ ведётся на примере Hibernate. Hibernate == JPA 1.0 - 2006 год.
JPA 2.1 (2013 год) из Java EE 7 привносит доступ к хранимым процедурам. А новый Criteria API позволяет делать запросы не только на выборку, но и на пакетное обновление и удаление.
Наконец, описание схемы базы данных и единиц хранения в persistence.xml.

>>> http://projects.spring.io/spring-framework/
>>> подходит для проектов практически любой сложности,
>> А Spring какую спецификацию, по-вашему, реализует?!
> Ставить знак равенства между спрингом и Java EE - это слишком.

Вот и я говорю: Spring лишь частично реализует спецификацию Java EE, остальное делает по-своему, нестандартным образом. И чем дальше, тем быстрее отстаёт от мейнстрима.

Ответить | Правка | Наверх | Cообщить модератору

128. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от csdoc (ok), 06-Апр-15, 22:34 
>> Также не понимаю в чем и где Java EE лучше за Spring.
> В унификации и стандартизации.

Каким образом это поможет в решении практических задач,
если в спинге можно сделать все то же самое что и в Java EE

Притом, более удобным и быстрым способом и без необходимости
покупать коммерческую реализацию Java EE от какого-либо вендора?

Маркетологи могут разумеется рассказать о преимуществах унификации
и стандартизации, а какая от этих высоких материй практическая польза?

> Java EE 7 это далеко не J2EE.

Даже Java EE 8 отстает от спринга.

>>> Вы Java EE 7 смотрели?
>>> http://habrahabr.ru/company/piter/blog/229213/
>> "научитесь обращаться с веб-службами SOAP" - без комментариев.
> SOAP уже отменили?

SOAP и WS-* используется только в legacy software.
Оно морально устаревшее, очень кривое и жутко монстрообразное:
https://en.wikipedia.org/wiki/List_of_web_service_specificat...

>> про EJB 2.1 много уже написано и сказано,
> Сейчас актуальны EJB 3.2 как бы.

Если вспомнить историю, то спринг появился в ответ на то, что кривым
и глючным Java EE было невозможно нормально пользоваться, потому что
получилось так, что "астронавты архитектуры" там такого понапридумывали,
что "мыши плакали, кололись, но продолжали жрать кактус". Хотя такой вариант
развития устроил не всех и тогда появился спринг.

EJB 3.x - это попытка исправить свои ошибки EJB 2.1
с оглядкой на то, что у спринга все получилось намного лучше.

>> а про JPA - есть очень хорошая презентация
>> https://www.youtube.com/watch?v=YzOTZTt-PR0
>> Николай Алименков — Босиком по граблям Hibernate
>> - рекомендую.
> В видео нет JPA, а рассказ ведётся на примере Hibernate.
> Hibernate == JPA 1.0 - 2006 год.

Зачем вы говорите неправду?

Hibernate ORM 4.3.0 Final == Java Persistence API 2.1

Причем, Hibernate - это такая же реакция на кривой Java EE как и спринг:

Hibernate was started in 2001 by Gavin King with colleagues from Cirrus Technologies as an alternative to using EJB2-style entity beans. Its original goal was to offer better persistence capabilities than offered by EJB2 by simplifying the complexities and supplementing missing features.

Когда астронавты архитектуры поняли что у Hibernate получилось лучше, чем в Java EE,
они начали эту самую Hibernate и стандартизировать в виде JPA.

> JPA 2.1 (2013 год) из Java EE 7 привносит доступ к хранимым
> процедурам. А новый Criteria API позволяет делать запросы не только на
> выборку, но и на пакетное обновление и удаление.
> Наконец, описание схемы базы данных и единиц хранения в persistence.xml.

Ну и чем это отличается от Hibernate? который JPA 2.1 поддерживает полностью.

https://www.youtube.com/watch?v=YzOTZTt-PR0
Николай Алименков — Босиком по граблям Hibernate

- хоть и написано "Hibernate", но разве в "JPA 2.1" не все то же самое?

>>> А Spring какую спецификацию, по-вашему, реализует?!
>> Ставить знак равенства между спрингом и Java EE - это слишком.
> Вот и я говорю: Spring лишь частично реализует спецификацию Java EE,
> остальное делает по-своему, нестандартным образом.

Спринг многое, практически все релизует способом лучшим, чем Java EE.
После того как пройдет несколько итераций в попытке догнать спринг -
более-менее нормальные и ставшие стабильными варианты спецификаций
начинают дополнительно поддерживаться и в спринге.

Менять в спинге то, что изначально было лучше на более кривой вариант смысла нет.

> И чем дальше, тем быстрее отстаёт от мейнстрима.

???

Все время было и есть наоборот, Java EE пыталось догнать спринг.
Вот и Java EE 8 не стало исключением - там еще только собираются
делать SR 371 - Model-View-Controller 1.0 и JSR 375 - Java EE Security API 1.0
а в спринге это уже давно реализовано: Spring MVC и Spring Security.

Spring - это гораздо больше, чем Java EE: https://spring.io/projects
и в то же время, проще и удобнее в использовании.

Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

145. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от iZEN (ok), 08-Апр-15, 20:41 
>>> Также не понимаю в чем и где Java EE лучше за Spring.
>> В унификации и стандартизации.
> Каким образом это поможет в решении практических задач,
> если в спинге можно сделать все то же самое что и в
> Java EE

Есть стандарт — есть заменяемые разработчики. Нет стандарта — есть зависимость решения от конкретного разработчика. Spring нестандартен, а значит всё с ним связанное будет на совести конкретного нанятого разработчика. Он уйдёт, компания вынуждена будет всё переписывать или нанимать такого же "гуру".

> Притом, более удобным и быстрым способом и без необходимости
> покупать коммерческую реализацию Java EE от какого-либо вендора?

Существуют бесплатные сертифицированные на полную совместимость с Java EE 7 решений. Это Oracle Glassfish (эталонная реализация) и Red Hat WildFly (бывший JBoss). Кроме этого, коммерческие решения в чём-то могут превосходить бесплатные, например, в высокой масштабируемости и нагрузочной способности, что на деле окажется выгоднее бесплатных решений.

> Маркетологи могут разумеется рассказать о преимуществах унификации
> и стандартизации, а какая от этих высоких материй практическая польза?
> Даже Java EE 8 отстает от спринга.

В чём конкретно?

>>>> Вы Java EE 7 смотрели?
>>>> http://habrahabr.ru/company/piter/blog/229213/
>>> "научитесь обращаться с веб-службами SOAP" - без комментариев.
>> SOAP уже отменили?
> SOAP и WS-* используется только в legacy software.
> Оно морально устаревшее, очень кривое и жутко монстрообразное:
> https://en.wikipedia.org/wiki/List_of_web_service_specificat...

Частное мнение и только. Знаю, в моде сейчас JAX-RS.

>>> про EJB 2.1 много уже написано и сказано,
>> Сейчас актуальны EJB 3.2 как бы.
> Если вспомнить историю, то спринг появился в ответ на то, что кривым
> и глючным Java EE было невозможно нормально пользоваться, потому что
> получилось так, что "астронавты архитектуры" там такого понапридумывали,
> что "мыши плакали, кололись, но продолжали жрать кактус". Хотя такой вариант
> развития устроил не всех и тогда появился спринг.

Spring появился как ответ на монструозный J2EE на Java 2.0 v.1.4.x. Всё. К выходу Java EE 6 его задача была исчерпана.

> EJB 3.x - это попытка исправить свои ошибки EJB 2.1
> с оглядкой на то, что у спринга все получилось намного лучше.

Так в чём лучше-то?!

>>> а про JPA - есть очень хорошая презентация
>>> https://www.youtube.com/watch?v=YzOTZTt-PR0
>>> Николай Алименков — Босиком по граблям Hibernate
>>> - рекомендую.
>> В видео нет JPA, а рассказ ведётся на примере Hibernate.
>> Hibernate == JPA 1.0 - 2006 год.
> Зачем вы говорите неправду?
> Hibernate ORM 4.3.0 Final == Java Persistence API 2.1

Затем, что Sun Microsystems выбрала EclipseLink в качестве эталонной реализации JPA 2.0 в Java EE 6, а не Hibernate - http://www.eclipse.org/org/press-release/20080317_Eclipselin...
2008 год!

> Причем, Hibernate - это такая же реакция на кривой Java EE как
> и спринг:

Согласен. Но нужно кому-то быть первым, а не лучшим.

>> JPA 2.1 (2013 год) из Java EE 7 привносит доступ к хранимым
>> процедурам. А новый Criteria API позволяет делать запросы не только на
>> выборку, но и на пакетное обновление и удаление.
>> Наконец, описание схемы базы данных и единиц хранения в persistence.xml.
> Ну и чем это отличается от Hibernate? который JPA 2.1 поддерживает полностью.

Тем, что в стандартной Java EE более быстрая и эффективная реализация от TopLink/Eclipse.

>> И чем дальше, тем быстрее отстаёт от мейнстрима.
> ???
> Все время было и есть наоборот, Java EE пыталось догнать спринг.
> Вот и Java EE 8 не стало исключением - там еще только
> собираются
> делать SR 371 - Model-View-Controller 1.0 и JSR 375 - Java EE
> Security API 1.0
> а в спринге это уже давно реализовано: Spring MVC и Spring Security.

Так попытайтесь соответствать со своим Spring спецификации JSR.

> Spring - это гораздо больше, чем Java EE: https://spring.io/projects
> и в то же время, проще и удобнее в использовании.

Так пользуйтесь на здоровье. Делайте vendor lock-in на себя и живите незаменимым.

Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

149. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от csdoc (ok), 08-Апр-15, 22:15 
> Есть стандарт — есть заменяемые разработчики. Нет стандарта — есть зависимость
> решения от конкретного разработчика. Spring нестандартен, а значит всё с ним
> связанное будет на совести конкретного нанятого разработчика. Он уйдёт, компания вынуждена
> будет всё переписывать или нанимать такого же "гуру".

Спринг сейчас более популярен, чем Java EE, и разработчиков,
которые знают/умеют спринг больше, чем разработчиков которые знают Java EE.
Хотя у Java EE есть один плюс - это независимость от конкретной реализации.

> Существуют бесплатные сертифицированные на полную совместимость с Java EE 7 решений.
> Это Oracle Glassfish (эталонная реализация) и Red Hat WildFly (бывший JBoss).

Как может быть Red Hat WildFly сертифицирован на полную совместимость с Java EE 7,
если он использует внутри себя редхатовскую же Hibernate, которая по вашим словам JPA 1.0 - 2006 год?

> Кроме этого, коммерческие решения в чём-то могут превосходить бесплатные, например, в высокой
> масштабируемости и нагрузочной способности, что на деле окажется выгоднее бесплатных решений.

Обычно для высокого масштабирования и нагрузочной способности надо подальше держаться
от готовых "коробочных" решений. Как пример - Netflix или Одноклассники.ру - ни там ни там
не используется коммерческая реализация Java EE и вообще какая-либо Java EE, насколько я знаю.

>> Маркетологи могут разумеется рассказать о преимуществах унификации
>> и стандартизации, а какая от этих высоких материй практическая польза?
>> Даже Java EE 8 отстает от спринга.
> В чём конкретно?

Я уже отвечал на этот вопрос, презентация
http://www.slideshare.net/reza_rahman/java-ee-and-spring-sid...
слайды на страницах 3 и 4.

Например, Spring MVC - очень удобная штука, в Java EE такого нет.
REST Template, Spring Security, Spring Testing - в Java EE такого тоже нет.

С тестированием EJB и прочего Java EE возникают очень большие проблемы,
а в спринге это все делается элементарно, потому что компоненты - это обычные POJO,
так что не особо напрягаясь можно на 100% покрыть юнит-тестами даже очень сложный код.

>>> SOAP уже отменили?
>> SOAP и WS-* используется только в legacy software.
>> Оно морально устаревшее, очень кривое и жутко монстрообразное:
>> https://en.wikipedia.org/wiki/List_of_web_service_specificat...
> Частное мнение и только. Знаю, в моде сейчас JAX-RS.

Да, через несколько лет в Java EE наверное появится что-то похожее на Spring MVC.

> Spring появился как ответ на монструозный J2EE на Java 2.0 v.1.4.x. Всё.
> К выходу Java EE 6 его задача была исчерпана.

Java EE содержит менее 50% тех возможностей, что есть сейчас в спринге: https://spring.io/projects

>> EJB 3.x - это попытка исправить свои ошибки EJB 2.1
>> с оглядкой на то, что у спринга все получилось намного лучше.
> Так в чём лучше-то?!

В том что не нужны монстрообразные сервера приложений,
и для нормальной работы достаточно Java SE + Spring.

Spring Boot - это вообще крутая штука, на выходе получается один jar-файл,
который можно просто взять и запустить, без каких-либо дополнительных танцев с бубном.

Для популярных и модных ныне микросервисов - это самое то, что надо.
Тем более, что спринговцы пошли еще дальше и уже делают http://projects.spring.io/spring-cloud/

>> Spring - это гораздо больше, чем Java EE: https://spring.io/projects
>> и в то же время, проще и удобнее в использовании.
> Так пользуйтесь на здоровье. Делайте vendor lock-in на себя и живите незаменимым.

При чем тут "vendor lock-in на себя" - программистов, которые знают спринг очень много.
И подозреваю, что в рунете - это более популярная платформа чем Java EE - по крайней мере,
именно такой вывод можно сделать по основным Java-конференциям, там говорят в основном про спринг.

Насколько я понимаю, Java EE - это более медленно развивающаяся платформа,
единственным плюсом которой является наличие нескольких реализаций от разных вендоров.
Кому-то это может быть важно, чтобы иметь возможность легко менять вендора для Java EE.

Спринг - более быстро развивающаяся платформа с большими возможностями,
у которой есть единственный минус - "vendor lock-in" на единственную реализацию.
В остальном эти две платформы или полностью идентичны или сравнимы по возможностям.

Так?

Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

152. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от iZEN (ok), 08-Апр-15, 23:57 
> Спринг сейчас более популярен, чем Java EE, и разработчиков,
> которые знают/умеют спринг больше, чем разработчиков которые знают Java EE.
> Хотя у Java EE есть один плюс - это независимость от конкретной
> реализации.
>> Существуют бесплатные сертифицированные на полную совместимость с Java EE 7 решений.
>> Это Oracle Glassfish (эталонная реализация) и Red Hat WildFly (бывший JBoss).
> Как может быть Red Hat WildFly сертифицирован на полную совместимость с Java
> EE 7,
> если он использует внутри себя редхатовскую же Hibernate, которая по вашим словам
> JPA 1.0 - 2006 год?

Так ведь в 2014-2015 году версия Hibernate в WildFly подросла и позволила пройти сертификацию на соответствие JPA 2.1 в Java EE 7.
Spring-фан, очевидно, не принял во внимание прогресс разработки альтернативной реализации. Он же весь в себе, для него время застыло на JavaEE5/6.

>> Кроме этого, коммерческие решения в чём-то могут превосходить бесплатные, например, в высокой
>> масштабируемости и нагрузочной способности, что на деле окажется выгоднее бесплатных решений.
> Обычно для высокого масштабирования и нагрузочной способности надо подальше держаться
> от готовых "коробочных" решений. Как пример - Netflix или Одноклассники.ру - ни
> там ни там
> не используется коммерческая реализация Java EE и вообще какая-либо Java EE, насколько
> я знаю.

Значит IBM и Oracle зря берут деньги у телекомов — давно пора прикрывать лавочки и заниматься, например, рыбалкой или сёрфингом.

>>> Маркетологи могут разумеется рассказать о преимуществах унификации
>>> и стандартизации, а какая от этих высоких материй практическая польза?
>>> Даже Java EE 8 отстает от спринга.
>> В чём конкретно?
> Я уже отвечал на этот вопрос, презентация
> http://www.slideshare.net/reza_rahman/java-ee-and-spring-sid...
> слайды на страницах 3 и 4.

Не понял, честно.

> Например, Spring MVC - очень удобная штука, в Java EE такого нет.

А JSF на что?

Spring MVC: https://netbeans.org/kb/docs/web/quickstart-webapps-spring_r...
JSF: https://netbeans.org/kb/docs/web/jsf20-intro_ru.html

> REST Template, Spring Security, Spring Testing - в Java EE такого тоже нет.

Потому что в Java EE 7 есть другое, более стандартизованное. К примеру, полная интеграция CDI в JSF 2.2 сделал часть пакетов последнего устаревшими, видоизменив обработку запросов. Но Spring-бои об этом не догадываются.

> Spring Security

///---
Вы можете использовать программную авторизацию, чтобы выборочно разрешать или блокировать доступ к роли или принципалу. Это становится возможно потому, что у вас есть прямой доступ к интерфейсу JAAS java.security.Principal , а также к контексту EJB, что позволяет проверить роль принципала в коде.
---///

> С тестированием EJB и прочего Java EE возникают очень большие проблемы,

В какой версии?

> а в спринге это все делается элементарно, потому что компоненты - это обычные POJO,
> так что не особо напрягаясь можно на 100% покрыть юнит-тестами даже очень сложный код.

Дааа? Можно подумать, что POJO — это исключительная фича Spring'а. :))

> Да, через несколько лет в Java EE наверное появится что-то похожее на Spring MVC.

Оно уже там под другим названием — JSF. Полезно хотя бы иногда интересоваться "параллельными" технологиями.

>> Spring появился как ответ на монструозный J2EE на Java 2.0 v.1.4.x. Всё.
>> К выходу Java EE 6 его задача была исчерпана.
> Java EE содержит менее 50% тех возможностей, что есть сейчас в спринге:
> https://spring.io/projects

Верю. Честно-честно. Ведь Spring используют все, а Java EE — единицы (маргиналы). :))

>>> EJB 3.x - это попытка исправить свои ошибки EJB 2.1
>>> с оглядкой на то, что у спринга все получилось намного лучше.
>> Так в чём лучше-то?!
> В том что не нужны монстрообразные сервера приложений,
> и для нормальной работы достаточно Java SE + Spring.

Что насчёт масштабируемости, множества виртуальных серверов и отказоустойчивости?

> Spring Boot - это вообще крутая штука, на выходе получается один jar-файл,
> который можно просто взять и запустить, без каких-либо дополнительных танцев с бубном.

Я тоже могу на Tomcat собрать Java EE 7 приложение с сервером. И просто запустить из командной строки. Но от этого оно не станет промышленного уровня.

> Для популярных и модных ныне микросервисов - это самое то, что надо.
> Тем более, что спринговцы пошли еще дальше и уже делают http://projects.spring.io/spring-cloud/

Oracle Cloud: https://cloud.oracle.com/home
Red Hat Cloud: https://www.openshift.com/products
IBM Cloud: http://www-01.ibm.com/software/websphere/products/applicatio...

>>> Spring - это гораздо больше, чем Java EE: https://spring.io/projects
>>> и в то же время, проще и удобнее в использовании.
>> Так пользуйтесь на здоровье. Делайте vendor lock-in на себя и живите незаменимым.
> При чем тут "vendor lock-in на себя" - программистов, которые знают спринг
> очень много.
> И подозреваю, что в рунете - это более популярная платформа чем Java
> EE - по крайней мере,
> именно такой вывод можно сделать по основным Java-конференциям, там говорят в основном
> про спринг.

Много говорят обычно о том, что "болит".

> Насколько я понимаю, Java EE - это более медленно развивающаяся платформа,
> единственным плюсом которой является наличие нескольких реализаций от разных вендоров.
> Кому-то это может быть важно, чтобы иметь возможность легко менять вендора для
> Java EE.
> Спринг - более быстро развивающаяся платформа с большими возможностями,
> у которой есть единственный минус - "vendor lock-in" на единственную реализацию.
> В остальном эти две платформы или полностью идентичны или сравнимы по возможностям.
> Так?

Несовсем.

Безусловно то, что Spring является одним из поставщиков идей и инициатором революции в Java EE. Но когда его молодой задор иссякнет, Java EE всё равно продолжит развитие, как ни крути.

Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

154. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от csdoc (ok), 09-Апр-15, 02:39 
> Значит IBM и Oracle зря берут деньги у телекомов — давно пора
> прикрывать лавочки и заниматься, например, рыбалкой или сёрфингом.

IBM и Oracle продают железо + софт в комплекте,
так что деньги они берут не зря, а за "решения"

>> Spring MVC - очень удобная штука, в Java EE такого нет.
> А JSF на что?

JSF has very nice way of rendering views и его можно использовать
вместе с Spring MVC вместо JSP или других технологий отрисовки view.

Но Spring MVC - это гораздо более простой и универсальный инструмент,
который может все то же что и JAX-RS и даже больше,
так что в спринге отдельный JAX-RS просто не нужен.

> JSF: https://netbeans.org/kb/docs/web/jsf20-intro_ru.html

Для сравнения, Spring MVC: https://spring.io/guides/gs/serving-web-content/

>> Spring Testing - в Java EE такого тоже нет.
>> С тестированием EJB и прочего Java EE возникают очень большие проблемы
> В какой версии?

В любой. Как можно протестировать EJB без сервера приложений?
http://habrahabr.ru/company/luxoft/blog/246465/#comment_8191813

В спринге - без проблем тестируется даже очень сложные веб-приложения
без сервера приложений, а лишь с помощью Spring MVC Test Framework.

Это преимущество спринга? Да еще какое. Например, у меня на не самом быстром компе
более сотни тестов пролетало всего за 7-8 секунд через Spring MVC Test Framework.

>> а в спринге это все делается элементарно, потому что компоненты - это обычные POJO,
>> так что не особо напрягаясь можно на 100% покрыть юнит-тестами даже очень сложный код.
> Дааа? Можно подумать, что POJO — это исключительная фича Spring'а. :))

В спринге нет EJB и проч. прелестей Java EE, так что да,
"все есть POJO" - это просто ГРОМАДНОЕ преимущество спринга.

>> Да, через несколько лет в Java EE наверное появится что-то похожее на Spring MVC.
> Оно уже там под другим названием — JSF. Полезно хотя бы иногда
> интересоваться "параллельными" технологиями.

Каким образом "оно уже там", если в Java EE 8
только собираются добавить JSR 371 - Model-View-Controller 1.0 ?

Причем, выглядит это как гибрид JAX-RS + 10% возможностей Spring MVC.
Как обычно версия 1.0 будет очень неудобной для использования, а до версии
3.2 может быть и дорастет до юзабельного состояния, сравнимого со Spring MVC.

>> Java EE содержит менее 50% тех возможностей, что есть сейчас в спринге
> Верю. Честно-честно. Ведь Spring используют все, а Java EE — единицы (маргиналы).

Спринг массово используется, а Java EE... вот что пишут:
http://java.dzone.com/articles/why-java-ee-lost-and-spring
Why Java EE Lost and Spring Won

>>> Так в чём лучше-то?!
>> В том что не нужны монстрообразные сервера приложений,
>> и для нормальной работы достаточно Java SE + Spring.
> Что насчёт масштабируемости, множества виртуальных серверов и отказоустойчивости?

С этим тоже все нормально, кластер из двух nginx в качестве роутера,
или аппаратный балансировщик + сколько надо backend`ов с приложением.

>> Spring Boot - это вообще крутая штука, на выходе получается один jar-файл,
>> который можно просто взять и запустить, без каких-либо дополнительных танцев с бубном.
> Я тоже могу на Tomcat собрать Java EE 7 приложение с сервером.
> И просто запустить из командной строки. Но от этого оно не
> станет промышленного уровня.

"промышленного уровня" - в переводе на английский - "Enterprise".
Спринг уже давно Enterprise уровня и в чем-то даже лучше Java EE.

> Безусловно то, что Spring является одним из поставщиков идей
> и инициатором революции в Java EE. Но когда его молодой задор
> иссякнет, Java EE всё равно продолжит развитие, как ни крути.

Что-то за 12 лет совсем не наблюдается признаков иссякания спринга,
скорее уж наоборот в последнее время он демонстрирует взрывной рост.

Java EE - это хорошая штука, если приходится покупать сервера у IBM или Oracle,
или писать очень большие проекты, когда важно отсутствие привязки к одному вендору.

А для мелких и средних задач, особенно, когда важна скорость и удобство разработки
- похоже что спринг выигрывает у Java EE как более динамично развивающаяся платформа.

Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

156. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от iZEN (ok), 09-Апр-15, 11:30 
> В любой. Как можно протестировать EJB без сервера приложений?
> http://habrahabr.ru/company/luxoft/blog/246465/#comment_8191813

Оригинал статьи: http://www.oracle.com/technetwork/articles/java/integrationt...
"Published September 2011"

>[оверквотинг удален]
> без сервера приложений, а лишь с помощью Spring MVC Test Framework.
> Это преимущество спринга? Да еще какое. Например, у меня на не самом
> быстром компе
> более сотни тестов пролетало всего за 7-8 секунд через Spring MVC Test
> Framework.
>>> а в спринге это все делается элементарно, потому что компоненты - это обычные POJO,
>>> так что не особо напрягаясь можно на 100% покрыть юнит-тестами даже очень сложный код.
>> Дааа? Можно подумать, что POJO — это исключительная фича Spring'а. :))
> В спринге нет EJB и проч. прелестей Java EE, так что да,
> "все есть POJO" - это просто ГРОМАДНОЕ преимущество спринга.

Про @Test для EJB как раз написано в вышеуказанной книге. Не надо бояться изучить что-то новое.

>>> Да, через несколько лет в Java EE наверное появится что-то похожее на Spring MVC.
>> Оно уже там под другим названием — JSF. Полезно хотя бы иногда
>> интересоваться "параллельными" технологиями.
> Каким образом "оно уже там", если в Java EE 8
> только собираются добавить JSR 371 - Model-View-Controller 1.0 ?
> Причем, выглядит это как гибрид JAX-RS + 10% возможностей Spring MVC.
> Как обычно версия 1.0 будет очень неудобной для использования, а до версии
> 3.2 может быть и дорастет до юзабельного состояния, сравнимого со Spring MVC.

Вот когда выйдет, тогда решим, чем это отличается от Spring MVC. Может мода на антипаттерн проектирования Model-View-Controller, наконец-то, пройдёт.

>>> Java EE содержит менее 50% тех возможностей, что есть сейчас в спринге
>> Верю. Честно-честно. Ведь Spring используют все, а Java EE — единицы (маргиналы).
> Спринг массово используется, а Java EE... вот что пишут:
> http://java.dzone.com/articles/why-java-ee-lost-and-spring
> Why Java EE Lost and Spring Won

Дело привычки и только. То же самое, что сидеть на J2EE/JavaEE5 десять-пятнадцать лет, потом ныть, что поддержка ВНЕЗАПНО закончилась.

>>>> Так в чём лучше-то?!
>>> В том что не нужны монстрообразные сервера приложений,
>>> и для нормальной работы достаточно Java SE + Spring.
>> Что насчёт масштабируемости, множества виртуальных серверов и отказоустойчивости?
> С этим тоже все нормально, кластер из двух nginx в качестве роутера,
> или аппаратный балансировщик + сколько надо backend`ов с приложением.

То есть без сторонних решений не обойтись.

>>> Spring Boot - это вообще крутая штука, на выходе получается один jar-файл,
>>> который можно просто взять и запустить, без каких-либо дополнительных танцев с бубном.
>> Я тоже могу на Tomcat собрать Java EE 7 приложение с сервером.
>> И просто запустить из командной строки. Но от этого оно не
>> станет промышленного уровня.
> "промышленного уровня" - в переводе на английский - "Enterprise".
> Спринг уже давно Enterprise уровня и в чем-то даже лучше Java EE.

Так в какой промышленности он используется?

>> Безусловно то, что Spring является одним из поставщиков идей
>> и инициатором революции в Java EE. Но когда его молодой задор
>> иссякнет, Java EE всё равно продолжит развитие, как ни крути.
> Что-то за 12 лет совсем не наблюдается признаков иссякания спринга,
> скорее уж наоборот в последнее время он демонстрирует взрывной рост.
> Java EE - это хорошая штука, если приходится покупать сервера у IBM
> или Oracle, или писать очень большие проекты, когда важно отсутствие привязки к одному вендору.

Да и для "наколеночных" поделок Java EE масштабируется неплохо, так как технология модульная: хочешь, используешь только JPA с JSF (WAR), хочешь - EJB с JMS (EAR). Куча embedded-решений на сертифицированных серверах Java EE 7, не нуждающихся в поддержке сторонних костылей и фронт-эндов.

> А для мелких и средних задач, особенно, когда важна скорость и удобство
> разработки
> - похоже что спринг выигрывает у Java EE как более динамично развивающаяся
> платформа.

На JSP много чего можно писать. Это ж "PHP на Java", считай. Обезьянки радуются простоте. :))

Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

157. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от csdoc (ok), 09-Апр-15, 16:56 
>> В любой. Как можно протестировать EJB без сервера приложений?
>> http://habrahabr.ru/company/luxoft/blog/246465/#comment_8191813
> Про @Test для EJB как раз написано в вышеуказанной книге.
> Не надо бояться изучить что-то новое.

Про @Test написано и в статье на сайте
https://netbeans.org/kb/docs/javaee/javaee-entapp-junit.html
- но там всеравно запускается Embedded EJB Container, других вариантов нет.
вопрос был: как протестировать без сервера приложений? ответ: никак, это невозможно.

>> Каким образом "оно уже там", если в Java EE 8
>> только собираются добавить JSR 371 - Model-View-Controller 1.0 ?
>> Причем, выглядит это как гибрид JAX-RS + 10% возможностей Spring MVC.
>> Как обычно версия 1.0 будет очень неудобной для использования, а до версии
>> 3.2 может быть и дорастет до юзабельного состояния, сравнимого со Spring MVC.
> Вот когда выйдет, тогда решим, чем это отличается от Spring MVC.

JSR 371 - Model-View-Controller 1.0 можно прочитать не дожидаясь выхода Java EE 8.

> Может мода на антипаттерн проектирования Model-View-Controller, наконец-то, пройдёт.

??? :-() Почему Model-View-Controller - это антипаттерн?

>>> Что насчёт масштабируемости, множества виртуальных серверов и отказоустойчивости?
>> С этим тоже все нормально, кластер из двух nginx в качестве роутера,
>> или аппаратный балансировщик + сколько надо backend`ов с приложением.
> То есть без сторонних решений не обойтись.

Если не использовать nginx - такое "масштабируемое" решение
будет легко уязвимо к DDoS и DOS атакам Slowloris и т.п.

B потребует в несколько (десятков) раз больше аппаратных ресурсов
для выполнения той же работы что и в случае с использованием nginx.

Хотя, если "без сторонних решений" - это может быть удобно для того,
чтобы продавать компаниям более мощные сервера и более масштабируемые Java EE решения.

Но если смотреть с точки зрения клиента - ему более выгодно будет поставить
на frontend nginx или даже купить NGINX Plus и это обойдется в разы дешевле.

>>> Но от этого оно не станет промышленного уровня.
>> "промышленного уровня" - в переводе на английский - "Enterprise".
>> Спринг уже давно Enterprise уровня и в чем-то даже лучше Java EE.
> Так в какой промышленности он используется?

https://pivotal.io/customers

А где в промышленности используется Java EE ?

> На JSP много чего можно писать. Это ж "PHP на Java", считай.

Разработчик языка Java, Джеймс Гослинг, охарактеризовал технологию JSP, лежащую в основе JSF, как «проект-клон Microsoft ASP, который был создан, только чтобы продемонстрировать насколько сама подобная идея плоха; но модель почему-то отказалась умирать»
- https://www.youtube.com/watch?v=9ei-rbULWoA

Если посмотреть на https://spring.io/guides/gs/serving-web-content/
- в спринге не заставляют пользоваться именно JSP, для отрисовки View
можно применять Thymeleaf, JSF и практически любую другую технологию.

> Обезьянки радуются простоте. :))

Любой вменяемый человек радуется простоте. Чем проще софт - тем он надежнее.
Например, операционная система UNIX построена на тех же принципах -
минимализма и простоты интерфейсов.

Для сравнения, когда оракл выкатил обновление 4.1 для своего Java EE стека,
они в этом минорном релизе 4.x -> 4.y исправили более одной тысячи багов.
Страшно даже подумать, сколько там еще багов осталось и как оно вообще
может работать и выдавать какой-то осмысленный результат при этом.

Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

138. "Бета-выпуск языка программирования Rust 1.0"  +3 +/–
Сообщение от Аноним (-), 07-Апр-15, 12:11 
По поводу SOAP, не мог не написать. Например написали апи на нём, для передачи ограниченного набора данных между Ява приложениями - тут всё ок, но впоследствии если выясняется что теперь нужно взаимодействие с разными системами, на разных языках, да и само кол-во данных увеличилось, плюс учитывая сразу что SOAP имеет кучу разных версий, которые в разных языках, в разных библиотеках с багами, нюансами, плюс обязательный xml добавляет кучу дополнительного объёма при передаче данных... и т.п
Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

142. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Аноним (-), 08-Апр-15, 01:28 
soap это анахронизм который кое-где оставили в качестве легаси в яве, и никому кроме них и не сдавшийся в наше время.
Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

158. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от iZEN (ok), 10-Апр-15, 14:10 
> Я наблюдал как команда писала ядро проекта на С++ и код был
> очень ровным. Вот тогда меня и научили "вменяемому" программированию на С++
> и научили ненавидеть Java :)

Ненависть была связана с обоснованным отказом от использования Java в пользу C++ или же чисто эмоциональными претензиями/отсутствием навыков программирования на Java и необходимостью его изучать/?

Архитектура сервера онлайн-игры на примере Skyforge: http://habrahabr.ru/company/mailru/blog/220359/


Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

56. "Бета-выпуск языка программирования Rust 1.0"  +1 +/–
Сообщение от nc (ok), 04-Апр-15, 18:03 
C++ неидеален. К сожалению, D, Rust, Go и прочие - тоже. Но то, что новые языки появляются, в любом случае хорошо, есть возможность обкатать новые идеи.
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

78. "Бета-выпуск языка программирования Rust 1.0"  +2 +/–
Сообщение от Аноним (-), 05-Апр-15, 00:42 
Обкатать новые идеи и добавить их в очередной стандарт C++
Ответить | Правка | Наверх | Cообщить модератору

93. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от nc (ok), 05-Апр-15, 10:25 
Нет уж, в С++ лучше ничего не добавлять. А вот если взять лучшие идеи из C, C++, Objective C, D, Go, Rust, Swift, C#, Java, Scala, Nemerle, Nim, Haxe и создать язык, который превзойдет все остальные языки программирования - это да.
Ответить | Правка | Наверх | Cообщить модератору

99. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от systemdanonymousd (?), 05-Апр-15, 16:35 
> Нет уж, в С++ лучше ничего не добавлять. А вот если взять
> лучшие идеи из C, C++, Objective C, D, Go, Rust, Swift,
> C#, Java, Scala, Nemerle, Nim, Haxe и создать язык, который превзойдет
> все остальные языки программирования - это да.

И назвать ++C.

Ответить | Правка | Наверх | Cообщить модератору

136. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Асушник (?), 07-Апр-15, 10:26 
Ваше высказывание выглядит примерно так: мозилловцы "ниасилили" с/с++, а потому, чтобы менял им обкаканные штанишки, запилили Rust. Мда..
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

27. "Бета-выпуск языка программирования Rust 1.0"  +4 +/–
Сообщение от Аноним (-), 04-Апр-15, 15:22 
судя по мейллистам, главные дишники сейчас чешут головы и обсуждают, что они сделали не так по сравнению с Го
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

32. "Бета-выпуск языка программирования Rust 1.0"  +2 +/–
Сообщение от Аноним (-), 04-Апр-15, 15:46 
Забыли стать мегакорпорацией и пропиариться на весь мир?
Ответить | Правка | Наверх | Cообщить модератору

45. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от Аноним (-), 04-Апр-15, 17:12 
А че, D так хорош? Стоит изучать его и перейти с С++ на D ?
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

72. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от pda (?), 04-Апр-15, 23:01 
Ну, вон Facebook используют. Ну это они скорее всего с гуглем пискомерюются. Типа, у нас тоже есть свой язык. Но тем не менее... :)
Ответить | Правка | Наверх | Cообщить модератору

75. "Бета-выпуск языка программирования Rust 1.0"  +/–
Сообщение от na (??), 04-Апр-15, 23:53 
В Facebook использует D потому, что его там использует Андрей Александреску, который на данный момент один из главных разработчиков D 2.*
Ответить | Правка | Наверх | Cообщить модератору

82. "Бета-выпуск языка программирования Rust 1.0"  +2 +/–
Сообщение от Crazy Alex (ok), 05-Апр-15, 04:51 
Это ты Bearophil'а начитался, что ли? D с Go даже сравнивать толком не получается - языки - результат принципиально разынх подходов. D целенаправленно делался так, чтобы сохранить и приумножить всю мощь плюсов, избавившись от их недостатков. Go - чтобы получить что-то минимальное, на чём можно писать компилируемый код.
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру