Akhir-akhir ini banyak sekali bermunculan bahasa pemrograman baru, terutama sejak munculnya LLVM pada 2003, LLVM seperti framework untuk membuat compiler atau mereka --pembuat-- menyebutnya compiler infrastructure. Banyak sekali bahasa baru yang dibuat dengan backend LLVM ini, seperti Swift, Rust, Julia, dll.

Saya jarang --atau bisa dikatakan tidak pernah-- membuat artikel tentang bahasa pemrograman baru, tapi V, hmmm... ini bahasa terlalu menarik untuk diabaikan. Ada fakta-fakta yang bisa membuat kita tercengang! Setidaknya untuk sementara ini. Baiklah lihat kurva ini:

V Lang Stargazers

Gambar digenerasikan dari: star-history.t9t.io

Gambar kurva apa itu? Kurva peningkatan jumlah panggilan telp masuk Jokowi untuk cari posisi mentri kabinet Maju tahun 2019?? Tidak, itu adalah kurva peningkatan jumlah stargazer repository-nya bahasa V di Github.

Dilihat dari history star pada repositorinya di Github lumayan serem bukan? Ya ini adalah salah satu yang membuat saya tertarik untuk mendalaminya.

Selain itu, ternyata belum banyak orang yang membahas bahasa ini, baik di blog maupun vlog, bahkan ketika saya menulis artikel ini wikipedia-nya pun belum ada! Di-googling pun masih sepi.

Sekilas pertama kali kamu mencoba bahasa ini kamu pasti langsung mengira bahwa otak pembuatnya telah terkontaminasi oleh "bisa ular" Python, tapi semakin didalami semakin nge-Go dan nge-Rust saja. Dan ketika saya mencoba syntax-nya lama-lama muncul citra ini di dalam otak saya:

V Go Rust Logo

Kalo boleh saya usul nama bahasa ini lebih pas diganti jadi Gopyrust saja, sepertinya keren wkwkwkwkw

Konsep

V, bahasa yang oleh klaim pembuatnya desainnya terinspirasi banyak oleh Rust dan Go, dan yang menarik lagi V ini tidak menggunakan LLVM loh sebagai backend untuk menggenerasikan kode mesinnya, pembuatnya mengklaim V di-compile secara langsung ke kode mesin tanpa perlu membuat IL (intermediate language) LLVM dulu, wow selow banget sepertinya ini creator-nya! Tidak mainstream!

Bahasa V awal mulanya ditulis menggunakan Go, namun setelah bahasanya mulai lengkap sang pembuat menulis ulang bahasanya menggunakan V itu sendiri, ya seperti Rust yang ditulis menggunakan Rust, dan Go yang ditulis menggunakan Go, hmmmm... sepertinya ini sudah menjadi trend, baiklah...

Fakta-Fakta

Nah sekarang fakta-fakta yang mencengangkan, apa saja itu?

Pertama, proses kompilasi V sangatlah cepat, V mengkompilasi dirinya sendiri hanya dalam waktu ~0.6 detik, bahkan tidak ada 1 detik!! (di Macbook Pro 17"), Go saja yang menurutku paling cepat kompilasinya membutuhkan waktu ~1.5 menit, gila! Si pembuat mengklaim hal ini dikarenakan V langsung build ke kode mesin secara langsung, tidak perlu ada tahap intermediating dulu. Tapi saya rada ragu soalnya ketika compile, V sempat buat file *.tmp.c dulu sebelum kemudian dihapus, jadi jangan-jangan dia menggenerasikan kode C dulu dari V baru kemudian dikompilasi menggunakan C compiler seperti GCC misalnya, saya belum begitu memahami karena belum sempat diving ke dalam kodenya, mungkin suatu saat perlu diving ke sana. Apabila memang benar seperti itu berarti tidak jauh beda dong dengan bahasa nim? Wallahua'lam.

Btw, berbicara tentang waktu kompilasi, sebelum menggunakan Rust saya menggunakan Scala, Scala sudah saya gunakan production selama hampir 4 tahun di Ansvia, dan semuanya aman, namun 1 hal yang membuat saya teriritasi dengan Scala adalah proses kompilasinya yang luamaaa, alhasil setelah Rust beranjak dewasa saya memilih Rust yang memiliki waktu kompilasi lebih cepat dari Scala, oya tentu saya mempertimbangkan Go juga waktu itu, tapi GC menggangguku, mengingat saya pernah punya pengalaman buruk dengan GC baik di Scala maupun Go, otomatis Rust telah mengambil hatiku, no GC no cry.

Kedua, sintaknya itu, ya ampunn simple banget, kayag Python dan Go dikawinkan, saking simpelnya bahkan anak SD yang gak tahu caranya megang komputerpun sepertinya bisa buat program pake bahasa ini :))

Ketiga, tidak ada GC maupun Refcounter, apa?? Serius?? Ya setidaknya itu klaim pembuatnya, saya belum ngecheck lebih dalam sih bagaimana mekanismenya. Mungkin suatu saat nanti perlu diulik lebih dalam kalau sudah selow tentunya.

Keempat, mendukung hot reload!! Kamu rubah kodenya otomatis programnya akan update juga walaupun programnya sedang berjalan!! Eh yang bener!? Ini outputnya native binary kan? Kok bisa? Ya, bisa, seriusan, saya sudah nyoba, bisa! Caranya V akan membuat dua binary, satu static binary satunya dynamic library, nah ketika ada perubahan pada kode yang telah ditandai maka static binary-nya akan me-recompile dynamic library-nya dan meng-hot-swap-kan kode dynamic library-nya yang sudah jadi module static binary-nya sehingga setiap perubahannya tampak instant tanpa perlu restart programnya yang lagi jalan!! Gile lu ndro! Kayag Erlang aja.

Kelima, output binarynya sangat kecil! Beneran compiler V sendiri hanya sebesar 560KB, tidak sampai 1MB! Coba bandingin dengan Go: ~12MB dan Rust: 7.8MB, yah walaupun sih V fiturnya masih belum segambreng Go dan Rust, tapi untuk pemula ukuran segitu lumayanlah.

Keenam, dibuat oleh satu orang, ya saat artikel ini ditulis, V baru dikembangkan oleh satu orang bernama Alexander Medvednikov!! Saya bisa merasakan betapa kesepiannya orang ini.

Kelebihan

Yang saya sukai dari V:

  1. Kompilasinya yang super cepat, karena waktu sangat berharga!
  2. immutability, option types, thread safety, tidak ada null, question mark sebagai error propagator, ahhhh Rust banget... saya suka.
  3. Ada defer keyword! Ini salah satu fitur yang saya sukai di Go, kalo di Rust kita perlu implement Drop untuk kebutuhan yang sama, saya lebih suka gaya defer-nya Go daripada Rust dengan Drop-nya.
  4. Punya fitur go func() seperti goroutine-nya Go.
  5. Binary-nya yang super kecil dengan footprint yang minimal.
  6. Hot-reload! Ini yang menurut saya salah satu fitur paling killer dari V, baru kali ini saya merasa memprogram bahasa sistem yang bisa hot-reload semudah ini, koding native system serasa koding PHP.
  7. Generic! V mendukung generik seperti Rust!, hal yang membuat wagu Go adalah Go tidak mendukung generik, cara generiknya Go ngeselin, yup interface{}, come on...

Perbandingan

Secara psikologis yang akan manusia bandingkan ketika melihat apapun pada pandangan pertamanya adalah "fisik"-nya, ya tampilan fisiknya, namun karena yang sedang mau dibandingkan adalah software, bukan manusia atau gebetan, maka fisik yang saya maksud di sini adalah:

  1. Kecepatan kompilasi.
  2. Jumlah dependensi.
  3. Ukuran output binary.
  4. Output kode mesin.

Dah itu saja dulu biar simpel. Karena perbandingannya hanya sebatas fisik, maka saya tidak akan membahas tentang memory management, threading, error handling, bla-bla-bla, karena apabila saya mencoba membahas subyek itu akan otomatis artikel ini jadi buku, dan males kan kalau jadi buku dan tidak ada yang membelinya?

Adapun bahasa yang akan saya bandingkan dengan V adalah Rust dan Go, kenapa? Karena pertama: saya sudah pernah menggunakan dua-dua-nya di proyek serius cukup lama, kedua: pembuatnya sendiri terinspirasi dari dua bahasa tersebut jadi akan lebih menarik untuk melihat seberapa jauh kemiripannya, ketiga: hasil outputnya sama-sama native binary sehingga saya tidak akan membandingkan dengan Python ataupun Scala, karena sudah beda alam.

Untuk perbandingan saya akan melakukan uji coba, dan uji coba pertamanya saya adalah membuat program hello world, mengkompilasi, menjalankan, melihat jenis output binary-nya, melihat dependensinya, memeriksa ukuran binary-nya, dan yang terakhir nanti kita akan coba breakdown kode mesin-nya.

V hello world examine

Bisa dilihat, untuk program hello world kompilasinya memakan waktu 0.2 detik, dependensinya hanya ada satu /usr/lib/libSystem ini dependensi standar OSX, dan ukuran binary-nya hanya 72kb.

Coba kalau kita hapus simbol-simbol "iluminati" di dalamnya:

Mac $ strip hello_v
Mac $ du -h hello_v
 64K	hello_v

Perintah strip ini untuk menghapus simbol-simbol yang biasanya digunakan untuk mempermudah proses debugging, nah simbol-simbol itu sebenarnya tidak diperlukan untuk program bisa jalan, tapi akan sangat dibutuhkan untuk mempermudah debugging. Begitu simbol-simbol iluminati ini saya bersihkan, berat badannya berhasil turun 8Kb, not bad...

Coba kalau kita kompilasi dalam mode release, atau V bilang prod:

Mac $ v -prod hello_v.v
Mac $ du -h hello_v
 64K	hello_v
Mac $ strip hello_v
Mac $ du -h hello_v
 56K	hello_v

Di prod mode, berat badan binary-nya jadi lebih enteng yakni 64Kb, dan hanya 56Kb setelah dihilangkan simbol-simbol iluminati-nya.

Catatan: Dalam beberapa ujicoba saya sempat beberapa kali menemukan output binary-nya malah rusak ketika dikompilasi di mode prod dan tidak bisa dijalankan.

Sekarang coba kita bandingkan dengan Rust:

Rust vs V basic

Hmmm... untuk skala program hello world, Rust masih lebih cepat kompilasinya dibanding V yakni 0.16 detik, namun dependensinya ternyata tidak hanya libSystem ada libresolv juga! Untuk apa coba libresolv disematkan pada program hello world? Dan sepertinya itu hanya terjadi di OSX saja issue 46797.

Sementara ukuran binary-nya 272kb, 200kb lebih besar dari V punya. Sekarang coba kita bersihkan simbol-simbol iluminati-nya:

Mac $ strip hello_rust
Mac $ du -h hello_rust
176K	hello_rust

Dan berat badannya berhasil turun 96Kb, yah lumayan lah...

Mungkin karena stdlib-nya Rust terlalu besar ya? Sekarang coba kalau saya buat yang Rust murni tanpa menggunakan stdlib a.k.a bare metal mode Rust:

Rust no stdlib bare metal mode

Di sini saya minta bantuan Cargo buat setup environment-nya biar tidak terlalu banyak dan panjang nulis parameter-parameter tambahan pada rustc.

Proses kompilasinya jadi lebih lama yakni 1.6 detik, hal ini dipengaruhi oleh adanya dependensi libc yang perlu di-lookup terlebih dahulu, dependensi libc ini saya tambahkan karena saya butuh memanggil fungsi _printf yang ada di libc tersebut, semenjak saya tidak bisa menggunakan println! lagi tanpa stdlib-nya Rust.

Tapi lihat, sudah tidak ada libresolv lagi di dependensinya, ini sudah sama dengan yang V punya, dan yang lebih mantapnya lagi ukurannya jadi hanya 12kb! Jauh lebih kecil 60kb dari yang V punya.

Hmmm.... jadi penasaran, sebenarnya apa saja sih yang ditulis sama V ke binary program sesederhana hello world?, mari kita bongkar kode mesinnya!! Reverse engineering mode ON

Mac $ otool -tvV hello_v | wc -l
    10283

Bisa dilihat V menuliskan sebanyak ~10283 baris kode mesin pada output binary-nya, isinya apa saja?

V hello world assembly output

Bentar itu baru fungsi main-nya, lengkapnya ada di sini: Full disassembled hello world V

Bisa dilihat dari hasil disassembly-nya, ternyata V menyematkan banyak sekali kode yang tidak digunakan seperti _strings__levenshtein_distance, itu fungsi untuk apa coba di program hello world? Itu gak kepake, tapi tetep aja disematkan.

Sekarang coba kita lihat hasil apa yang dituliskan Rust pada binary-nya tanpa stdlib:

Hello Rust disassembly output

Btw, itu sudah semuanya, dan jumlah baris kode mesinnya adalah:

Mac $ otool -tvV target/release/hello_rust | wc -l
      12

Ya, hanya 12 baris plus 3 baris non assembly code yang ikut kehitung sama wc -l

Dan apabila Rust dengan stdlib-nya:

Mac $ otool -tvV target/release/hello_rust | wc -l
   32001

Jadi membengkak menjadi ~32001, lebih besar ~21000 baris dari V.

Sekarang saatnya kita bandingkan dengan Go:

Hello Go compile time and output

Go butuh waktu 0.27 detik untuk kompilasi program hello world, tidak jauh beda dengan V, dependensi hanya ada satu libSystem ini standar, lalu outputnya binary-nya 1.9MB! Wah kok gemuk banget ya? Oh mungkin karena simbol dan debug info-nya masih ikut masuk, sayangnya Go tidak mengenal istilah debug dan release mode, by default semua simbol dan debug info ikut disertakan di output binary-nya, eh tapi kita bisa menghapus simbol dan debug info-nya loh, menggunakan parameter -ldflags "-s -w", yuk kita coba:

Mac $ time go build -ldflags "-s -w" hello_go.go

real	0m0.221s
user	0m0.208s
sys	0m0.123s
Mac $ du -h hello_go
1.5M	hello_go

Yup berhasil menurunkan berat badannya, tapi hanya mampu memangkas sebesar 0.4Mb saja :(

Itu belum cukup! Mari kita bersihkan simbol-simbol iluminati di dalamnya!

Mac $ strip hello_go
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: error: symbols referenced by indirect symbol table entries that can't be stripped in: /private/tmp/workarea/hello_go
_exit
_open
_close
_read
_write
_setitimer
_madvise
...

Waduh sayangnya binary Go tidak bisa di-strip, hmmmm.... entah apa yang merasuki mu Go..., yang pasti bukan simbol iluminati ini.

Sekarang kita lihat berapa baris kode mesin yang dituliskan:

Mac $ otool -tvV hello_go | wc -l
  138276

Buset, banyak banget ~138276 LoC man!! Saking banyaknya sampai saya males cari main entrypoint-nya untuk diposting di sini.

Breakdown Kode Mesin

Sebenarnya saya sungguh males untuk melakukan ini, tapi semenjak sang creator mengatakan dia menulis kode mesinnya secara langsung single handedly saya jadi penasaran, "mantap jiwa ini orang" selow banget sampai sempat bikin instruksi mesinnya sendiri pasti berat tuh karena dia harus deal dengan banyak sekali arsitektur mesin yang berbeda-beda dan mengabaikan banyak wanita.

U No LLVM?

Untuk keperluan ini, saya akan menulis algoritma Fibonacci secara rekursif:

V:

fn fib(n int) int {
    if n <= 1 {
        return n
    }else{
        return fib(n-1) + fib(n-2)
    }
}

Rust:

fn fib(n:i32) -> i32 {
    if n <= 1 {
        n
    }else{
        fib(n-1) + fib(n-2)
    }
}

Go:

func fib(n int) int {
    if n <= 1 {
        return n
    }else{
        return fib(n-1) + fib(n-2)
    }
}

Dan berikut adalah hasil kompilasi setelah menjadi kode mesin (assembly) dalam syntax AT&T:

V:

V Fibonacci

Hasil disassembly pada fungsi fib yang ditulis menggunakan bahasa V didapatkan 24 baris rutin assembly, dilihat dari polanya pada bagian prolog dan epilog kok seperti tidak asing ya, ini mirip banget dengan hasil kompilasi kode C menggunakan gcc (C code convention)? Ditambah lagi bagian-bagian yang saya kasih tanda warna kuning misalnya pada bagian 01, movl %edi, -0x8(%rbp) adalah perintah untuk memasukkan parameter ke function stack memory lalu cmpl $0x1, -0x8(%rbp) adalah membandingkan nilai di dalam function stack memory dengan angka 1, padahal baru diambil dari register edi, kenapa tidak langsung saja sih cmpl $0x1, %edi gitu? Jadi langsung komparasi dari register tidak perlu ke stack dulu bukannya akan lebih cepat? Atau jangan-jangan dia memang sengaja untuk mempermudah debugger dalam menginspeksi nilai dalam sebuah variable? Bisa juga sih, tapi cara itu adalah cara gcc ketika dikompilasi pada mode optimasi level 0 (-O0) atau debug mode, karena itu akan membantu debugger untuk me-lookup nilai pada suatu variable.

Selanjutnya Rust:

Rust Fibonacci Disassembly

Hasil disassembly pada fungsi fib di Rust yang saya kompilasi di release mode ini tampak seperti hasil kompilasi kode C menggunakan gcc dengan optimasi level 3 (-O3). V dan Rust ada beberapa kemiripan, pertama: dalam mengumpankan parameter pertama ke dalam fungsi mereka menggunakan register edi ya ini normal sih di mesin 64bit. Kedua: pengembaliannya ditaruh di register eax. Kemudian perbedaannya: V mengalokasikan stack sebesar 16 bytes, sementara Rust tidak ada alokasi memory untuk stack, hanya menggunakan register, ya wajar sih V perlu memory untuk lempar-lemparan nilai melalui variable di alamat stack -0x8(%rbp), btw bagi yang masih awam dengan assembly, rbp itu register yang selalu mengarah ke base pointer pada stack, dan biasanya ditemani rsp yang selalu mengarah ke alamat stack terkini, ya karena setiap pertambahan/pengurangan data pada stack akan otomatis merubah nilai rsp, mereka berdua rbp dan rsp adalah sahabat sejati sejak kecil, sejak masih bp dan sp (16bit) lalu kemudian ebp dan esp (32bit) , dan kini telah menjadi rbp dan rsp (64bit).

Selanjutnya Go:

Go Fibonacci Disassembly

Hasil disassembly pada fungsi fib di Go ini menghasilkan 30 baris rutin assembly, lebih banyak dari V dan Rust. Dan juga, Go berbeda dengan yang lainnya, dia tidak mengikuti konvensi C dalam penulisan fungsinya, dia punya gaya sendiri, coba lihat pada kode yang saya tandai warna kuning dengan nomor 01, kalau di V dan Rust di situ adalah tempat prolog, namun di Go sebelum prolog dia menaruh kode tambahan di sana, kode apakah itu? Mari kita breakdown:

movq %gs:0x30, %rcx

Itu adalah perintah untuk memuat nilai dari alamat %gs:0x30 yang merupakan alamat dari TLS (Thread Local Storage) ke register %rcx, nilai tersebut merupakan alamat atau pointer yang mengarah pada G Structure pada Go Runtime, lalu:

cmpq 0x10(%rcx), %rsp

Membandingkan nilai di dalam G Structure yang terletak di offset 16 (0x10 adalah hexadecimal dari 16). Ini adalah merupakan rutin pengecekan untuk memeriksa apakah memory stack perlu ditambah atau tidak, apabila perlu maka akan dialokasikan lagi, lihat pada kode selanjutnya jbe 0x1092f79 itu artinya "jump if bellow or equal to 0x1092f79", sekarang lihat pada baris 0x1092f79 yang sudah saya tandai garis bawah warna orange, ya apabila memory-nya masih kurang dia akan melompat ke alamat 0x1092f79 yang mana berisi pemanggilan fungsi runtime.morestack_noctxt nah fungsi itu yang bertanggung jawab untuk mengalokasikan stack tambahan dan akan terus dilakukan sampai kebutuhan memory-nya terpenuhi, lihat kode bawahnya jmp main.fib itu akan lompat lagi ke awal kode fungsi, ya ini adalah loop bersyarat.

Dari sini maka perlu diketahui bahwa, Go tidak seperti V yang alokasi stack-nya dilakukan secara statis seperti ini:

subq	$0x10, %rsp

Go mengalokasikan stack-nya secara dinamis, hal ini karena fungsi pada Go awalnya hanya menggunakan memory untuk stack yang kecil, namun kemudian akan bertambah seiring dengan kebutuhan, untuk apa sebenarnya ini? Bukannya ini akan menambah overhead pada runtime-nya? Bukannya ini bisa memperlambat? Iya memang benar, tapi dengan adanya ini, kamu jadi bisa menggunakan fitur killer andalan Go yang tidak ada di Rust:

go fib(10)

Ya, goroutine, karena untuk mendukung fitur itu.

Kode yang saya tandai kotak garis kuning tadi itu dibutuhkan untuk membentuk context memory pada goroutine yang disimpan referensinya di TLS agar apa? Agar tidak terjadi benturan context di thread satu dengan yang lainnya. Karena TLS sifatnya lokal untuk setiap thread. Eh tapi kan saya tidak akan jalankan fungsi fib secara concurrent, apakah kode "pembesar" stack ini tetap akan ada di setiap fungsi Go walaupun tidak pernah akan saya gunakan untuk operasi asynchronous? Ya, sayangnya semua fungsi Go akan memiliki kode "pembesar" stack ini.

Eh tapi V juga kan punya fitur killer seperti Go ini, tapi kok fungsi di V gak ada kode "pembesar" stack-nya? Ya memang benar, itu karena V masih menggunakan native thread untuk setiap go yang dieksekusi, berbeda dengan Go yang menggunakan "mini-thread" yang jauh lebih murah.

Perbedaan lainnya terletak pada cara mengumpankan parameter-nya, Go menggunakan stack untuk umpan parameter-nya, sementara V dan Rust menggunakan register, tentu lebih performan menggunakan register dibanding stack dalam mengumpankan parameter, style umpan parameter melalui stack itu gaya jadul di era mesin 32bit, dimana register prosesor masih sedikit jumlahnya, sejak era 64bit rata-rata kompiler menggunakan register untuk umpan parameter-nya. Lalu pertanyaannya mengapa Go tidak menggunakan register saja? Karena Go tidak bisa melakukannya, ini semua demi goroutine, hanya native thread yang bisa memiliki konteks pada register. Sementara goroutine Go bukan native thread, tapi "mini-thread" yang dijalankan di native thread, sehingga Go harus mengakalinya dengan menggunakan stack. Begitu juga dengan tempat nilai pengembaliannya, kalau V dan Rust menggunakan register eax untuk tempat nilai pengembaliannya maka Go lagi-lagi harus menggunakan stack. Bayangkan kalau Go tetep keukeuh menggunakan register, apa yang terjadi? Akan terjadi konflik horizontal dan perang saudara antar goroutine dalam satu native thread!.

Nah sekarang sudah lebih jelaskan? Kenapa Go masih lebih lambat dibanding Rust dan C? Karena salah satunya adalah adanya kode "pembesar" stack ini. Ya walaupun tentu masih ada faktor lainnya juga seperti GC, dll.

Kekurangan

Penilaian ini akan sangat subjektif, mengingat saya hanya akan mengkritisi bagian-bagian yang menurut saya tidak optimal untuk kebutuhan kerja saya.

Hal yang tidak saya sukai dari V:

  1. Dukungan fungsional yang belum luas. Padahal saya sudah menjadi pecandu fungsional, hidup terasa merana ketika kita tidak menemukan cara tercepat dan efektif dalam memecahkan masalah programming sederhana.
  2. Masih beberapa kali mendapatkan error segmentation fault tanpa ada kejelasan. Ini asli jengkelin, karena saya bandinginnya sama Rust sih, sejak pertama menggunakan Rust sampai sekarang belum pernah ketemu sama segfault. Ya saya tidak adil membandingkan bahasa kemarin sore dengan bahasa yang sudah 9 tahun umurnya, eh tapi saya sudah mulai pakai Rust sejak awal kemunculannya loh.
  3. Gaya orientasi objek yang "gak enak", V mengadopsi gaya Go dalam mengimplementasikan konsep orientasi objek, jujur saya lebih suka gayanya Rust untuk masalah ini.
  4. Tidak ada macro, terus terang saya sendiri tidak suka macro ala C/C++ karena dapat mengacaukan kode sehingga susah dipahami, tapi saya suka konsep macro-nya Rust yang higinis dan procedural macro yang bisa memperkaya fitur dengan cara memanipulasi AST (Abstract Syntax Tree) saat compile time.

Sebenarnya masih ada yang lainnya, masih buanyak banget apabila termasuk juga ke masalah community support, documentation, troubleshooting, optimasi dll. Tapi saya tidak akan membahas hal itu, karena subyek itu masih terlalu dini untuk dinilai --baca: hakimi--

V Bahasa Ideal?

Menurut pembuatnya bahasa ini masih di kualitas alpha, artinya masih banyak sekali kekurangannya, sehingga belum ideal untuk membuat proyek yang serius (production). Saya sendiri tidak akan menggunakan bahasa ini, kecuali hanya untuk main-main saja atau untuk membuat tool-tool sederhana yang akan membantu proses DevOps, setidaknya untuk saat ini, ya kita tidak tahu apa yang akan terjadi 5 tahun lagi dengan bahasa ini, bisa jadi bahasa ini akan jadi superstar di 5 tahun mendatang, who knows?

Saya masih akan menggunakan Rust untuk proyek-proyek yang serius, dan sejauh ini tidak ada keluhan apapun kecuali hanya di masalah compile time saja, itupun masih bisa dihadapi i7 dengan SSD. Rust saat ini masih yang paling ideal untuk kebutuhan profesional saya. Jadi belum ada kepikiran sama sekali untuk pindah ke lain hati.

Bagi yang tertarik untuk mempelajari bahasa V, bisa kunjungi website resminya di https://vlang.io.

Terakhir, mohon maaf apabila ada yang salah itu semata karena saya lalai, apabila benar itu karena Allah swt.

[] Robin Sy.

Twitter: @anvie

mantab om robin

Menarik ini om. Jadi pengen nyobain. :D