Live data from Hacker News

Why is Rust difficult?

vorner.github.io

231–240 of 260 posts

Re: Why is Rust difficult?

#231
post #76

Earlier quoted context omitted.

> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully. I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to…

The nice thing about Rust not having Async IO built into the language is that arbitrary third-party implementations are possible on a level playing field with the async framework being developed by the core team. For example, there is the May[1] concurrency library. It provides alternative implementations of the standard library's IO interface, but does Go's automatic suspend/resume, so it still looks like blocking c…

Let me offer a counter point. Every language I have used that has gone the route of "let the community make their own concurrency libraries" has turned out a mess; specifically Ruby and Python.

On the other hand, the concurrency OOTB languages have all had much better ecosystems and experiences; C#, nodejs(now and w/TypeScript), F#, Golang, etc.

Re: Why is Rust difficult?

#232
post #230

Earlier quoted context omitted.

That says that, once Stepanov had written the STL in C++, Stroutrup advocated the STL becoming part of the C++ standard. But you said, > Bjarne advocating him to use C++ instead [of Ada] which your quote here doesn't substantiate at all.

I got the names mixed up, it was Andrew Koenig not Bjarne. "My attempts to implement algorithms that work on any sequential structure (both lists and arrays) failed because of the state of Ada compilers at the time." "In 1987 at Bell Labs Andy Koenig taught me the semantics of C. The abstract machine behind C was a revelation. I also read lots of UNIX and Plan 9 code: Ken Thompson’s and Rob Pike’s programming style c…

> I got the names mixed up

Fair enough. I forgot he was encouraged to go to C++ by anybody.

Re: Why is Rust difficult?

#234
post #186
post #96

Earlier quoted context omitted.

The two languages are approaching a superficial parity, as C# eats up more and more functional concepts. I find it interesting, too, because many of the arguments about things being 'too hard' compared to C# make no sense when those concepts are baseline knowledge in both languages. The positive parts of the functional approach will make code more solid in any language, and C# is working hard to support that approach…

I agree. I just wish more other people knew F# so I could use it for more projects. I've also almost stopped using Python for my scripting purposes. F# is just so much more elegant, and if the scope of the script grows, I can grow it to a proper project. The only reason why I still use Python every once in a while is pandas. If I have to analyze some big tables, it's still far ahead of anything in any other language…

F# is my language crush. Been following it and hoping to use it for a long time. I'm in a leadership position and could MAYBE push to standardize on it however the current more likely scenario is TypeScript(I know, I know) due to my having already successfully pushed that out haha. Unfortunately the ship is already a bit far from shore.

Trying to move us completely away from Python for infra due to its tooling/language services being a post-apocalyptic wasteland. We will always have it around for pandas and ML work though.

Re: Why is Rust difficult?

#235
post #174

Earlier quoted context omitted.

I've taken a brief look at Ada several times, but gave up on it because it seemed difficult to get a cohesive set of documentation and examples (and ideally a good book) that were all in sync. Since Ada has been around for so long, there's an awful lot of outdated material. Do you have any suggestions on materials one should use while learning Ada for hobbyist purposes? I'd like to give it another go.

Four versions of Ada, named after the year it was released: 83, 95, 2005, and 2012. Each new version adds features on top of the previous. Ada 83 has - arrays, - records (structs), - derived types (subtypes carrying the same data as parent type), - subtypes, - access types (thick pointers), - procedures (subprograms executed for their side effects) and functions (subprograms that return values), - Named parameters -…

This PDF introduces Ada for C++ and Java developers. After a quick perusal, it appears that it would be valuable. http://www.adacore.com/uploads_gems/Ada_for_the_C++_or_Java_...

Re: Why is Rust difficult?

#236
post #76

Earlier quoted context omitted.

> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully. I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to…

On the other hand we ripped out channels and went back to mutexes. And my experienced Go-developer friends seem to have all the same reluctance to use channels after ending up in channel hell. There are good aspects of Go concurrency like how the whole ecosystem is async by default (like Node's), but truly praising the model is something I mainly hear from beginners.

I don't know Go, but could you point to more details on the "channel hell"? I would have assumed it was a good way to structure parallelism so I would like to see why not.

Re: Why is Rust difficult?

#237
post #49

Earlier quoted context omitted.

Oh yes, as long as the anti-patterns that emerge don't cause other bugs, they're OK; but some may lead to logical bugs. I'm not sure how likely that is, though- not enough history to go off of yet. Rust is certainly a step in the right direction. I hope the toolchain and so forth end up in a state where all forms of users can love it, though; I have seem some reasonable opposition to including Rust in kernel code, an…

I wonder if rust could be transpiled to somewhat idiomatic C... It should be easier than the other way around.

mrustc compiles Rust to C; I don’t think idiomatic is a goal though.

Re: Why is Rust difficult?

#238
post #31

I feel Go and Rust are great options for writing modern server side applications today, but they exist on two different ends of the spectrum. The Go language is highly minimal, constrained, and forces devopers to write unified code, that performs extremely fast idiomatically. This uniformity is helpful for open source collaboration. Rust is a much more robust language (eg generics), but is more complicated to pick up…

>Imho, Go is ideal for

... tons of boilerplate working fast yet slower than C/Rust/C++.

Re: Why is Rust difficult?

#239
post #76

Earlier quoted context omitted.

> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully. I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to…

I do hope it's not true that people from the community would attack you for writing a compile-to-go language. I don't think it's such a bad idea, considering how stable the language itself is, it's a pretty solid bet.

>writing a compile-to-go language.

Why not fix Go instead?

Re: Why is Rust difficult?

#240
post #204

Earlier quoted context omitted.

As an occasional Ada programmer, I've taken a look several times at Rust and have decided to skip it every time. Ada might be a pain in the ass sometimes (alias rules...), but it's way easier than Rust. In my opinion Rust is a classical case of technology that gets into humans' way rather than serving humans. For me it's just not worth the hassle, especially since most of my programs do not require any soft realtime…

Ada is another non-C with odd semantics, so the problem is that it goes too far and not far enough: It's not enough like C to be familiar, but it's not far enough from C to be able to go head-to-head with Haskell. If I want something that's very safe and don't care about it being similar to C, I'm going all the way to Haskell and not bothering with half-measures.

But it's a big deal to say, "Whenever safety matters, you alwys have room for a runtime with a garbage collector." I feel like you hven't substatiated that claim.
Post reply on HN