Erlang을 사용하여 "반대"를 결정한 이유는 무엇입니까?

Erlang을 사용하여 "반대"를 결정한 이유는 무엇입니까?

---

실제로 Erlang을 "시도"(단순히 기사를 읽는 것이 아니라 프로그램 된 것을 의미)하고 프로젝트를 위해 반대하기로 결정 했습니까? 그렇다면 그 이유는 무엇입니까? 또한 이전 언어로 돌아가거나 F #, Haskell, Clojure, Scala 또는 다른 기능과 같은 다른 기능적 언어를 사용하기로 선택한 경우 이것도 중요하며 그 이유를 설명합니다.

---

나는 Haskell의 놀라운 타입 시스템의 단순한 장점 때문에 Erlang의 개인 프로젝트를 위해 Haskell로 돌아 왔습니다. Erlang은 일이 잘못되었을 때 처리 할 수있는 수많은 도구를 제공합니다. Haskell은 처음부터 잘못되는 것을 방지하는 도구를 제공합니다.

강력한 유형 시스템을 사용하는 언어로 작업 할 때 컴파일 할 때마다 코드에 대한 무료 정리를 효과적으로 증명하는 것입니다.

당신은 또한 Haskell의 typeclass 기계로부터 많은 과부하 설탕을 얻습니다.하지만 그것은 나에게 크게 부차적 인 것입니다-비록 그것이 내가 끔찍하게 장황하거나 비 관상적이고 Erlang에서 사용할 수없는 추상화를 표현할 수 있다고해도 (예 : Haskell의 카테고리 확장).

저는 Erlang을 좋아하고 그 채널과 손쉬운 확장 성을 좋아합니다. 나는 이것이 내가 필요한 일이 될 때 그것을 의지합니다. Haskell은 만병 통치약이 아닙니다. 나는 공간 소비에 대한 더 나은 운영 이해를 포기합니다. 마법의 원 패스 가비지 수집기를 포기합니다. 나는 OTP 패턴과 그 모든 쉬운 확장 성을 포기합니다.

그러나 일반적으로 말했듯이 Haskell에서 타입 체크를하면 옳은 보안 담요를 포기하기가 어렵습니다.

---

우리는 Haskell, OCaml 및 (현재) F #을 사용하므로 C와 유사한 구문의 부족과 관련이 없습니다. 다음과 같은 이유로 Erlang을 건너 뜁니다.

• 동적으로 입력됩니다 (우리는 Haskell의 유형 시스템의 팬입니다)
• '실제'문자열 유형을 제공하지 않습니다 (이유를 이해하지만 아직 언어 수준에서 수정되지 않은 것이 짜증납니다)
• 열악한 (불완전하거나 유지 관리되지 않은) 데이터베이스 드라이버가있는 경향이 있습니다.
• 배터리가 포함되어 있지 않으며이 문제를 해결하기 위해 노력하는 커뮤니티가없는 것 같습니다. 그렇다면 눈에 잘 띄지 않습니다. Haskell은 적어도 Hackage를 가지고 있으며, 그것이 우리가 다른 언어보다 그 언어를 선택하게하는 이유라고 생각합니다. Windows 환경에서 F #은 여기에서 궁극적 인 이점을 얻게됩니다.

지금 당장 생각할 수없는 다른 이유가있을 수 있지만 이것이 주요 포인트입니다.

---

Erlang을 피하는 가장 좋은 이유는 프로그래밍의 기능적인 방법을 사용할 수 없을 때입니다.

나는 몇 주 전에 반 Erlang 블로그를 읽었고 Erlang에 대한 저자의 비판 중 하나는 동일한 인수로 호출 할 때마다 함수가 다른 값을 반환하도록 만드는 방법을 알아낼 수 없다는 것입니다. 그가 정말로 알아 내지 못한 것은 Erlang이 의도적으로 그런 식이라는 것입니다. 이것이 Erlang이 명시적인 잠금없이 여러 프로세서에서 잘 실행되는 방법입니다. 순전히 함수형 프로그래밍은 부작용이없는 프로그래밍입니다. 당신은 Erlang을 우리의 블로거가 원했던 것처럼 작동하도록 팔을 비틀고 부작용을 추가 할 수 있지만 그렇게함으로써 Erlang이 제공하는 가치를 버릴 수 있습니다.

순수 함수형 프로그래밍 만이 올바른 프로그래밍 방법은 아닙니다. 모든 것이 수학적으로 엄격 할 필요는 없습니다. 응용 프로그램이 "기능"이라는 용어를 오용하는 언어로 작성하는 것이 가장 좋다고 판단되면 Erlang을 목록에서 제외하는 것이 좋습니다.

---

이미 몇 가지 프로젝트에서 Erlang을 사용했습니다. 나는 종종 편안한 서비스를 위해 그것을 사용합니다. 그러나 내가 사용하지 않는 곳은 Ruby on Rails와 같은 도구가 훨씬 더 나은 복잡한 프런트 엔드 웹 애플리케이션 용입니다. 그러나 배후의 파워 브로커에게는 Erlang보다 더 좋은 도구가 없습니다.

또한 Erlang으로 작성된 몇 가지 응용 프로그램을 사용합니다. CouchDB와 RabbitMQ를 약간 사용하고 EJabberd 서버를 몇 개 설정했습니다. 이러한 응용 프로그램은 해당 분야에서 가장 강력하고 간편하며 유연한 도구입니다.

JVM을 사용하지 않기 때문에 Erlang을 사용하고 싶지 않은 것은 내 마음에 꽤 어리석은 일입니다. JVM은 세상의 모든 일을하는 데있어 최고의 마법 도구가 아닙니다. 제 생각에는 다양한 도구 중에서 선택하고 단일 언어 또는 프레임 워크에 갇히지 않는 능력이 전문가와 코드 원숭이를 구분하는 것입니다.

추신 : 맥락에서 내 의견을 읽은 후 oxbow_lakes를 코드 원숭이라고 부르는 것처럼 보였습니다. 나는 정말로 그가 그렇게 받아들이지 않았다면 사과한다. 나는 프로그래머의 유형에 대해 일반화하고 있었고 그 사람이 한 의견에 근거하여 개인을 그러한 부정적인 이름이라고 부르지 않을 것입니다. 비록 내가 JVM을 일종의 거래 중단 자로 만들지 말라고 권하더라도 그는 아마도 좋은 프로그래머 일 것이다.

---

내가하지 않았지만, 인터넷상의 다른 사람들은 예를 들어

우리는 미 해군을위한 병렬 음향 광선 추적 알고리즘의 구현에서 C ++와 Erlang의 상대적인 장점을 조사했습니다. 우리는 pthreads 기반 C ++ 프로그래밍보다 병렬 Erlang에 대해 훨씬 더 작은 학습 곡선과 더 나은 디버깅 환경을 발견했습니다. 우리의 C ++ 구현은 Erlang 프로그램보다 최소 12 배 이상 뛰어났습니다. IBM Cell BE 마이크로 프로세서에서 Erlang을 사용하려는 시도는 Erlang의 메모리 공간 때문에 좌절했습니다. (출처)

그리고 ICFP 경연 대회의 여파로 다시 읽었던 기억이 내 마음에 더 가까운 것 :

코딩은 매우 간단하여 의사 코드를 C ++로 변환했습니다. Java 또는 C #을 사용할 수 있었지만 C ++에서 높은 수준의 프로그래밍이 매우 쉬운 시점에 왔으며 이러한 경우 낮은 수준의 비트 트위들 링으로 빠르게 드롭 다운 할 수있는 옵션을 유지하고 싶었습니다. 아래로. Erlang은 내가 해킹하는 데 가장 좋아하는 언어이지만, 내가 스스로를 구제 할 수없는 성능 문제가 발생 할까봐 걱정했다. (출처)

---

저에게는 Erlang이 동적으로 입력된다는 사실이 저를 조심스럽게 만듭니다. 나는 비록 이렇게 사용을 그들 중 일부는 너무 매우 문제가 지향하기 때문에 동적 언어를 입력, 나는 그들이 정적으로 대신 입력 된 소원 (파이썬을, 나는 그것으로 많은 문제를 해결).

즉, 실제로 Erlang을 한동안 사용해 보려고했으며 소스를 다운로드하기 시작했습니다. 그래서 당신의“질문”은 결국 무언가를 성취했습니다. ;-)

---

대학 때부터 얼랭을 알고 있지만 지금까지 내 프로젝트에 사용한 적이 없습니다. 주로 저는 주로 데스크톱 응용 프로그램을 개발하고 있으며 Erlang은 멋진 GUI를 만드는 데 좋은 언어가 아니기 때문입니다. 하지만 곧 서버 응용 프로그램을 구현할 것이며 Erlang을 사용해 볼 것입니다. 그것이 좋은 이유이기 때문입니다. 그러나 나는 더 많은 라이브러리가 필요하다는 것이 걱정스럽기 때문에 Java를 대신 사용해 볼 것입니다.

---

여러 가지 이유 :

• C 언어 군에 익숙한 사람과는 낯설 기 때문에

• Java Virtual Machine 에서 실행하여 JConsole과 같이 알고 이해 한 도구와 JIT 및 GC에 대한 수년간의 노력을 활용 하기를 원했기 때문 입니다.

• 수년에 걸쳐 구축 한 모든 (Java) 라이브러리를 다시 작성하고 싶지 않았기 때문입니다.

• Erlang "생태계"(데이터베이스 액세스, 구성, 빌드 등)에 대해 전혀 모르기 때문입니다.

기본적으로 저는 Java, 플랫폼 및 생태계에 익숙하며 JVM에서 실행되는 것을 구축하는 데 많은 노력을 기울였습니다. 그것은이었다 훨씬 쉽게 스칼라로 이동합니다

---

단일 멀티 프로세서 시스템에서 많은 공유 데이터로 실행될 프로젝트에 Erlang을 사용하지 않기로 결정했고 Clojure가 실제로 공유 메모리 동시성을 가져 오기 때문에 Clojure와 함께갔습니다. 분산 데이터 저장 시스템에서 작업했을 때 Erlang은 분산 메시지 전달 시스템에서 정말 빛나기 때문에 매우 적합했습니다. 프로젝트를 해당 언어의 최고 기능과 비교하고 그에 따라 선택합니다.

---

독점, 다중 계층, 이진 프로토콜을위한 메시지 게이트웨이로 사용되었습니다. 서버에 대한 OTP 패턴과 서비스 간의 관계 및 이진 패턴 일치는 개발 프로세스를 매우 쉽게 만들었습니다. 이러한 사용 사례의 경우 다른 언어보다 Erlang을 다시 선호 할 것입니다.

---

The JVM is not a tool, it is a platform. Although I am all in favour of choosing the best tool for the job the platform is mostly already determined. Unless I am developing something standalone, from scratch and without the desire to reuse any existing code/library (three aspects that are unlikely in isolation already) I may be free to choose the platform.

I do use multiple tools and languages but I mainly targetg the JVM platform. That precludes Erlang for most if not all of my projects, as interesting as some of it concepts are.

Silvio

---

While I liked many design aspects of the Erlang runtime and the OTP platform, I found it to be a pretty annoying program language to develop in. The commas and periods are totally lame, and often require re-writing the last character of many lines of code just to change one line. Also, some operations that are simple in Ruby or Clojure are tedious in Erlang, for example string handling.

For distributed systems relying on a shared database the Mnesia system is really powerful and probably a good option, but I program in a language to learn and to have fun, and Erlang's annoying factor started to outweigh the fun factor once I had gotten past the basic bank account tutorials and started writing plugins for an XMPP server.

---

I love Erlang from the concurrency standpoint. Erlang really did concurrency right. I didn't end up using erlang primarily because of syntax.

I'm not a functional programmer by trade. I generally use C++, so I'm covet my ability to switch between styles (OOP, imperative, meta, etc). It felt like Erlang was forcing me to worship the sacred cow of immutable-data.

I love it's approach to concurrency, simple, beautiful, scalable, powerful. But the whole time I was programming in Erlang I kept thinking, man I'd much prefer a subset of Java that disallowed data sharing between thread and used Erlangs concurrency model. I though Java would have the best bet of restricting the language the feature set compatible with Erlang's processes and channels.

Just recently I found that the D Programing language offers Erlang style concurrency with familiar c style syntax and multi-paradigm language. I haven't tried anything massively concurrent with D yet, so I can't say if it's a perfect translation.

So professionally I use C++ but do my best to model massively concurrent applications as I would in Erlang. At some point I'd like to give D's concurrency tools a real test drive.

---

I am not going to even look at Erlang.

Two blog posts nailed it for me:

1. Erlang machinery walks the whole list to figure out whether they have a message to process, and the only way to get message means walking the whole list (I suspect that filtering messages by pid also involves walking the whole message list)

   http://www.lshift.net/blog/2010/02/28/memory-matters-even-in-erlang

2. There are no miracles, indeed, Erlang does not provide too many services to deal with unavoidable overloads - e.g. it is still left to the application programmer to deal checking for available space in the message queue (supposedly by walking the queue to figure out the current length and I suppose there are no built-in mechanisms to ensure some fairness between senders).

   erlang - how to limit message queue or emulate it?

Both (1) and (2) are way below naive on my book, and I am sure there are more software "gems" of similar nature sitting inside Erlang machinery.

So, no Erlang for me.

It seems that once you have to deal with a large system that requires high performance under overload C++ + Boost is still the only game in town.

I am going to look at D next.

---

I wanted to use Erlang for a project, because of it's amazing scalability with number of CPU'S. (We use other languages and occasionally hit the wall, leaving us with having to tweak the app)

The problem was that we must deliver our application on several platforms: Linux, Solaris and AIX, and unfortunately there is no Erlang install for AIX at the moment.

Being a small operation precludes the effort in porting and maintaining an AIX version of Erlang, and asking our customers to use Linux for part of our application is a no go.

I am still hoping that an AIX Erlang will arrive so we can use it.

참고URL : https://stackoverflow.com/questions/2199368/why-did-you-decide-against-using-erlang