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

Rust and Go

medium.com

Post reply on HN
Print view View original

241–250 of 311 posts

Re: Rust and Go

#241

Post by steveklabnik »

holoway wrote: post #234
steveklabnik wrote: post #70

Earlier quoted context omitted.

Yeah, "Erlang style-actor" isn't exactly accurate anymore. A while ago, this was true, but it's not exactly true today. That said, Rust does encourage message passing by default, but also gives you the ability to safely do shared-memory concurrency if you need.

From my (admittedly super ignorant position) it felt very similar - message passing, spawn, etc. The primitives felt very similar. I'm sure they differ hugely in details ;)

When I think "Erlang style" I think process trees and no shared-memory and sending code over the network to other nodes. Maybe that's my bias. :)

(We also used to say "Erlang-style" in our marketing, but eventually removed it)

Re: Rust and Go

#242

Post by yohanatan »

ternaryoperator wrote: post #177
yohanatan wrote: post #159

Earlier quoted context omitted.

> I could not agree more with your first paragraph. The only other language I've used that I've had that experience with was Haskell, and while there are good arguments to be made for using Haskell in production, it should be obvious that's not a language that will ever become mainstream. I don't think it is at all obvious that Haskell won't become mainstream. It's already exerted a tremendous influence over many oth…

I agree Haskell has had an important influence, but I don't see why people would necessarily "go directly" to it because of that. In fact, I would argue just the reverse. People chose the derivative languages b/c they provide things the original does not. To wit, Lisp never became mainstream despite exerting a huge influence. Likewise Smalltalk.

> I agree Haskell has had an important influence, but I don't see why people would necessarily "go directly" to it because of that.

I also said "or one of its direct descendants" (like Agda or Idris in all likeliness).

> To wit, Lisp never became mainstream

Clojure doesn't count? And the good parts of Perl, Ruby & Javascript are essentially Lisp without the homoiconicity.

Re: Rust and Go

#243

Post by yohanatan »

legulere wrote: post #194
yohanatan wrote: post #159

Earlier quoted context omitted.

> I could not agree more with your first paragraph. The only other language I've used that I've had that experience with was Haskell, and while there are good arguments to be made for using Haskell in production, it should be obvious that's not a language that will ever become mainstream. I don't think it is at all obvious that Haskell won't become mainstream. It's already exerted a tremendous influence over many oth…

Even worse than the problem of uncommon concepts as monads is that Haskell's memory footprint is extremely hard to reason about. A few years ago it was impossible with the http libraries to download a file without the program consuming several times as much memory as the downloaded file.

> Even worse than the problem of uncommon concepts as monads

Just go ahead and learn the typeclass hierarchy and such-- it really is quite a useful higher level of abstraction in whatever language you choose. And it definitely will enter the mainstream (even more than is already has [Swift, Scala & C# all have monadic constructs]).

> Haskell's memory footprint is extremely hard to reason about.

And you'd probably want to also throw runtime in there as well.

I think this is relative-- it's not "extremely hard" for everyone. Also, many structured programmers found object orientation "extremely hard" but somehow the industry managed to progress through that era.

Re: Rust and Go

#244

Post by kolektiv »

MichaelGG wrote: post #175
zzzcpan wrote: post #72

Earlier quoted context omitted.

There are a lot of bad things in Go, sure. And some are really annoying, like "goroutine all the things" mantra. But no matter how I dislike it there is just no other choice today. It all comes down to support, bug fixing, ease to learn and to use, good standard library, built in cross-compilation and a pretty fast one, static binaries, good enough dependency management, reasonable performance and memory usage, espec…

F# has that. With Mono you can produce static binaries. And the F# compiler can also make statically linked assemblies, including the bits it needs from all its dependencies. Although I'm not sure if there is an F# code formatter tool. Which is made up for by F# being a vastly more capable language.

Yes, some code formatting tools exist (within Visual Studio as part of F# Power Tools, and also I believe standalone in some binary form). However, as a community we're currently a little less dogmatic than Go (for example) about what "correct" formatting is.

Tabs vs. Spaces is decided at the language level (it's spaces or it doesn't work) but other things are often a matter of taste. It doesn't tend to matter too much though because (well written) F# code is expressive almost regardless of minor formatting issues (poorly written code in any language is a comprehensibility mess, regardless of "neatness" or newline consistency!)

Re: Rust and Go

#245

Post by yohanatan »

bjz_ wrote: post #165
yohanatan wrote: post #159

Earlier quoted context omitted.

> I could not agree more with your first paragraph. The only other language I've used that I've had that experience with was Haskell, and while there are good arguments to be made for using Haskell in production, it should be obvious that's not a language that will ever become mainstream. I don't think it is at all obvious that Haskell won't become mainstream. It's already exerted a tremendous influence over many oth…

I have definitely heard from multiple people that for them Rust was a good stepping stone to Haskell. Hopefully it will be the same way with Swift.

I think the same is true for F# and Scala.

Re: Rust and Go

#246

Post by eridius »

yohanatan wrote: post #242
ternaryoperator wrote: post #177

Earlier quoted context omitted.

I agree Haskell has had an important influence, but I don't see why people would necessarily "go directly" to it because of that. In fact, I would argue just the reverse. People chose the derivative languages b/c they provide things the original does not. To wit, Lisp never became mainstream despite exerting a huge influence. Likewise Smalltalk.

> I agree Haskell has had an important influence, but I don't see why people would necessarily "go directly" to it because of that. I also said "or one of its direct descendants" (like Agda or Idris in all likeliness). > To wit, Lisp never became mainstream Clojure doesn't count? And the good parts of Perl, Ruby & Javascript are essentially Lisp without the homoiconicity.

> Clojure doesn't count?

Perfect example. Clojure != Lisp. But it is a pretty obvious descendant.

Re: Rust and Go

#247

Post by eridius »

tome wrote: post #183
eridius wrote: post #40

Earlier quoted context omitted.

I could not agree more with your first paragraph. The only other language I've used that I've had that experience with was Haskell, and while there are good arguments to be made for using Haskell in production, it should be obvious that's not a language that will ever become mainstream. I'm hoping that as Swift evolves over time, it will slowly become that sort of language. Right now it's pretty hard to write any rea…

> it should be obvious [Haskell]'s not a language that will ever become mainstream If it is obvious then you should be able to explain why in a few sentences.

Haskell is an academic language with a focus on language research rather than pragmatism.

One sentence. Is that sufficient?

Re: Rust and Go

#248

Post by Dewie »

dbaupp wrote: post #147
bjz_ wrote: post #143

Earlier quoted context omitted.

Hmm, was the parent comment edited? I can't see a reference to documentation...

The "I missed Nim" article to which it links to includes > Nim has Exceptions with tracking (!) and Rust has… something incomprehensible or perhaps its this, I am actually not sure ;). Again, for me, a clear win for Nim. where "something incomprehensible" links to very old documentation of the conditions system, which was removed quite a while ago.

If we swapped the language, he might as well also have said:

> The other language is named Nimrod... or perhaps it is Nim... I'm actually not sure ;).

Re: Rust and Go

#249

Post by Dewie »

gokr wrote: post #211
dbaupp wrote: post #192

Earlier quoted context omitted.

Re 2. as my comment states, we have tried to fix it, but we cannot: the administrator of that server is powerless. Error handling is mainly via types, mainly `Result`: http://doc.rust-lang.org/nightly/std/result/ . That part of your article will need changing because it is completely different to the condition system (that is, just swapping the link would be useless). Also, it's a little unfortunate that you entirely…

What I meant with "issue to fix" - add a section in the documentation that has some kind of words that outsiders connect with "error handling": Error, Exception etc Perhaps I didn't search hard enough - but the next person will probably not search harder either. "Result" is not typically a word one would search for.

> "Result" is not typically a word one would search for.

It was renamed from the more generic (type-wise) "Either", because the two tags (Left and Right) didn't feel very descriptive when it was used as a error-or-value type. But "Either" at least hints at the concept of "either this or that": "Result" is even more of a generic name. I don't know why they settled on a name like that. (The two tags, Ok and Err are more descriptive for errors, though.)

Re: Rust and Go

#250

Post by masklinn »

masklinn wrote: post #221
acqq wrote: post #210

Earlier quoted context omitted.

To handle the overflow on the places where you want to handle them, modern processor doesn't have any problem with an additional jump instruction. Also, modern compilers could optimize the checks away if they aren't used. In effect, implementing overflow checks definitely won't turn your C speed (1s) code in a Python speed (40s) code. I estimate it wouldn't be even two times slower in most of the use cases. It's cert…

> I estimate it wouldn't be even two times slower in most of the use cases. In his "We Need Hardware Traps for Integer Overflow"[0], Regher quotes 5% to 100% overhead for languages such as JS or Racket, and that a "highly tuned" checker would likely be in the 5% range. Playing with arithmetics-heavy programs and Rust's checked_* (which are backed by LLVM's overflow intrinsics[1]) I got anywhere from 5 to 40% performa…

OTOH I must note that Swift, on the other hand, has opted to error on overflow and have a second set of overflowing operators: https://developer.apple.com/library/mac/documentation/swift/...
Post reply on HN