Live data from Hacker News

My favorite Rust function

blog.jabid.in

101–110 of 197 posts

Re: My favorite Rust function

#101

Earlier quoted context omitted.

FWIW, that won't compile because std::mem::drop requires ownership of the object being passed; your code is trying to pass a reference instead.

This code compiles just fine. It doesn't do anything since immutable references are Copy, and so dropping them doesn't do anything. https://play.rust-lang.org/?version=stable&mode=debug&editio...

Oh right, I forgot about the interaction with generics in this case. Semantically, I suppose it's creating and dropping a reference 4 times.

Re: My favorite Rust function

#102
post #72
post #62

Earlier quoted context omitted.

> 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. While someone else is right that "zero-cost" refers to runtime cost rather than compilation cost, dependencies are the biggest problem. The program `spotifyd` takes over an hour to compile on my X200 laptop. This is, for reference, the same…

An X200 is also an ancient machine. Do you value your own time so little? Clearly you are annoyed by the compile times? You can get a $200 CPU that will blast through a kernel compile in 3 minutes.

> An X200 is also an ancient machine. Do you value your own time so little? Clearly you are annoyed by the compile times?

I value my security first and foremost. My X200 has zero binary blobs running on the machine, it also has several other properties that I appreciate.

> You can get a $200 CPU that will blast through a kernel compile in 3 minutes.

That assumes that I even have the money to afford that. Not all of us live in silicon valley.

Re: My favorite Rust function

#103
post #13
post #9

Earlier quoted context omitted.

Rust has the exact same semantics there. Drop is useful when you need to explicitly notate that a value should end its life early.

void drop(unique_ptr && x) {} Would do the same in C++ for values held by unique_ptr: take ownership of the pointer and then free it.

It would have to be

void drop(std::unique_ptr x) {}

Or, you know, just call someX.reset(); or do someX = nullptr;. The drop call would be way noisier: drop(std::move(someX));

Re: My favorite Rust function

#104
post #62

Earlier quoted context omitted.

> 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. While someone else is right that "zero-cost" refers to runtime cost rather than compilation cost, dependencies are the biggest problem. The program `spotifyd` takes over an hour to compile on my X200 laptop. This is, for reference, the same…

I've also heard that Rust compilation is slow, so I put off learning it for a while. I finally dug in deep recently and, to be honest, I don't understand the issue. Rust compilation is quite fast in my experience. Your comment was the first I've heard of spotifyd, so I downloaded it from github and ran "cargo build". I spent 3 minutes figuring out that I needed to install the "libasound2-dev" package, then I spent le…

> Maybe you're referring to --release compilation?

Indeed.

Re: My favorite Rust function

#105
post #93

Earlier quoted context omitted.

These are orthogonal points. Linux Kernel is all in C and possibly drives the world. Doesn't mean it's safe and amazing.

C was the only sensible choice back then. Uber on the other hand has many languages available yet picked Go. So they certainly don't think it is "unacceptably crippled".

Many teams just start with what they know and then that sets the tone. It no way means that the language is better. Amazon uses Java. Does that mean it's better than Go ? Popularity paints an incomplete picture at best.

Re: My favorite Rust function

#106
post #22

> 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.

> > or making the language unacceptably crippled like Go

> ... if the only takeaway from Go for you is that it is “unacceptably crippled” then I feel you have missed a lot of insight.

Perhaps the author used a poor choice of words and instead could have phrased their intent along the lines of:

Go lacks the semantic density needed to express solutions in both a concise and consistent manner.

Were this the case, it would be hard to disagree as Go does, indeed, lack linguistic capabilities present in other programming languages which enable developers to encode system constraints within the language itself. Some might see this as a benefit, but I do not. YMMV.

A similar philosophy of "keep the language dirt-simple so anyone can code in it" was a driving force behind Java (the language) and JavaScript. What people have discovered is that when a programming language does not assist in expressing intrinsic problem complexity explicitly, it becomes implicitly intertwined within the source itself.

Re: My favorite Rust function

#107
post #93

Earlier quoted context omitted.

C was the only sensible choice back then. Uber on the other hand has many languages available yet picked Go. So they certainly don't think it is "unacceptably crippled".

Many teams just start with what they know and then that sets the tone. It no way means that the language is better. Amazon uses Java. Does that mean it's better than Go ? Popularity paints an incomplete picture at best.

Except that Uber started with JavaScript and Python.

Switching to Go was an educated decision. Not a continuation of what was there.

https://www.quora.com/What-is-the-technology-stack-behind-Ub...

Re: My favorite Rust function

#108
post #22

> 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.

Go is crippled. I know you disagree, but I can tell you why you disagree and why you are wrong. Simply put, you do not have enough knowledge to know why GO is crippled.

Allow me to elucidate.. Imagine that you never knew about the concept of a negative number. You only knew about natural numbers. And for 5 years that's all you worked with... positive numbers. This does not mean you are inn-effective working with your positive numbers it does not say anything about your abilities at working with Natural numbers, you could be a an expert natural number mathematician.

However it does say that you are missing knowledge about numbers and that your knowledge is in a way (crippled)

Go is exactly this. Go is missing some very basic primitives that should be intrinsic to modern type systems in programming. If you had knowledge of "negative numbers" this would look like a gaping hole within GO's "number system." However if you have no knowledge of this, you would be completely unaware of the gaping hole and you could be unaware of it for half a decade. You may even get offended when someone comments on your knowledge being "crippled"

Go is missing:

1. Enumerations... or some way of representing elements of a set within a type system. This is a fundamental concept needed to create a type. Unless you played with languages like Agda or Idris it's hard to see why enumerations are so fundamental and so important.

2. Sum types (while having product types) Go has structs but doesn't have Variant types which is a huge gaping hole in the type system as it uses products to return errors.

3. Recursive types.

4. Parametric Polymorphism (probably the most well known missing feature that is by many considered unneeded)

You may not have fully understood all the concepts mentioned so I'm going to illustrate a very common problem go has that other modern typed languages don't have.

The GO type system is not powerful enough to hold a JSON type because it is missing fundamental primitives of types.

In python and javascript and ruby I can parse JSON and put it in a variable. In GOLANG I have to guess all the possible permutations of the incoming JSON type in order to hold it in a variable. This is 100% because GO is missing properties 1, 2 and 3 from above.

There is no this in GOLANG:

   x := parseJSON("[1,2,3]")
But there is in practically every other modern language.

Re: My favorite Rust function

#110
post #93

Earlier quoted context omitted.

These are orthogonal points. Linux Kernel is all in C and possibly drives the world. Doesn't mean it's safe and amazing.

C was the only sensible choice back then. Uber on the other hand has many languages available yet picked Go. So they certainly don't think it is "unacceptably crippled".

There is an implicit "for my use-case" following "unacceptably crippled". So, go is not "unacceptably crippled" for the use case of creating a ton of small, simple, easily maintainable services at Uber, but it might be "unacceptably crippled" for the use case of having fun with type systems, or whatever the author was interested in at the time they were considering go as an option.
Post reply on HN