[deleted]
My favorite Rust function
81–90 of 197 posts
Re: My favorite Rust function
#82> or making the language unacceptably crippled like Go Gotta say, I lost a lot of respect for the author at this point. It’s not like I don’t love Rust - quite the contrary - but if the only takeaway from Go for you is that it is “unacceptably crippled” then I feel you have missed a lot of insight. Go has been one of my languages of choice for over half a decade now, and for good reason.
It may be an unnecessary dig, but the author may indeed be familiar with Go and still think it's unacceptably crippled for all their use cases. The whole post is just their opinion.
In my anecdotal experience, the type of programmers that evangelize and talk shit about programming languages tend to be on the less informed side of the knowledge spectrum.
Re: My favorite Rust function
#83Gotta admit, that really is a cute example. However, I was a bit surprised when the author described Go as "unacceptably crippled." What is he referring to?
Interesting how developer views can differ. Someone describes Go as "unacceptably crippled" while Uber engineering has 1500 microservices written in Go, making it their primary language. https://news.ycombinator.com/item?id=21226347
Popularity ≠ Quality.
Re: My favorite Rust function
#84Earlier quoted context omitted.
It may be an unnecessary dig, but the author may indeed be familiar with Go and still think it's unacceptably crippled for all their use cases. The whole post is just their opinion.
Sure, and my opinion is that this is a very shallow takeaway. My whole comment is just my opinion.
It is crippled admittedly by the authors themselves. The error checking pattern, no generics etc. are all to keep it "simple" yet are things most other programming languages have. Have you used Rust ? The borrow checker makes a lot of sense.
Re: My favorite Rust function
#85> Now this might seem like a hack, but it really is not. Most languages would either ask the programmers to explicitly call free() or implicitly call a magic runtime.deallocate() within a complex garbage collector.
The compiler actually implicitly adds drop glue to all dropped variables!
Re: My favorite Rust function
#86For me, rust is still love & hate, even after 1 year of half-time (most of the free time I have) hacking. It's a wonderful language but there are still some PITAs. For example you can't initialize some const x: SomeStruct with a function call. Also, zero-cost abstraction is likely the biggest bullshit I've ever heard, there is a lot of cost and there's also a lot of waiting for compiler if you're using cargo packages…
I hear you. I'm really hoping that Swift improves over the next few years. It seems to be in a great sweet spot with many of the modern language features of Rust (optional / result types, parametric enums, try, generics, static compilation, etc). But it also has the ergonomics of a language like Go thats explicitly designed for writing practical code and just getting work done.
Swift is still missing decent async / await support, generators and promises. Some of this stuff can be written by library authors, but doing so fragments the ecosystem. Its also still harder than it should be to write & run swift code on non-mac platforms. And its also not as fast as it could be. I've heard some reports of swift programs spending 60% of their time incrementing and decrementing reference counts. Apparently optimizations are coming. I can't wait - its my favorite of the current crop of new languages. I think it strikes a nice balance between being fancy and being easy of use. But it really needs some more love before its quite ready for me to use it as a daily workhorse for http servers and games.
Re: My favorite Rust function
#87Earlier quoted context omitted.
std::move's implementation not quite as elegant, though (this is from the GCC source): template constexpr typename std::remove_reference ::type&& move(_Tp&& __t) noexcept { return static_cast ::type&&>(__t); }
It’s a bit ugly because the standard library functions are replete with underscores, and of course it isn’t empty. But I still think it’s quite surprising, as most people would think it actually does some sort of semantic “move”.
> It’s a bit ugly because the standard library functions are replete with underscores, and of course it isn’t empty.
I'll be honest, neither of those are my top issue with that in terms of why I think it's ugly.
Re: My favorite Rust function
#88Gotta admit, that really is a cute example. However, I was a bit surprised when the author described Go as "unacceptably crippled." What is he referring to?
Interesting how developer views can differ. Someone describes Go as "unacceptably crippled" while Uber engineering has 1500 microservices written in Go, making it their primary language. https://news.ycombinator.com/item?id=21226347
These are orthogonal points. Linux Kernel is all in C and possibly drives the world. Doesn't mean it's safe and amazing.
Re: My favorite Rust function
#89Earlier quoted context omitted.
Disclaimer: I’ve never tried to write Go. Memory management is not the only type of “little detail.” For instance, rust provides common collection operations (filer, map, find…) in the standard library. In go (AFIAK), you need to hand-write a loop for each. IMO, the rust version is takes much less mental bandwidth to write and understand.
rust provides common collection operations (filer, map, find…) Those are just standard functional methods available in most languages. Go indeed is noteworthy for it's lack of features.
Yes, of course. I just described it as a Rust feature because that was the comparison being made in the thread.
Re: My favorite Rust function
#90Earlier quoted context omitted.
It may be an unnecessary dig, but the author may indeed be familiar with Go and still think it's unacceptably crippled for all their use cases. The whole post is just their opinion.
Sure, and my opinion is that this is a very shallow takeaway. My whole comment is just my opinion.
> if the only takeaway from Go for you is that it is “unacceptably crippled” then I feel you have missed a lot of insight.
Um, the whole point of Go was to be "opinionated and acceptably crippled". That's why the creators built it the way they did. Go has more than a few things where "Me, but not for thee" rules--the compiler can do X but you cannot. If you find that is an acceptable tradeoff for the other features of Go, great!
Lots of modern languages, however, are trying to go the other way. They are trying to give the programmer every bit of power that the library/compiler programmers have. This has its own failure modes that you may find unacceptable. That's fine too.
I personally dislike the Rust vs Go discussions. Those two languages in particular really don't have domain overlap and are like comparing apples to screws.