Microsoft готовит свой ответ языкам D, Rust, Go.

NIH-синдром? Когда уже введут УК-ответственность за такое?

а ясно. Странно что ещё никто не написал какой-то менеджер, как gem для руби или pip для питона или npm для node.js, которые бы это всё качали.
Я не уверен, но вроде есть даже универсальные глубоко конфигурируемые качаторы кода с гитхаба, которые можно настроить для любого языка.

Скажем дружно...

если он разведет хоть одну функцию на прямое присваивание вместо порождение новых данных, хотябы какой-то галимый ++ - тут же код перестанет быть потокобезопасным. поэтому он делать этого никогда не будет. pure Haskell code is always threadsafe (с)

я не говорю о возможности мелких оптимизаций. я говорю про оверхед и калечность, неестественность такого подхода на современном железе.

если он разведет хоть одну функцию на прямое присваивание вместо порождение новых данных, хотябы какой-то галимый ++ - тут же код перестанет быть потокобезопасным

Что за глупости?

если

ну вот уже если ) А если нет, то.

А насчёт операция со списками, там специально же cons cellы и когда изменяется список, то не весь лист копируется, а только часть. Ну и т.д.

на современном железе

это мне кажется на любом железе не совсем естественно. Тем не менее всякие хаскелы с окамлами и скалами работают со скоростями большими чем императивный 'некалечный, естественный' питон, скажем.

pure Haskell code is always threadsafe

это не значит, что оно не соптимизирует, если ты не пользуешься тредами. А если пользуешься тредами — то тебе и на Сишке может понадобится копирование и 'порождение новых данных'.

В одном потоке: childrenKilled++; totalPeopleKilled++;, в другом потоке в случае с мутабельными объектами можем получить что число убитых детей будет новое, а число убитых людей в принципе будет старое.

Сделай над собой усилие и вырази свою мысль более формально.

Мутабельные объекты при их модификации (без костылей в виде блокировок) могут оказываться в неправильном состоянии для кода в другом потоке.

А, ну да. Есть такая категория людей, которые предпочитают забивать гвозди камнями. Только бы не использовать нормальный инструмент.

Мутабельные объекты при их модификации (без костылей в виде блокировок)

Мде. Я правильно понял, что имеются в виду только _общие_ для разных нитей данные? Не просто «какой-то голимый ++», а «изменение глобальных данных»?

Понятно, не знаешь ничего.

У меня да, у чувака который был ранее в нити — хз.

А как ещё назвать язык, в котором любое значение может измениться из-за любой функции, даже если она не держит на него указатель, даже опосредованно?

ну я думал я про это пытаюсь писать

изменение глобальных данных

++ не изменение?

что именно не знаю? дай самообразоваться ссылку.

ну я думал я про это пытаюсь писать

Мне трудно читать мысли на таком расстоянии.

++ не изменение?

К thread safety имеет отношение только изменение глобальных (т.е. видимых двум и более нитям) данных. Трижды насквозь императивная программа, состоящая из присваиваний и инкрементов, может быть гарантированно threadsafe.

http://www.youtube.com/watch?v=-6BsiVyC1kM

Вот тут на английском рассказывают почему модификация данных по указателю сосёт во многих случаях, несмотря на «логичность» для железа.

Трижды насквозь императивная программа, состоящая из присваиваний и инкрементов, может быть гарантированно threadsafe.

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

сосёт

по производительности? да ну? дай примера.

Трижды насквозь императивная программа, состоящая из присваиваний и инкрементов, может быть гарантированно threadsafe.

может, но не гарантирует

У кого-то здесь проблемы с русским языком.

по производительности? да ну? дай примера

Не. По удобству использования.

я говорю о том, что есть функция, которая гарантированно threadsafe. если я добавлю в нее ++, то никто не даст гарантии, что она threadsafe.

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

По удобству использования

по этому поводу базара нет.

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

• легкость разработки
• безопасность типов
• производительность исполнения
• современность и легкость распараллеливания

зачем второй C# ?

я говорю о том, что есть функция, которая гарантированно threadsafe. если я добавлю в нее ++, то никто не даст гарантии, что она threadsafe.

Если это ++ на локальной для нити переменной - даст.

Если это ++ на локальной для нити

об этом и речь

я так понял, оно будет компилируемое, а не vm'ное.

Совсем недавно было хотябы «какой-то галимый ++» и «не гарантирует». Остается понять, что «порождение новых данных» даже на концептуальном уровне не обязательно для thread safety.

я вообще не понимаю, что ты пытаешься сказать.

У них все языки - жалкие подделки оригинала: C# - подделка Java, F# - подделка Ocaml, и т.д.

Вот боолее приличная ссылка
http://joeduffyblog.com/2013/12/27/csharp-for-systems-programming/

My goal is to eventually open source this thing, but before we can do that we need to button up a few aspects of the language

У них все языки - жалкие подделки оригинала: C# - подделка Java

Агументируйте, пожалуйста.
Я пишу на Java большн 15 лет и считаю что как язык программирования, Java отстала от C# на много лет.
Это признаёт и Оракл, копируя фичи из C#

At a high level, I classify the language features into six primary categories:

1) Lifetime understanding. C++ has RAII, deterministic destruction, and efficient allocation of objects. C# and Java both coax developers into relying too heavily on the GC heap, and offers only “loose” support for deterministic destruction via IDisposable. Part of what my team does is regularly convert C# programs to this new language, and it’s not uncommon for us to encounter 30-50% time spent in GC. For servers, this kills throughput; for clients, it degrades the experience, by injecting latency into the interaction. We’ve stolen a page from C++ — in areas like rvalue references, move semantics, destruction, references / borrowing — and yet retained the necessary elements of safety, and merged them with ideas from functional languages. This allows us to aggressively stack allocate objects, deterministically destruct, and more.

2) Side-effects understanding. This is the evolution of what we published in OOPSLA 2012, giving you elements of C++ const (but again with safety), along with first class immutability and isolation.

3) Async programming at scale. The community has been ’round and ’round on this one, namely whether to use continuation-passing or lightweight blocking coroutines. This includes C# but also pretty much every other language on the planet. The key innovation here is a composable type-system that is agnostic to the execution model, and can map efficiently to either one. It would be arrogant to claim we’ve got the one right way to expose this stuff, but having experience with many other approaches, I love where we landed.

4) Type-safe systems programming. It’s commonly claimed that with type-safety comes an inherent loss of performance. It is true that bounds checking is non-negotiable, and that we prefer overflow checking by default. It’s surprising what a good optimizing compiler can do here, versus JIT compiling. (And one only needs to casually audit some recent security bulletins to see why these features have merit.) Other areas include allowing you to do more without allocating. Like having lambda-based APIs that can be called with zero allocations (rather than the usual two: one for the delegate, one for the display). And being able to easily carve out sub-arrays and sub-strings without allocating.

5) Modern error model. This is another one that the community disagrees about. We have picked what I believe to be the sweet spot: contracts everywhere (preconditions, postconditions, invariants, assertions, etc), fail-fast as the default policy, exceptions for the rare dynamic failure (parsing, I/O, etc), and typed exceptions only when you absolutely need rich exceptions. All integrated into the type system in a 1st class way, so that you get all the proper subtyping behavior necessary to make it safe and sound.

6) Modern frameworks. This is a catch-all bucket that covers things like async LINQ, improved enumerator support that competes with C++ iterators in performance and doesn’t demand double-interface dispatch to extract elements, etc. To be entirely honest, this is the area we have the biggest list of “designed but not yet implemented features”, spanning things like void-as-a-1st-class-type, non-null types, traits, 1st class effect typing, and more. I expect us to have a few of these in our mid-2014 checkpoint, but not all of them.

Assuming there’s interest, I am eager to hear what you think, get feedback on the overall idea (as well as the specifics), and also find out what aspects folks would like to hear more about. I am excited to share, however the reality is that I won’t have a ton of time to write in the months ahead; we still have an enormous amount of work to do (oh, we’re hiring ;-) ). But I’d sure love for y’all to help me prioritize what to share and in what order. Ultimately, I eagerly await the day when we can share real code. In the meantime, Happy Hacking!

С++ вообще не ООП

Именно.

NIH чистой воды. У M$ уже есть F#. Штука потенциально способная зарулить все что угодно, включая Хаскель.

Но... Только... У M$ столько всего что способно только потенциально: ядро с логичной и понятной архитектурой, CLR позволяющий не изобретать велосипеды в рантаймстроении, API на все случаи жизни. Только вот не выходит нифига.

Раньше M$ могда тупо купить, если не разработку, то по крайней мере команду, теперь же, во-первых, все уже давно раскуплены, а во-вторых, все отлично понимают что ожидает их детища в M$. Тут вам не гугель.

а говношелла с qbasic'ом им мало?

Т.е. их расхваливаемый C# не такой уж и легкий в разработке и безопасный?

я не знаю C#, но мне кажется, что у тебя взаимоисключающие параграфы. Не?

Microsoft готовит свой ответ языкам D, Rust, Go.

Как может зло, готовить ответ? Зло обычно инициатор.

Хорошая шутка должна быть правдоподобной, идеальная шутка является правдой

Ваганыч Петросян исклчительно идеально шутит. Вот только несмешно на вас.

Си сложен? Правда?

если ты дебил — да. Тогда твой удел php. Ибо магию free(3) тебе не осилить.

А как ещё назвать язык, в котором любое значение может измениться из-за любой функции, даже если она не держит на него указатель, даже опосредованно?

у меня для тебя плохие новости...

Неправильно - не будет работать вообще нигде.

C#
F#
M#

Никакой фантазии. Боюсь, эта компашка не сдохнет, пока все буквы в латинском алфавите не закончатся.