고는 안 써봐서 잘 모르지만 코틀린 네이티브랑 위치가 겹친다고 생각. 네이티브 환경에서 GC를 지원한다는 특징이 같으니까.
근데 고 문법이 편리한 건가해서 예전에 간단히 살펴본 거론 별로 감흥이 없었음. 그래서 코틀린 네이티브가 정식 릴리즈 되면 빌드 속도 이외엔 고를 선호할 이유가 없지 않나 생각했지. 성능은 미지수니 넘어간다치고.
고를 쓸만한 다른 이유가 더 있으려나.
고는 안 써봐서 잘 모르지만 코틀린 네이티브랑 위치가 겹친다고 생각. 네이티브 환경에서 GC를 지원한다는 특징이 같으니까.
근데 고 문법이 편리한 건가해서 예전에 간단히 살펴본 거론 별로 감흥이 없었음. 그래서 코틀린 네이티브가 정식 릴리즈 되면 빌드 속도 이외엔 고를 선호할 이유가 없지 않나 생각했지. 성능은 미지수니 넘어간다치고.
고를 쓸만한 다른 이유가 더 있으려나.
코루틴이나 future와는 차원이 다른 고루틴이 있음
그리고 코틀린 네이티브 라이브러리나 플랫폼 지원이 부실함. 고도 1.6 정도 되서야 쓸만한 라이브러리들이 안정화되서 붐이 오기 시작한 걸 생각해보면 실 사용까지 얼마나 걸릴지 모르겠음
kotlinx.coroutines가 고루틴의 기능을 모두 포함하고 있는 게 아닌 거임? 찾아봤더니 SO에서는 고루틴의 특징이 채널이라고 하는 것 같아서. 라이브러리는 납득함. 코틀린은 라이브러리를 자바에 위탁하는 처지니...
채널이야 스레드간에도 운용 가능한 개념인데 고루틴의 근본 특징이라고 하기는 어렵지 흔히 말하는 경량 스레드를 구현하면서 미친듯한 효율을 달성한게 고루틴이란게 제일 큰 의미일 듯 사용의 편의성도 다른 언어들의 경량스레드들 대비 훨씬 좋고
기능적으로는 비슷한데 Go는 프로그래머가 해야할 일을 대신 해줘서 편하다는 장점이 있음.
http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
그건 kotlinx.coroutines도 가능한 것 같아서 그런 거임.
https://github.com/Kotlin/kotlinx.coroutines/blob/master/docs/basics.md#coroutines-are-light-weight
그러니까 이 링크의 경량 스레드라는 개념은 요즘 존나 흔한데 숫자로 나오는 구체적인 효율이 고루틴이 엄청 좋다는거
그리고 코틀린 코루틴은 기본은 싱글 스레드 기반이고 멀티스레딩에서 이용하려면 좀 많은 걸 해줘야 하는 걸로 알고 있는데 고루틴은 그부분까지 다 알아서 해줌 사용자는 스레드니 뭐니 신경 끄고 고루틴만 띄우면 됨
@0xrgb: 5가지 항목을 확인했는데, 내가 보기엔 맨 마지막에 표준 라이브러리 기본 비동기 지원 빼고 문제 없는 것 같음. 그것도 개선이 불가능한 문제는 아닌 것 같고.
코루틴 가이드를 보면 분량에 질리기는 하지만, 반대로 고루틴은 스레드를 신경써야하는 상황을 어떻게 다룸?
고언어에는 스레드 개념 없어 ㅋㅋㅋㅋ 동시성/비동기 다루는 유일한 툴이 고루틴이야 ㅋㅋ 동시성 다룰 때 생기는 동기화 문제에 대한 해결책을 묻는 거라면 그점은 타언어랑 크게 다를게 없지 메세지 전달만 하든가 혹은 메모리 공유를 하되 뮤텍스 등을 활용하든가
@웹땔: UI 스레드같은 걸 어떻게 다루는지를 물어본 거임. coroutines 라이브러리가 복잡하긴 하지만 내가 살펴보기엔 다 이유가 있었고, 더 간단해지는 게 가능한가 싶었으니까. 고언어보다 나중에 나온 건데 신경쓰지 않았을 리도 없고.
뭘 다루든지 그냥 고루틴 함수를 호출하지 UI 이벤트 핸들러 함수가 정의 되어있다면 그냥 go handler(args);
딱히 사용법이랄게 없다는게 고루틴 장점이라 뭐 설명할 게 없어
그럼 네이티브 라이브러리가 스레드 지역 저장소같은 걸 쓰는 경우는 대응이 불가능한 건가?
고루틴에는 스레드 로컬 스토리지 개념 자체가 없음
그래서 자바 하던 사람들이 고언어에서 스레드 로컬 스토리지 아날로그를 만든다고 이것저것 해놓은 라이브러리들이 있는데 안쓰임
어.. FFI를 쓰는 경우를 말한 거임. 뭐 슬슬 작위적인 예가 되는 것 같으니 아무렴 어떠냐 싶기도 하지만, 못하는 거와 안 하는 거는 차이가 있으니까.
https://stackoverflow.com/questions/1880262/forcing-goroutines-into-the-same-thread
이걸 물어보는 거였음. 내 생각엔 이 문제에 대해선 kotlinx.coroutines가 더 나은 것 같음.
애초에 고언어는 고루틴이 아닌 스레드별로 개별적인 무언가를 한다는 개념 자체가 없으니 그런게 없어서 문제라고 할 이유가 없지 고루틴들에 그룹별로 개성(?)을 주려면 보통 Context를 공유함
내 생각에는 지금 자신이 쓰는 언어의 개념을 타언어에 주입시키려하면서 이런게 있냐 없냐 하니 답이 안 나오는 것 같은데
그치. 고언어 내에선 스레드를 신경쓰는 상황이 없을 테니. 그래서 작위적이라고 말한 거고. 또 고언어는 그만큼 간단함을 얻어올 수 있었겠지. 근데 코틀린도 스레드를 신경 끄면 그렇게 복잡하진 않거든.
내 생각은, 코틀린 코루틴이 복잡한 건 복잡한 상황에 대한 옵션이고, 고루틴은 복잡한 문제를 해결하는 걸 회피한 것 같음.