Linux 버전의 PowerShell?

마이크로소프트에서 최근에 PowerShell 로 CMD 를 대체하려 한다는 뉴스와 함께, 마소가 PowerShell 을 Linux 로도 포팅했다는 소식이 소개되면서 PowerShell 과 유닉스 파이프에 대한 토론이 있었습니다.

그것에 대해 적었던 내용들을 포스팅 합니다.

유닉스 철학의 포인트들중 일부: 바이너리 헤이터, 텍스트 성애자. 그것도 플랫하고 멍청한(KISS) 텍스트를.

McIlroy, the head of the Bell Labs CSRC (Computing Sciences Research Center), and inventor of the Unix pipe, summarized the Unix philosophy as follows[1]:

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

약간 유사한 예가 아닐까 하는게, 우리가 매일 짜는 프로그램들을 예로, 프로그램은 신택스적으로 괴앵장히 구조화된 예술품이지만, 우리는 오직 플랫한 텍스트 파일로만 컴파일러와 대화를 하죠.

Continue reading

프로그래밍의 특급 비밀

coolspeed

This book has a lot of knowledge in it, but it is mainly about expertise. It is going to try to teach you the things about Unix development that Unix experts know, but aren’t aware that they know.
– Eric S. Raymond, “The Art Of UNIX Programming”

벤처캐피탈 업계에는 이런 역학이 존재합니다: 최고로 잘한 투자는 수익이 나머지 모든 투자 수익의 합보다 많다. 나머지중 최고로 잘한 투자는 나머지 모든 투자 수익의 합보다 많다.

프로그래밍에도 비슷한 역학이 존재합니다.
프로그램은 90%의 실행시간을 10%의 코드 실행에 소모합니다.[1]

이것을 통해 우리는 놀라운 추론을 해낼 수 있습니다.
시스템을 성능이 낮지만 생산성이 좋은 언어로 짜고, 그중 10% 의 핫스팟만 찾아내 C++ 로 짜면 끝.

실제로 (일부) 천재 프로그래머들은 시스템을 어떻게 설계했을까요?

1. YouTube

검색창은 Go 프로그램. 웹 애플리케이션 서버는 느린 Python 으로 짰습니다.

2. GitHub

“GitHub” 의 “Hub” 은 느린 Ruby on Rails 이고, “Git” 은 C.

3. Instagram

사진 저장은 Amazon S3 (네이티브 코드 예상). 웹 프런트는 C코드 (NginX). 데이터베이스는 C (PostgreSQL).
웹 애플리케이션 서버는 Django (Python).

4. Uber

DB: C++(MySQL)
Index: C (Redis)
애플리케이션: Javascript

Continue reading

Python 을 사용하는 대기업들 지금은 어떻게 됐을까?

Google

Google 얘기는 빼놓을 수 없다. Python 언어의 발명자 Guido van Rossum 도 구글에 계시기 때문이다.

Google 은 Python 을 좋아하다가, Go 언어를 만들었다.

특히 Python 언어의 플래그쉽같은 존재였던 YouTube, 아직도 Python 인걸로 알고 있다. 하지만 YouTube 의 검색창의 모든 검색은 Go 언어로 구현된 프로그램을 통해 일어난다고 한다. (프록시만 하는지, 구현까지 하는지는 잘 모르겠지만, 구현이야 당연히 구글의 기존 C++ 프로그램이겠지 싶다) [1]

dl.google.com 이 Go 언어로 만들어졌다고 한다. Chrome 의 압축 프록시가 Go 언어로 구현되었다고 한다. [1]

Dropbox

Dropbox 는 빠른 Python 구현인 Pyston 을 개발하다가, 이미 구현된 빠른 Python 인 PyPy 를 만지작거리다가.. 결국 Go 언어로 갈아탔다. [7]

Uber

오래되진 않았지만, 요즘은 Uber 이야말로 핫하다고 할 수 있지 않은가. 성능 크리티클한 부분을 Go 로 만들었다. (Node.js 를 고려하다가 Go 를 선택했다고 함.) [2]

Pinterest

Gevent 로 Python 을 빠르게 하다가 [3], Elixir 로 갈아탔다. [4]

참고로 Pinterest 는 MAU (Monthly Active Users) 가 1 억에 달한다고 한다. [5]

Alexa 에 의하면 Pinterest 는 Netflix.com 보다 트래픽이 많다고 한다. [6]

여담

여담으로 Ruby on Rails 로 시작한걸로 유명한 Twitter 는 Scala 로 갈아탔고, GitHub 은 음 잘 모르겠는데 아직도 Ruby on Rails 인가..?

여담중의 여담으로 Elixir 은 Ruby on Rails 핵심 커미터였던 개발자가 Ruby 로 컨커런시 처리하는 것에 지쳐서 Erlang 으로 돌아선 것이라고 한다.

결론

결론은 반전이다. YouTube 도 Python 으로 만드는데, Python 이 너무 느리게 느껴질 정도로 성공하는 서비스부터 만들고 보자. 그때까지 언어 성능은 별로 중요하지 않다.

Continue reading

오픈소스 네트워크 라이브러리 일람

1. Century

coolspeed 가 만든 Go 언어 네트워크 라이브러리 입니다:
https://github.com/coolspeed/century

이것이 1등입니다. 그냥 말이 필요 없습니다 ( __ __)

2. Skynet

https://github.com/cloudwu/skynet/graphs/contributors

C 언어와 lua 로 된 네트워크 라이브러리.
중국 게임 업계 제일 유명한 스타 개발자인 cloudwu 가 개발한 네트워크 라이브러리 입니다.
아직도 활발하게 개발 중이네요. Pull Request 도 활발하나 봅니다.

천하의 netty 가 github 에서 별표 7000개인데, Skynet 이 무려 4000개.

3. Netty

Java 네트워크 라이브러리.
한국인이 개발하고 (게임 업계 포함하여) 전 세계 개발자들이 추앙하는 네트워크 라이브러리인데  정작 한국에서는 많이 안쓰이는?

https://github.com/netty/netty

4. SuperSocket

C# 네트워크 라이브러리.
중국인이 만들었는데 한국 게임 업계에 많이 쓰이는..

https://supersocket.codeplex.com

5. Boost.ASIO

C++ 슈퍼천재(괴짜)들이 만든거라 워낙 웰메이드. 사용도 쉽고.
언뜻만 보기에도 탑 솔루션인데, C++ 17 표준에 포함된다는게 거의 확정이라 (개인적으로 80%확률일거라 봄) 가장 핫하다고 볼 수 있지 않을까요.

Continue reading

싱글스레드 모델이 액터 모델(Actor-Model)보다 나은 X가지 이유

1. 액션(동작) 순서 컨트롤이 된다. 액션의 페이스를 컨트롤할 수 있다. 예를 들어 30fps 로 모든 몹의 x좌표 더하기 1. 액터 모델에서는 비동기라서 그 액션이 어느 프레임에 들어갈찌 모른다.

2. 디버깅이 쉽다.
2.1 액터 모델에서는 글로벌 상태에 브레이크 포인트를 찍은 후에 매개인의 메일박스를 검사해야 하는 번거로움이..
서버의 경우 클라와 달리 브포보다 로그가 더 유용할 경우가 많다. 예를 들어서 Joe Armstrong 과 Richard Stallman 등 분들이 모두 printf 디버깅 방식을 더 선호한다는 소문이… 하지만 서버가 클라만큼 상태가 복잡할 경우, 브포(==시간정지) 를 통한 글로벌 상태 파악이 극히 중요해질 때가 있다.
2.2 그리고 액터 모델은 비결정론적이라서 어떤 버그들이 어떤때는 재현되고 어떤 때는 재현되지 않을 수 있다. (그러고보니 2.2 항목은 LMAX 의 장점만 말하면 다 나오네.)

3. 반경 10메터안 모든 몹들에게 범위공격. 액터모델의 경우 남의 좌표를 알 수 없어서 일일이 물어야 한다. “님 좌표 얼마임?” (그렇지 않으면 좌표를 좌표테이블에 등록해야 하는데, 그러면 액터모델이 아니게 됨) (IO 오버헤드, 코딩 코스트)

4. 로드밸런싱따위 필요없다. 액터모델의 경우 (스케쥴러에 따라 다르지만) (어차피 스케쥴러 연구하는 사람은 없으니) 액터 로드밸런싱이 필요한 경우가 있다(Skynet 역사 참조). 반면 싱글스레드 모델에서 프로그래머는 신이고, 로드밸런싱따위 필요없다.

5. 트랜잭션?

6. 클라도 싱글스레드 모델이잖아.

7. CPU 성능에 좋다 (동일언어) (사실 이건 가장 중요하지 않은 원인이다) (늘여쓰면 글한편감이라 자세한 내용은 생략한다).

결론: 두 모델이 서로 다른 문제 도메인 (Problem Domain) 에 적합할 것 같다는거다:

  • 액터모델은 격리성, 분산성과 faul-tolerance 가 골(goal)에서 제일 중요한 경우 또는 message-passing 자체가 문제를 잘 모델링할 경우 (IM, Instant Messenger: e.g. Facebook Messenger, Whatsapp, etc.)
  • 싱글스레드 모델은 글로벌 상태 컨트롤이 중요한 경우. 예를 들어 게임. (시뮬레이팅 문제?)

적재적소(適材適所).

길게 쓰면 아무도 안읽으니 이번에도 후딱 끝내는 미덕을 발양하겠다.

(끝)

[번역] ZeroMQ설계자: 세계를 구원하라

  • 번역: coolspeed

이 글은 ZeroMQ설계자가 지은 책이며 ZeroMQ의 “바이블”이라 불리는 ZGuide 의 머리말이다.

이 책은 다양한 프로그래밍 언어 예시 버전의  PDF, epub 등 이북 포맷으로 다운로드도 가능하고[1], 한글 번역도 온라인에서 읽을 수 있다. 당연히 그속에는 이 머리말의 한글번역도 포함되어 있었다. 다만 번역이 만족스럽지 못해 필자가 직접 번역했다.


ZeroMQ 100 자 요약

ZeroMQ (ØMQ, 0MQ, or zmq 라고도 표기함) 는 임베드블 네트워킹 라이브러리처럼 생겼는데 실제론 컨커런시 프레임웤처럼 작동한다. ZeroMQ 는 원자적으로 메시지를 배송하는 소켓을 제공하는데 그 배송수단으로는 스레드간 통신, 프로세스간 통신, TCP 그리고 multicast 등 다양하다. 당신은 ZeroMQ 소켓을 N-to-N 방식으로, fan-out, pub-sub, task distribution, 그리고 request-reply 등 패턴으로 사용할 수 있다. 이것은 클러스터 제품들의 뼈대로 사용하기에 전혀 문제 없는 높은 성능을 가지고 있다. 이것의 비동기 I/O 모델은 당신이 message-passing task처럼 짜여진, 확장성 있는 멀티코어 애플리케이션을 만들 수 있게 해준다. 언어 API 만큼 고득점을 갖고 있으면서 거의 모든 OS에서 돌아간다. ZeroMQ 는 iMatix 에서 개발했으며 LGPLv3 라이센스로 소스가 오픈되어있다.

 

세상을 구원하다

ZeroMQ 요놈은 정말 좋은데. 어떻게 말로 표현할 방법이 없네.  ZeroMQ의 가치를 설명하기 위해, 일부 사람들은 요놈이 제공하는 모든 훌륭한 기능들을 나열하는 것으로 부터 시작하려고 한다:

  • 이놈은 스테로이드를 처먹은 소켓이야.
  • 이놈은 라우팅 기능이 있는 우편함으로 비유할 수 있지.
  • 존나 빠름.

Continue reading