Hacker News Reader

Hacker News

Comment by dijit | Hacker News Reader

Parent Full thread

dijit

.connect() or connection.new() like everything else.

Python: https://wiki.python.org/moin/TcpCommunication#CA-b22bc303d6d...

Ruby: https://ruby-doc.org/stdlib-2.5.1/libdoc/socket/rdoc/TCPSock...

Rust: https://doc.rust-lang.org/std/net/struct.TcpStream.html

Julia: https://docs.julialang.org/en/v1/manual/networking-and-strea...

C++: https://github.com/KMakowsky/Socket.cpp/blob/master/Socket.c...

Win32 C: https://docs.microsoft.com/en-us/windows/win32/api/Winsock2/...

Linux C: http://man7.org/linux/man-pages/man2/connect.2.html

Swift: https://github.com/apple/swift-nio/blob/master/Sources/NIOEc...

Java: https://docs.oracle.com/javase/7/docs/api/java/net/Socket.ht...

Javascript: https://gist.github.com/tedmiston/5935757#file-nodejs-tcp-ex...

Anyway, it's not about being demoralised, it just doesn't "spark joy". :)

View on HN

Go follows the Plan9 system call name instead of the UNIX one. Dial is much more powerful than the UNIX dance of "getaddrinfo"+struct sockaddr init+connect(2).

It might not seem much (and higher level languages usually abstract away the craziness that UNIX sockets are in C), but that's what the OS still gives you in 2020...

Plan9's "Dial" is definitely a product of it's time, literally meaning to "Dial" a phone.

More information here: relevant man entry: https://www.unix.com/man-page/plan9/2/dial/

It specifically mentions making a call.

The example even dials "kremvax". Usenet over AX.25 from the 80s. Pretty sure that is _actual_ dialling.

But, I'm curious as to why Go's "Dial" is more powerful than a standard connection in any other language.

Plan9's dial is derived from OSI approach of separating service and protocol (aka implementation), with name service as first-party component (BSD Sockets have it stapled over and it hurts).

The example with calling kremvax over datakit specifically goes to show-off that all that specifies datakit usage is the "dk" string - nothing else.

Similarly with XTI (and other OSI-oriented network APIs), what you are telling OS is "I want to have a stream oriented connection with graceful close, to service Y on host X", and you don't have to care at all whether it will be IPv4, IPv6, TUBA, CLNS over Ethernet, or direct serial modem exchange using HDLC.

Go doesn't have all of that flexibility because it works from userspace, but it reuses the "service, not implementation detail" approach and lets you concentrate on human-readable domain names and service names instead of providing a maze of "hardcoded IP" issues.

Plan 9's dial() interface is implemented in a user land library. In terms of the interfaces provided by the kernel, connecting a socket is anything but simple in Plan 9. See https://9p.io/sources/plan9/sys/src/libc/9sys/dial.c

The reason no standard interface has replaced getaddrinfo + socket + connect is probably because it's just barely simple enough for common usage in C, and C was never the language you turned to when you wanted to write something short and sweet--that's why Unix environments have always hosted a myriad of other languages. If initializing a network connection were as complex as in Plan 9, doubtless Unix would have provided a more succinct libc interface for the common case

The BSD Sockets API is also close to the simplest possible interface for supporting all the various address and socket option combinations that are possible. (The kernel provides mechanism, not policy.) So even if POSIX, Linux, or whatever included a better standard interface for initializing a connection, it would have to be in addition to the BSD Sockets API (or equivalent).

BSD Sockets are infamous for being significant issue in using anything other than IPv4 (getaddrinfo is copied over from XTI, aka Streams-related "evil" API).

They are literally a low-level API that happened to be part of IPv4-only stack because DoD had short deadline to get IPv4 ported to VAX and other new Unix machines.

And OS should provide a policy when it comes to networking, otherwise you end up with never ending story of working around other's software to implement them.

Reply on news.ycombinator.com