Вышла новая версия компилятора языка D — DMD 2.066

Ну так и есть. Все эти плюшки нужны новичкам. Опытные программеры уже научились обходить все грабли C++

so what?

Сделан большой прогресс в сторону реализации ручного управления памяти.

Неужели решили сделать таки язык, которым можно пользоваться?

Когда на вашем Rust напишут что-то навроде vibe.D, тогда и поговорим :-)

Ой, веб-штуки всякие, фэ. Ничего в этой области не понимаю, только знаю, что у ржавчины есть страничка по этому поводу - http://arewewebyet.com .

Ну и не думаю, что ржавчина, как язык, может помешать написать аналог этого «vibe.D», надо что бы просто это кому-то понадобилось.

Дык, если хочешь безопасного ручного управления памятью, то это точно к Rust.

Rust слишком непонятный программисту на С++\Java\Python\C#. На него массовой миграции не будет.

Я лично когда смотрю код на Rust очень редко понимаю, что этот код делает. С той же Java таких проблем нет. Хотя ее вообще не знаю.

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

Единственное, из того что мне в голову приходит, что может быть непонятно в коде на Rust - это явные области жизни (штуки типа 'a). Ну да, ради них стоит немного полистать введение в язык или http://doc.rust-lang.org/guide-lifetimes.html.

Раньше еще были ~ и @ указатели, но этот синтаксис убрали, он слишком многих пугал))

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

Может, ты какой-то сильно хитрый код смотришь?

https://github.com/iron/iron пойдет?

Dicebot, а старый вариант отключения сборщика мусора:
...

Да, GC.disable не изменился, но это совсем разные вещи. GC.disable не предотвращает выделение памяти, но отключает сборку мусора. Память при этом будет постепенно утекать, пока не будет вызван GC.enable

@nogc - полная противоположность. Этот атрибут никак не влияет на работу GC в приложении в целом, но гарантирует, что конкретная функция не выделяет память (как явно через new, так и «случайно» через closures / array appending)

Как результат - совсем разные области применения. GC.disable полезен, когда нужно предотвратить возможный stop-the-world сборки мусора на критическом участке кода. @nogc помогает быть уверенным, что не создаётся дополнительный мусор там, где его не должно быть. Так стандартная библиотека постепенно адаптируется к @nogc потому что выбор способа аллокации - решение пользователя, а не библиотеки. @nogc полезен в embedded/barebone коде, когда GC вообще удаляется из runtime и используется полность ручная обработка памяти.

Ну и не думаю, что ржавчина, как язык, может помешать написать аналог этого «vibe.D», надо что бы просто это кому-то понадобилось.

Проблема у Rust тут исключительно в высоком пороге вхождения на мой взгляд. vibe.d более естественный выбор после node.js из-за привычного синтаксиса и возможности на первых порах вообще не думать о владении памятью.

То есть на самом деле это не проблема - у языка совсем другая ниша (в которой он будет очень силён), но я не представляю себе популярный веб-фреймворк на Rust, не та целевая аудитория.

1 файлик парсит? ОК.

На данный момент известно о C-препроцессоре, лексическом анализаторе, обёртке для fuse и ODBC-драйвере для какой-то из их баз данных. https://www.youtube.com/watch?v=1JZNvKhA3mA упоминает об интеграции с C++ сервисами в backend, но такие детали редко публикуются.

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

Какое конкретно конкурентное преимущество ты получаешь? посоны то не знают, расскажи

Если судить по публично доступным финансовым данным, поддержание нашей серверной инфраструктуры обходится в разы дешевле, чем в среднем тратят конкуренты в этой же области (http://en.wikipedia.org/wiki/Real-time_bidding) - по крайней мере такие числа называл мой коллега Don Clugston во время выступления на DConf (http://youtu.be/WmE7ZR1_YKs?t=40m39s) и у меня нет оснований ему не верить :)

D - вполне хороший вариант в ситуациях, когда рынок слишком молодой и динамичный для C++ (быстро выпускать обновления критично для конкуренции), а JVM-based языки не подходят по производительности. Серверные фермы стоят отнюдь не дешево.

Главная проблема - найм новых сотрудником (мы безжалостно переобучаем выходцев из C++)

D - вполне хороший вариант в ситуациях, когда рынок слишком молодой и динамичный для C++ (быстро выпускать обновления критично для конкуренции), а JVM-based языки не подходят по производительности. Серверные фермы стоят отнюдь не дешево.

Чем это лучше Go? JVM тут посоны на форуме говорят рвет всех и вся, ну и питончик никто не отменял.

Чем это лучше Go?

Чем Go лучше D?

Чем это лучше Go?

Тем, что в больших проектах без шаблонов и метапрограммирования очень плохо :) В Go аналогичные конструкции или не существуют, или используют virtual dispatch (а у нас счёт на миллисекунды).

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

JVM тут посоны на форуме говорят рвет всех и вся

Пусть говорят :)

Новая языковая конструкция extern (C++

Новая такая новая...

1. Нет template engine навроде Jade
2. Не асинхронный
3. Нет поддержки UDP
4. Нет интегрированного load balancer
5. Отсутствие компактного API
6. Разве многопоточный ?

... Все эти плюшки нужны новичкам. ...

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

... Опытные программеры уже научились обходить все грабли C++.

Ммм, скорее, научились минимизировать количество наступаний на грабли - ошибки все равно у всех бывают. Ну и я не знаю, по каким критериям программиста можно внести в ранг «опытный» по твоей классификации).

Как пример - http://bitsquid.blogspot.ru - этого парня (парней? хз сколько их там) я явно считаю опытным разработчиком, но, судя по постам в блоге, С++ ему не слишком симпатизирует и нужен только ради простеньких шаблонов и RAII.

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

Ну дык да, научились. Проблема то в чем? Я думаю проблема во вхождении в проект новых людей, не привыкшим с данным конкретным набором граблей. Ты же наверное сам сто раз видел, что человек, который давно в проекте, его уже все устраивает)