apple swift

[juan_gandhi]

So, with the new "Apple language", object-oriented Java people are going to do what?
There must be some deep philosophy, explaining why they are so retarded.
I think.

I mean, I kind of heard an explanation from Josh; in my translation it sounds like this: "Java programmers are not very smart anyway, let's not overload them with closures and all that stuff."

The correlation I was writing about lately kind of shows itself again.
Weird.

Well, it's not Scala, of course; but it's a nice step in the right direction, I think.

Comments

[alamar.livejournal.com]

1) You usually can't continue after segfault, because your memory might be corrupted. You have to restart your process. Btw, memory might be corrupted even without segfault - you will never know.

2) There is exception handling in non-VM languages, but there are also segfaults which can't be avoided or handled as exceptions.

3) Surely, in my VM only my services are important. You're free to have your own VM.

4) "Do you REALLY mean that I can't allocate two structures and accidentally write to the wrong one?"
This is entirely different problem from buffer overruns. You can't overwrite unrelated data structure (if you allocate two structures in one place, they're related).

5) When I say non-VM language, I mean everything that calls into a wide range of native libraries. That includes Haskell, OCaml, ObjC, you name it.

6) The fact that OS'es do multiprocessing doesn't help you solve your task that much. Certainly that doesn't solve your task for you.

7) The difference is simple: non-VM languages emit SEGV, VM languages don't.
One that doesn't emit SEGV is safer because longer-living processes open up new possibilities.

[migmit.livejournal.com]

> You usually can't continue after segfault, because your memory might be corrupted. You have to restart your process.

Ah, so you mean restarting the process. Well, that goes for JVM services as well after an unhandled exception, doesn't it?

> This is entirely different problem from buffer overruns.

Well, you only mentioned buffer overruns in the previous comment. Your original statement was "your program may segfault due to error in library or your code, or corrupt data". There are LOTS of errors that lead to data corruption, and, frankly, buffer overruns are an insignificant minority.

> When I say non-VM language, I mean everything that calls into a wide range of native libraries.

What exactly do you mean by "calls"? You know that JVM libraries at least CAN call arbirtary native libraries, right?

> The difference is simple: non-VM languages emit SEGV, VM languages don't.

Am I supposed to care if my process fails because of SEGV or because of unhandled exception?

[alamar.livejournal.com]

"Well, that goes for JVM services as well after an unhandled exception, doesn't it?"
What's unhandled exception and why won't I handle it?
Every exception is logged and then execution continues as usual.
Non-VM languages don't have this option - they have to hard-fail and restart.

"buffer overruns are an insignificant minority"
Maybe I should have clarified, I thought this is obvious.
No they aren't so insignificant, but the problem here is - they're really deadly and there's not much you can do.

JVM libraries CAN call native libraries but they don't do that.
If they will it will be a totally different story.
JVM languages don't call native code, but {python/haskell/swift/whatever} libraries do it all the time. Which is kind of scary to me.

You can handle all exceptions. You can't handle SEGV gracefully. Why would you have unhandled exceptions?

[badula.livejournal.com]

Паранойя какая-то… Почти в любой практической системе отловить и обработать дурной доступ к памяти можно без особого хака. У виндовса есть SEH, у мака Mach exceptions, прямые линуксоиды обойдутся чаще всего сигналом. Суть же не в том как именно код развалится, а в том что данные с которыми он вынужден работать безвозвратно испорчены, а из такой ситуации никакого выхода нет. От того что процесс может чисто-технически продолжить куда-то бежать никому нет никакой пользы. Поднять процесс заново - дело не хитрое и чаще чем нет почти ничего не стоящее. Толку в таком поднимании не весть как много - он же сертифицированно с жуками внутри, опять упадёт.

[alamar.livejournal.com]

"данные с которыми он вынужден работать безвозвратно испорчены"
В случае с JVM они не будут испорчены. JVM не позволяет лёгким движением руки переписать чужие данные мусором. Поэтому в реальной жизни что испортится - это данные одного запроса/задачи/этапа.

И всё, дальше система продолжает работать. Параллельно выполнявшийся код даже не заметил беды.

"Поднять процесс заново - дело не хитрое и чаще чем нет почти ничего не стоящее"
Это всё потому, что при хрупких процессах люди предпочитают ничего в них не иметь ценного. Но это имеет свою цену. Чтобы процесс было поднять быстро и нехитро - за это платится определённая цена.

Напомню на всякий случай архитектуру раннего Stack Overflow: одна машина с 64G RAM под .net, плюс один сервер баз данных с таким же количеством памяти. Эта штука держала сотни rps сложных запросов (SO, ну ты представляешь), в сто потоков, с гигантским кешем в памяти.

Эту штуку не так просто запустить (минут 20 будет прогреваться), зато потом заменяет сразу целый кластер. Вот так надо.

[badula.livejournal.com]

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

[alamar.livejournal.com]

Есть такая беда. Но всё равно долгоживущие процессы для многих задач лучше короткоживущих.

"нулы постоянно дереференсятся, за пределы массивов постоянно кто-то норовит вылезти, ексепшоны типа еррор вылетают и разламывают код до основания контейнера"
Это всё не приводит к протуханию всего процесса. Проезд по чужой памяти - приводит.