Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My favorite Rust function

blog.jabid.in

Post reply on HN
Print view View original

161–170 of 197 posts

Re: My favorite Rust function

#161

Post by kd5bjo »

Too wrote: post #148
hinkley wrote: post #25

Do variables go out of scope after last use or when the function exits? I could see the former evolving into the language if it’s not already the default behavior. In which case there’s only one situation where I could see this useful, and that’s when you are building a large object to replace an old one. The semantics of foo = buildGiantBoject(); In most languages is that foo exists until reassigned. When the object…

Not sure how Rust mutexes work but in c++ that wouldn't work. Obvious first example is std::lock_guard which is implemented by locking in constructor and unlocking in destructor. The variable itself never has any "use", it's just created and held alive as a dummy to denote the locking scope. Now actually this is a quite nasty object with implicit global side effects which you should avoid in the first place, but for…

Rust’s mutex guard has similar semantics, but acts as a amart pointer to the data in the mutex: if you let the guard drop, you no longer have access to the shared data.

Re: My favorite Rust function

#162

Post by Gene_Parmesan »

ErotemeObelus wrote: post #126
AdieuToLogic wrote: post #106

Earlier quoted context omitted.

> > 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 wou…

I think it's a syntax problem. ASCII doesn't have enough bracket characters to simply & clearly represent necessary language features. So it's harder for an intelligent human to sort and categorize these aspects. Pre-generics Java is about the appropriate amount of language complexity for our current lingua franca

I will gladly trade a little bit more language complexity if it means the complexity of the code that I write using that language is simpler.

Re: My favorite Rust function

#163

Post by EdwardDiego »

jchw wrote: 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.

Crippled is a good way of describing "use a map[T]struct{} when you need a set of T" in my mind.

Re: My favorite Rust function

#164

Post by EdwardDiego »

ErotemeObelus wrote: post #126
AdieuToLogic wrote: post #106

Earlier quoted context omitted.

> > 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 wou…

I think it's a syntax problem. ASCII doesn't have enough bracket characters to simply & clearly represent necessary language features. So it's harder for an intelligent human to sort and categorize these aspects. Pre-generics Java is about the appropriate amount of language complexity for our current lingua franca

Generics don't make Java that much more complex for your workaday Java coding.

Re: My favorite Rust function

#165

Post by EdwardDiego »

baby wrote: post #97
jchw wrote: 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.

I work with Rust only these days, it’s really an awesome language and I wish everyone working with system languages would switch to Rust. Yet, I find Golang to be a much clearer language to read (and I read a shit ton of code). I hope they don’t add generics, but I wish they would options, results, sum types in general, redeclaring variables, the ? Operator, etc.

Interesting, I've been reading a lot of Golang of late as we move into k8s world, and I find it hard to read, mainly in terms of package layout - types and their related functions are often in very different places.

But it's certainly less semantically dense compared to Rust or Scala etc.

Re: My favorite Rust function

#166

Post by masklinn »

nerdponx wrote: post #141
saghm wrote: post #27

Earlier quoted context omitted.

Interestingly, the type of `x` actually does matter here in Rust! For most types, yes, passing something by value into a function will cause the memory to be "moved", which means that reusing `x` will be a compiler error. That being said, you can also either pass a shared reference (i.e. `&x`), which will allow you to access the data in Rust (provided you don't move anything out from it or mutate it, which would caus…

Is there any kind of compile-time check available for this (e.g. BIG COMPILER WARNING when you pass-by-value something that lacks Copy)? Seems like a lot of unsettlingly Python-esque freedom ("read the docs and don't screw up") for a language like Rust.

No, passing a "moved" structure by value is perfectly safe, fine and normal. All it means is that you won't be able to reuse it afterwards unless the function you're calling returns it.

There is no "read the docs and don't screw up" because the program will not compile at all if you do it wrong, and the compiler will explain why.

It's very useful for data ownership e.g. move file or string, you can forget about its existence (you have to really). It's also extremely useful to encode "static" state machines, especially when they're attached to some sort of unique resource: on state transition, consume the old state (one type) and return the new state (a different type). Not all state machines can be encoded thus and still useful, but when they do it's really nice.

Re: My favorite Rust function

#167

Post by masklinn »

Too wrote: post #146
gpm wrote: post #42

Earlier quoted context omitted.

The compiler prevents you from implementing both Copy and Drop (i.e. a destructor). So dropping any copy type is a no-op.

Lesson learned from c++ "rule of five"? Where if you implement a destructor you must also carefully implement a copy constructor so that the two copies of the object don't accidentally refer to each others members in any way. Something that is much harder than it sounds like, leading to the now more recommended "rule of zero" saying just don't.

Rust doesn't have copy constructors per-se (it really doesn't have ctors in he C++ sense). Copy is a "marker trait", its operation can not be overridden and is always (semantically) a simple memcpy. The truth is that Copy is not a thing at runtime, it's only a compile-time restriction (when not present).

Clone would be what comes closest to copy constructors, and it has to be explicitly invoked.

Re: My favorite Rust function

#168

Post by crimsonalucard »

HeyImAlex wrote: post #144
crimsonalucard wrote: post #137

Earlier quoted context omitted.

>Isn’t that JSON example the same in python, javascript, and ruby? No. Python doesn't have type checking. That example is a made up syntax of golang if golang had all the correct type primitives. In this example I am defining a type in the first line, similar to how you would define a struct in golang. Then using the type in the second line. There is a bit of an error, but it's too late to edit it now. the Struct in…

I mean... that’s the point I was making. Interface is just like using a dynamically typed language. So saying python can do this but golang can’t is wrong. They are effectively the same. RE: Permutation, the unmarshalled value will only ever be float64, bool, string, interface[], or map[string]interface. The nested interfaces are recursively defined. It’s literally just like doing it in rust, except the compiler won’…

Hm. Ur right bad examples. The only advantage rust has then is more elegant syntax and safety for JSON. Ur also right about python and ruby. It is effectively the same.

Overall though the need for assert is a sign of a crippled type system.

Re: My favorite Rust function

#169

Post by speedplane »

crimsonalucard wrote: post #168
HeyImAlex wrote: post #144

Earlier quoted context omitted.

I mean... that’s the point I was making. Interface is just like using a dynamically typed language. So saying python can do this but golang can’t is wrong. They are effectively the same. RE: Permutation, the unmarshalled value will only ever be float64, bool, string, interface[], or map[string]interface. The nested interfaces are recursively defined. It’s literally just like doing it in rust, except the compiler won’…

Hm. Ur right bad examples. The only advantage rust has then is more elegant syntax and safety for JSON. Ur also right about python and ruby. It is effectively the same. Overall though the need for assert is a sign of a crippled type system.

> Overall though the need for assert is a sign of a crippled type system.

Given that most (if not all) new applications have to ingest data from third party systems and export outgoing data to other third party systems, the need for assertions and data validation is not going away, even in strongly typed systems.

JSON is becoming the de-facto data transfer format, and thus JSON input validation is necessary in both weekly and strongly typed systems. Assuming this JSON trend continues, we can predict stronger JSON type checking built directly into languages.

Re: My favorite Rust function

#170

Post by stepbeek »

pwdisswordfish2 wrote: post #127
hu3 wrote: post #55

Earlier quoted context omitted.

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

Businesses often prefer poor languages with lots of cheap programmers readily available to the opposite, because this lets them easily trade off quality against price. Want it done cheap and fast? Get a freshman intern to write it in PHP or JavaScript; if you later want quality, you can then hire some more expensive seniors to fix it up. If you pick Haskell instead, it may be more reliable upfront, but you also have…

I'm a big fan of scala and really enjoy the language. That being said, the scala community does sometimes advocate an approach that's pretty over-engineered.
Post reply on HN