원숭이 언어 VII의 구현 비교: 내 이름은 3… 스칼라 3

반응형

이전에.

마지막 회에서 몽키의 크리스탈 구현인 몬예트의 변경 사항을 검토합니다.

스칼라와의 이야기

저는 10여 년 전부터 2.6 버전에서 스칼라를 사용하기 시작했습니다. 모든 것이 흔들렸고, IDE의 지원은 거의 없었지만, 신나고, 새롭고, 재미있었다. 그 콘셉트들은 신선하고 감동적이었습니다. 그리고 새로운 버전이 나왔고, 사람들은 파도를 탔습니다. 모두가 새로운 큰 것에 대해 이야기하고 있었습니다. 나는 내가 할 수 있는 한 파도를 가장 잘 탄다. 사실 잘 했어요, 아주 잘했어요. 스칼라 덕분에 나는 한 번이 아니라 두 번 이민을 갔다; 나는 가족과 내 조국을 떠나 해외의 새로운 모험에 착수했다. 스칼라에게 많은 감사를 표합니다.

 

하지만 시간이 흐르고, 괴짜들은 새로운 반짝이는 것들을 좋아하기 때문에, 저는 더 푸른 목초지로 이사했습니다. 지난 3년 동안 전문적으로 스칼라 코드를 한 줄도 작성하지 않았습니다. 많은 Python, Kotlin, Java(약간의 TypeScript와 Go)가 있지만 Scala는 아닙니다.

스칼라 3으로 돌아가기

Langur를 소개합니다, 원숭이 언어를 구현한 스칼라 3

오랜 세월이 흐른 후 이미 알고 있던 곳으로 돌아간 경험. 익숙하지만 낯설다.

내가 사랑했던 것, 사랑하지 않았던 것, 그리고 다른 나라에서 보낸 시간 덕분에 다른 것들을 다른 빛으로 볼 수 있습니다.

 

좋은 부분

새 열거형

스칼라는 오래된 버전의 열거형을 가지고 있었는데, 실제로는 친근하지 않고 몇 가지 기능이 부족했기 때문에 아무도 사용하지 않았다. 그러나 새로운 열거형은 훌륭하며 최신 열거 구현에서 기대하는 모든 기능을 갖추고 있다.

확장

Kotlin에서 영감을 받아, Extensions는 암시적 클래스를 대체하는 좋은 방법이며, 이론적으로는 래퍼 + 함수 호출의 인스턴스화 대신 함수 호출로 컴파일될 때 더 빨라야 한다.

 

컴파일러 속도

더 빨리 느껴져요, 아니면 더 좋은 기계가 생겼죠. 어쨌든

사용하지 않았지만 멋있는 기능들.

주어진 것과 사용은 함축성을 대체할 수 있는 올바른 방법인 것 같습니다. 유니언과 교차로 유형은 다른 언어에서도 훌륭하며, 스칼라 구현도 모범적이었으면 합니다.

메흐 부분

 

새 구문

라이언 레이놀즈의 But Why? meme

이유가 뭐예요? 파이썬 개발자들을 끌어들이기 위해? 그것은 파이썬처럼 전혀 보이지 않는다. 그리고 당신은 두 구문을 같은 파일에서 섞어서 일치시킬 수 있나요?

컴파일되지 않는 코드에 20분 동안 머리를 깨물고 있었는데 실수로 탭을 입력했다는 것을 알게 되었고 컴파일러 오류 메시지가 전혀 도움이 되지 않았습니다.

메타프로그래밍

 

이제 매크로를 하는 표준적인 방법이 생겼다니 다행이다. 하지만 너무 복잡해서 사용을 피해요. 나의 사용 사례는 매우 간단해서 매크로 코드를 유지하는 것보다 코드를 복사하여 붙여넣는 것을 더 선호했습니다.

IntelliJ IDEA는 아직 준비가 되지 않았습니다.

언어 자체에는 문제가 없습니다. IntelliJ의 스칼라 3 지원을 설명하는 가장 좋은 방법은 "임의"이다. 임의로 자동 가져오기, 임의 자동 완료, 임의로 작업 중지, 임의 실패 등의 작업을 수행합니다.

저는 또한 스칼라 플러그인 팀을 탓하지 않습니다. 변화가 엄청나고 적절한 지원은 많은 작업을 필요로 할 것입니다.

그것은 여전히 작동 가능하고, 빠르며, 나는 막히지 않았다. 그러나 IntelliJ가 그 과정에서 도움을 받았던 익숙한 경험은 아니다.

 

세월이 흘러 달라진 부분들.

스칼라 패턴 매칭은 정말 놀라워요.

패턴 매칭으로 매우 간결한 코드를 작성할 수 있었습니다. + 스마트 캐스트 + 파괴 시 코틀린으로 대체할 수 있지만 참고하십시오. 예

비교:

애니발

 

스칼라 3은 서명되지 않은 바이트를 지원하지 않지만 AnyVal로 합리적인 근사치를 만들었습니다.

Kotlin Nullable 유형 대 Scala 옵션

저는 스칼라 옵션의 열렬한 옹호자였습니다. 제가 쓰던 펑키오날레 라이브러리 아래서 코틀린(Kotlin)에게 넘겼을 정도로요.

Kotlin을 몇 년 동안 사용한 후에는 옵션 유형이 투박하고 장황하며 의식으로 가득 차 보입니다. 대신 Nullable 타입은 실제 사용 사례의 99%를 커버하고, 나머지 1%는 Option from Arrow(원래 코드 중 일부를 기여함)를 사용할 수 있습니다.

그 모든 의식을 피하려고 노력하면서, 나는 언제 Option이 필요한지에 대해 신중했다. 그 후, 저는 이러한 변경 사항을 원래의 Kotlin 코드로 역포환했는데, 이것은 전체 옵션[T] 시그니처 및/또는 Some(T)/map/foreach/양도 호출을 위한 단일 문자를 삭제하는 것처럼 쉽습니다.

 

Nullable Type과 Options는 기능적으로 동일하다고 생각하기 쉽지만, 성능/메모리 소비량의 차이로 해석되는 매우 다른 바이트코드를 생성합니다.

예

이 스칼라 코드는 기능적으로 다음과 같습니다.

이 코틀린 코드는.

정확히 같은 줄의 코드와 동등하면서도 자국어로는 관용적이다.

 

스칼라 코드는 프로키온 디컴파일러를 사용하여 디컴파일된 이 바이트코드를 생성한다.

여기에 포함되지 않은 두 개의 추가 수업을 제외하고요.

코틀린 코드는 프로키온으로 디컴파일된 바이트코드를 생성한다.

쉽고, 예시가 없고, 캐스팅도 없고, 포장도 없고, 추가 전화도 없습니다.

성능

 

공연에 대해 얘기해보자. 언제나 그렇듯이, 우리는 전통적인 Monkey 벤치마크 피보나치(35)를 실행하고 해석(평가)과 컴파일/VM인 Go, Kotlin 및 Scala의 My 구현을 비교할 것입니다.

인터프리터드 모드

Kotlin과 Scala 모두 Go보다 빠릅니다. 이는 JVM이 얼마나 잘 하고 있는지를 보여주는 증거입니다.IT 최적화. 하지만 코틀린은 스칼라보다 1.41배 더 빠릅니다.

메모리 소모에 대해 설명하면:

코틀린(JVM 포함)은 367.76 MB를, 스칼라(JVM 포함)는 617.45 MB를 소비한다.

 

컴파일됨/VM 모드

놀랍게도, 바이트를 다루는 것이 바둑의 요새 중 하나이기 때문에, 코틀린과 스칼라보다 바둑이 더 빠르다. 코틀린은 스칼라보다 1.38배 빠르다.

메모리 소모를 얘기하면.

코틀린(JVM 포함)은 362.98MB를 소비하고 스칼라(JVM 포함)는 596.64MB를 소비합니다.

저는 여전히 옵션의 사용이 스칼라의 성능에 영향을 미친다는 이론을 유지하고 있지만, 현재로서는 VisualVM 프로파일러를 스칼라 코드에 연결하여 어떤 일이 일어나고 있는지 확인할 수 없기 때문에 이론일 뿐입니다.

 

결론

스칼라 3는 좋은 언어이고, 새로운 추가 사항으로 언어가 더 명확해졌습니다. 저는 여전히 Kotlin을 선호하지만 전문적인 역량으로 Scala와 함께 일하는 데 문제가 없을 것입니다.