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

[migmit.livejournal.com]

> Non-VM program often corrupts its memory with random data. That's why you want to restart on segfault.

For clarification: it seems like you think that garbage from one (non-VM) process somehow messes with other processes. Please tell me you don't mean it.

[alamar.livejournal.com]

We're talking about one VM process versus one non-VM process. VM processes don't corrupt their memory, non-VM processed do.

So naturally the solution for non-VM languages is multiprocessing, but it is often problematic (just look at the CORBA disaster).

[migmit.livejournal.com]

OK. Now we have several issues.

1) What does it have to do with "That's why you want to restart on segfault"?

2) Do you REALLY think anybody EXCEPT the failing process cares about some jerk corrupting memory?

3) Do you REALLY think corrupting some random memory is in any way different from corrupting some data structure?

4) What exactly does your "often" mean? Are you aware that all major OS'es are doing multiprocessing for a long time now?

[alamar.livejournal.com]

1) Segfault is what you have in non-VM languages instead of exceptions.
2) I don't care about anybody except my process. My process[es] is the only important thing on my dedicated machines.
3) You don't corrupt some random data structure in VM language. This is only possible with evil determination. In non-VM language, any buffer overrun might corrupt some unrelated data structures. Doesn't happen in VM languages.
4) You don't care about "major OS'es", you care about YOUR TASK.

VM languages are good for YOUR TASK, however big and complex it is. OSes and non-VM languages are good for many things but NOT for your task.

You're too much theoretical. That's boring.

[migmit.livejournal.com]

> Segfault is what you have in non-VM languages instead of exceptions.

1) And what does it have to do with restarting?

2) You know that there is exception handling in non-VM languages too, right?

> My process[es] is the only important thing on my dedicated machines.

Just to clarify: do you also mean that only your services are important on JVM?

> You don't corrupt some random data structure in VM language.

Are you serious? Do you REALLY mean that I can't allocate two structures and accidentally write to the wrong one?

> In non-VM language, any buffer overrun might corrupt some unrelated data structures. Doesn't happen in VM languages.

Oh, really? So, when you say "non-VM language", you actually mean C (and friends), right?

> You don't care about "major OS'es", you care about YOUR TASK.

So, does it mean "no"?

> OSes and non-VM languages are good for many things but NOT for your task.

So far, you failed to show the difference.

[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]

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

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