That said I know a lot of folks really dig it and think it's a breath of fresh air; more power to em'.
The package manager is a joy to work with and supports multiple versions of tools.
The edition mechanism allows the language not to be dragged down by old cruft.
The proc macros make it possible to have insanely reusable libraries, like serde.
The normal macros are part of the AST so you don't make stupid mistakes that are hard to trace.
Rust is just so good. But I think it's only obvious if you've worked with C++. Most of this doesn't seem special coming from C#. Except the performance that is possible.
The borrow checker might cost you a few minutes, but it can save you days or even weeks of debugging, and maybe it will save lives some day when Rust makes it to safety critical applications.
One thing that did bother me for a long time was RLS auto complete, which was just really slow and useless. This has been fixed with the advent of rust analyzer.
Like, I find it extremely pleasing to write any kind of prototype in Rust and make things work. I guess once you have borrow checker embedded in your head and your newly written code compiles without errors most of the time, it becomes more pleasing, but that's not even the main point. There's something about it that's "just right" for me, not anything in particular but a multitude of various things.
However, this sense is reducing every-time I see an example of some idiomatic Rust code. I appreciate that they've addressed a lot of C++ pain points.
1. Traits are awesome. (Simon Brand: How Rust gets polymorphism right - https://www.youtube.com/watch?v=VSlBhAOLtFA)
2. The lazy pipeline styled programming is idiomatic and produces optimal assembly. (Ranges in C++20 )
3. Extremely powerful enums. Straight out of functional langs.
These are only a few of the things top of my mind but it makes me appreciate Rust more and more.
It's crazy, because this is that part I love the most. Both Rust and Elm just blow my mind every time the compilers not only throw up something I never would've noticed, but even tell me how to fix it! It's crazy to think how far we've come, and it still makes me giddy with excitement every time I see it.
These days I'm working again with Rust to add a new feature to a project after not touching it for months, and that feeling of "oh dear god this is awful" that I felt when I was starting out with the language was back again. However, once everything clicked in, with the compiler telling me exactly what was wrong with the code, and the project compiling which meant that I could be damn sure that the code I wrote would work with little to no risk of breaking in unexpected ways... that sure did spark joy.
Just my experience.
I've never understood this. Why continue taking "awful" puffs? Why not just use/ingest something else that doesn't feel awful?
And yes, I get that languages are extremely subjective and some folks find it joyful not awful. Good for them. I'm glad they found happy. For everyone else though...
I'm primarily a C# dev, which normally has a pretty happy compiler.
But I've started playing with Websharper (Translates C#/F# code to JS.) One nice thing about the library is that once you understand the basics of composition, your JS -will- work as long as the compiler doesn't barf on what you did.
But, it has the drawback of seeing more errors from the compiler itself. While at first it was frustrating, I realized that the time I spent dealing with the compiler errors was still less time than I would have spent troubleshooting my own handwritten JS.
I hope it's not the tone, but rather how nitpicky the language feels, but the target is for most of the seemingly pedantic or arbitrary restrictions to give you guidance on what needs to be done instead.
If I was working on something where the best alternative is C++, I'd probably feel different. Right tool for the job and all of that.
Also a fairly good development experience (compared to C++)
But I find that Go does not spark joy for me. ('.Dial'?!, first character case denotes public/private D:).
I guess that it is very subjective.
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". :)
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...
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.
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.
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).
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.