Kotlin언어 성공사례: Corda 블록체인(by R3)

Kotlin언어? 뭔 듣보잡? 성공사례가 있니?

찾아보니 있다.

corda_kotlin.png

CTO는 전 구글 시니어 엔지니어였다고 한다. CTO분이 얘기하신 Kotlin 선택 원인:

  1. 정적 타이핑 (그러고 보니 밀레니얼 세대 언어는 다 그런 것 같다)
  2. Java가 비즈니스 월드에서 중요해서. (하긴)
  3. 섹시해서 (구닥다리 Java랑 비교하니 그렇지)
  4. 배우기 쉬워서 그래서 구인이 쉬워서 (보통 Java구인을 하고 1~3일 트레이닝 시키면 코틀린 언어 코딩을 할 수 있다고 한다)
  5. IDE지원 잘되서
  6. 컴파일 속도가 빨라서 (Scala 저격하며)
  7. 문서화가 잘돼있어서
  8. 내가 할줄 알아서. 내가 좀 해봤는데 재밌어서

그러면서 하는 말이 Kotlin이 없었다면 Scala 썼을 것이라 한다.

마지막에 내린 결론이: 잘한 것 같다.


 

개인적으로 Kotlin이 정말 반갑다. JVM팬으로서 항상 언어가 아쉬웠는데, Java는 구닥다리고, Scala는 너무 복잡하고* Groovy는 언어가 아쉽고, (Scala 와 Groovy공통점이 모두 창립자가 포기했다는 점..) Clojure는 대중성을 전혀 염두에 두지 않은 것 같고. 그런 점에서 Kotlin은 JVM에게 복음과도 같았다.

특히 실행 가능한 환경이  JVM / Javascript VM / Native 로 다양해서 플랫폼에 발목 잡히는 일이 없도록 했다는 점도 칭찬하고 싶다. (마이크로소프트가 최근에야 터득한 점)

JVM, V8엔진, 네이티브 세가지 모두 점점 중요해지는 플랫폼인 것 같다. 아 WASM(Web Assembly)까지 지원하면 더욱 좋겠지만. 이게 미래가 될 수도 있으니. 걱정할 필요가 없는게 컴파일러 플랫폼이 LLVM이어서 WASM이 GC만 지원하면 WASM으로 컴파일 하는 것도 식은 죽 먹기일 거라는 점.

최근 홍민희님의 PyConKr 2017 발표 <파이썬과 다이아스포라>를 보고, 최근에 읽은 <사피엔스>와 결부해서 느낀 점이: 성공한 언어들은 모두 대중성을 키 피처로 치밀하게 기획된 것 같다는 점이다. 민족의 용광로처럼 말이다. (적어도 대량 전파됨을 성공의 척도로 본다면 그렇다)

심지어 Rust도 너무 결백증스러운 면이 있어서 대중성이 의심스럽다.

다행히 Kotlin은 대중성을 키 피처로 설계된 듯하다. 그것의 일환으로 Java월드 레거시에 대한 포용성도 잘 설계된 것 같다.

미래가 지켜볼만하지 않은가!

* 참고로 R3 Corda의 경쟁상대인 IBM hyperledger fabric 은 Go언어로 만들었다.

부록

* TIOBE 프로그래밍 언어 유행도 인덱스에 따르면 Scala는 D언어나 COBOL언어보다 인기가 적다: https://www.tiobe.com/tiobe-index/

 

왜 그동안의 함수형 언어 홍보는 잘못됐는가?

그렇다. 함수형 프로그래밍과 그것을 포함하는 “선언식 프로그래밍” [1] 은 그동안 이른바 산업 프로그래밍과 산업 프로그래밍 언어의 혁신요소들의 주요 원천 중 하나였다[2]. 하지만 그동안의 함수형 언어 홍보에서는 중요한 오류들을 범했다.

예를 들어 함수형 에반젤리스트들은 아래와 같은 광고어들을 내세웠었다.

“함수형 언어에서 변수는 값이 바뀔 수 없어요. 그리고 이게 좋아요. 버그를 막아주니까.”

이걸 듣는 사람들의 반응은 아마도 당장 발이 묶인 느낌일 것이다. 그래서 “그러면 코딩을 어떻게 해요?” 라고 묻는다면, 이런 대답이 올 것이다. “변수 변경이 정말 필요할 때는 변경할 수도 있어요. 그리고 함수형 프로그래밍에서는 꼬리 재귀를 사용하지요.” 그러면서 아마도 계승(factorial)이나 피보나치 예제를 주머니에서 꺼낼 것이다.

이렇게 되면 프로그래머는 아마도 고개를 갸우뚱 하며 (말은 하지 않고) 생각할 것이다.

“그렇게 되면 어차피 명령식에서랑 똑같이 변하는 변수를 사용하지 않을까? 과연 참고 변수를 변하지 않게 사용할 수 있을까?”

“그리고 나는 일할 때 매일 계승을 짜진 않는단 말야..흠..”

Continue reading

프로그래밍 바벨탑 해결

Python 을 Go 로 번역해주는 트랜스컴파일러:

https://github.com/google/grumpy

Python 을 Go 로 트랜스컴파일한다는 것은 무엇을 의미하는가, Python이 최정적으로 네이티브 컴파일 됨을 의미합니다..

저는 어제 이 리포의 별수가 실시간으로 오르는 걸 보았습니다. 오늘은 어제 대비 별표가 많이 늘어났더라구요.

이런 갓 프로젝트를 누가 만들었나 했더니 갓 Google 님이 만들었더라구요.

이게 좀더 성숙해지면 구글은 python 으로 짜여진 유튜브를 네이티브 프로그램으로 서비스 하겠네요.

자 그러면 앞으로 이런 식으로 프로그래밍 바벨탑들이 다 해결 될 것인가?

 


하스스톤 역기획 해 python 코딩하는 알파고:

http://kotaku.com/google-deepmind-is-now-analysing-magic-and-hearthstone-1767628685

프로그래머들을 아예 다 해치울지도..? ㅋㅋㅋ

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

AST diff? – 홍민희의 트윗글로부터

홍민희트윗글에서 본 내용인데:

텍스트 파일로 쓰인 소스 코드는 AST의 직렬화일 뿐인데 그걸 왜 사람이 편집하냐, 편집기가 AST 자체를 다루면 되지 않냐는 얘기는 전부터 많았다.

그런데 Rust 쪽의 “언어 생소함 예산” 관점에 따르면 새로운 언어는 혁신하려는 아주 적은 양의 생소함만을 지니고 있지 않으면 진입 장벽 때문에 사람들이 외면해서 망해버린다.
http://words.steveklabnik.com/the-language-strangeness-budget

따라서 AST 수준에서 편집하는 편집기와 언어라는 개념을 실현시키려면, 딱 그 아이디어 말고 다른 부분에서는 혁신을 포기해서 원포인트 혁신을 한 뒤에, 다른 종류의 혁신은 이후의 다른 언어에게 양보해야 한다.

그런데 애초에 그런 아이디어에 매료된 사람들은 야심이 있는 사람들이기 때문에 보통은 이것저것 평소에 프로그래밍 세상에 있던 불만들에 대한 아이디어를 다함께 버무려서 일거에 많은 것을 혁신하고 싶어하기도 한다. 그러면 망하는 지름길…

그런 반면 “코딩 스타일 차이로 인한 어려움”은 혁신의 어려움에 비해서 불편함은 다른 언어적 불편에 비하면 사소한 수준이라 그럭저럭 참고 쓸 수 있고. 그래서 나는 똑똑한 사람들의 “야심의 방향”으로 삼기에 작은 목표라서 혁신이 잘 안된다고 생각.

나는 AST 편집기라는 아이디어보다는 차라리 AST diff 아이디어가 더 불편한 것을 직접적으로 고치는 방식이고 퍼뜨리기도 비교적 쉽기 때문에 훨씬 먼저 달성되지 않을까 기대한다.

그러고 나면 각자 개발 환경에서 각자 취향대로 소스 코드를 포매팅하고 살아도 서식 문제로 버전 관리 시스템에서 충돌이 나지 않게 되기 때문에 점차 코딩 스타일의 차이 자체가 큰 문제가 되지 않는 방향으로 문화가 흐르지 않을지.

처음엔 격하게 공감했는데, 다시 생각해보니 문제점이 있었다.

텍스트 diff 가 쉬운 원인은 텍스트가 어의(Syntax)상으로는  구조가 있을지 몰라도 형식상으로는 리니얼하기 때문이다(다시말해 직렬화 되어있기 때문이다). AST 로 되어버리면 비교가 어려운 일이 된다.

비교가 됐다고 한들 diff 내용을 보여주기 위해서는 또 직렬화가 필요하다. 물론 직접 벡터 그림으로 보여주는 방법도 있지만, 요즘은 벡터 그림도 다 텍스트로 표현하지 않는가 – SVG, Graphviz, PostScript, Processing, etc. (PDF 는 잘 모름.) 게다가 모든 것을 CLI / TLI 에서 하는 Emacs 파(Linus Torvalds)도 고려되어야 한다. Visual Studio 식의 툴인들, 내부적으로는 텍스트로 표현할게 아닌가(Visual Studio 의 프로젝트 파일이 XML 이듯이). 어쨌거나 이 다시 직렬화 해야 하는 문제는 그냥 하면 된다. 큰 문제가 아니긴 하다.

내가 생각해낸 아이디어

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