Earlier quoted context omitted.
That's easy, just change your program so that every value of type T is now a value of type Arc >.
Reference counting does not handle cycles.
But it works for every other case.
Rust in 2018: easier to use
281–290 of 305 posts
Re: Rust in 2018: easier to use
#282Earlier quoted context omitted.
I wanted to get into f# but had a hard time with tooling, cross platform. For example, I'd see a great library and the instructions assume VS while I'm on Linux. There are a variety of build tools and package managers. As Python dev since 10 years I can't point fingers -- Python is probably worse though I've memorized the idiosyncrasies -- but I couldn't justify my way up the tooling learning curve in addition to the…
(I work on F# at MS) Do you remember the library? The landscape has changed dramatically in the past ~6 months with .NET Core 2.0 support. For example, I can use Fable[0] and Giraffe[1] with the .NET CLI[2] to build full-stack F# apps on my machine which runs .NET Core. The big remaining blocker for most people to just jump wholesale onto .NET Core and forget anything Windows-based is the lak of Type Provider support…
I was looking at Brahma.FSharp and something else with type providers, both with Nu Get instructions, and I didn’t see how to get it working with VS Code.
Re: Rust in 2018: easier to use
#283Earlier quoted context omitted.
You summarized it so well ! It was also a huge source of confusion for me in the beginning. Would you mind if I made a pull request to the Rust book adding your explaination to the lifetime chapter ?
While it doesn't have this literal text, it already does have the equivalent: https://doc.rust-lang.org/book/second-edition/ch10-03-lifeti... > Lifetime annotations don’t change how long any of the references involved live. In the same way that functions can accept any type when the signature specifies a generic type parameter, functions can accept references with any lifetime when the signature specifies a generic l…
Cool. I haven't read the second version of the book, and I read the first version about two years ago I think. Glad to see this difficulty is now covered. Carry on with the great job Steve :)
Re: Rust in 2018: easier to use
#284Earlier quoted context omitted.
Heh, so does yours. I can say this without even knowing what language you use to write your software, much less looking at it... All software has bugs, and most of those are security vulnerabilities waiting to happen.
Of course. Code is hard. Using a safer language makes it easier and less prone to out-of-bounds memory accesses. By using C/C++ you're choosing to make a hard problem harder.
And slower or impractical even for some things. Maybe we should write a real-time media codec in python 'cause security. I don't understand why you, like the OP, make these sweeping generalizations as though all of engineering is black and white. Sometimes, I reach for a higher abstraction, sometimes not. It depends on the problem domain.
Oh and btw, "out of bounds memory accesses" are not the primary source of security vulnerabilities at all. In fact, such out of bounds access is more likely to just make your program crash (which is a good thing).
Re: Rust in 2018: easier to use
#285Well it is super easy to develop hello world in Rust. Yay! Last time I checked there was no decent HTTP client and the documentation is just non existent for that subpar library. There were lost of promises about the newer version of async io library yet it is still WIP as of today. The performance was 30 times less than the same code in Java and after consulting many Rust developers nobody could tell me why. It is n…
Looks like we found the javatarian! I had to look up on Wikipedia when Rust was conceived: 2010. It took me another moment to realize that it's already been 8 years. We should be flying in spaceships programmed with Rust by now. This is ridiculous.
Totally. This is why i use OCaml, Erlang and Clojure. I am a performatarian more like and I cannot be put up with the newest hipster crap that anybody came up with if it does not provide the functionality that we need to implement for our business requirement. Rust failed that. What is your argument exactly here? This is reddit level comment you put in here.
Re: Rust in 2018: easier to use
#286Well it is super easy to develop hello world in Rust. Yay! Last time I checked there was no decent HTTP client and the documentation is just non existent for that subpar library. There were lost of promises about the newer version of async io library yet it is still WIP as of today. The performance was 30 times less than the same code in Java and after consulting many Rust developers nobody could tell me why. It is n…
So if a language can't do HTTP and async I/O (with state-of-the-art performance) then we shouldn't consider any other possible application for it? Rust is not Java, you have better languages to build webservers with.
So if a language cannot do our business need then we shouldn't consider any other possible application for it?
Re: Rust in 2018: easier to use
#287Re: Rust in 2018: easier to use
#288Earlier quoted context omitted.
Looks like we found the javatarian! I had to look up on Wikipedia when Rust was conceived: 2010. It took me another moment to realize that it's already been 8 years. We should be flying in spaceships programmed with Rust by now. This is ridiculous.
Totally. This is why i use OCaml, Erlang and Clojure. I am a performatarian more like and I cannot be put up with the newest hipster crap that anybody came up with if it does not provide the functionality that we need to implement for our business requirement. Rust failed that. What is your argument exactly here? This is reddit level comment you put in here.
It was an ad hominem. I'm sorry. Good luck with your endeavors. Erlang is a wise choice, if you can find the people to support it.
Re: Rust in 2018: easier to use
#289Earlier quoted context omitted.
Totally. This is why i use OCaml, Erlang and Clojure. I am a performatarian more like and I cannot be put up with the newest hipster crap that anybody came up with if it does not provide the functionality that we need to implement for our business requirement. Rust failed that. What is your argument exactly here? This is reddit level comment you put in here.
It was an ad hominem. I'm sorry. Good luck with your endeavors. Erlang is a wise choice, if you can find the people to support it.
"Looks like we found the javatarian!" ... "It was an ad hominem."
Re: Rust in 2018: easier to use
#290Earlier quoted context omitted.
rust at one point had garbage-collected references. And there's still Rc/Arc types for reference counting. I get what you're saying though. Another poster mentioned Swift and indeed Graydon Hoare, Rust's creator, is now working on Swift at Apple. And I believe some kind of notion of borrow checking/lifetimes is supposed to be coming to Swift in the future?
Not all that familiar with Rust's history or anything but why would he leave to work on Swift at Apple? He creates a language which is getting a huge amount momentum and praise around it, and decides to do something else? Must have been a lot more money, because a situation like that don't come up very often.
He didn't leave to work on Swift; he left, then got a different job, then left that job eventually to work on Swift. I'm being vague because well, it's his personal life, and he'd generally prefer people not talk about it too much or read too much into it.