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

231–240 of 311 posts

Re: Rust and Go

#231

Post by holoway »

Animats wrote: post #23

The article is a lightweight analysis by someone who writes small programs. He does get that, for Rust, "If the compiler accepted my input, it ran — fast and correctly. Period." That's was a common experience with the very tight languages, such as Ada and the various Modulas. It's been a while since a language that tight was mainstream. We need one now, badly. Go isn't bad for writing routine server-side web stuff th…

It's absolutely lightweight. First impressions for sure, writing what were very small programs. I tried to be clear about that. :)

Re: Rust and Go

#232

Post by holoway »

ChrisGaudreau wrote: post #127
bad_user wrote: post #30

Earlier quoted context omitted.

Quite the contrary, learning a language because it is exploding in popularity is a nice way to ensure that you'll end up being abused, poorly paid and irrelevant. You can't possibly find a worse reason for learning a new language. On Javascript you're missing the causality. Some people are learning Javascript because it is popular of course, because they've read on some forum that learning popular things gets them hi…

Personally, I like to learn any language, regardless of how popular it is. It's just fun.

Yeah, I was doing this for fun. I'm pretty secure in my day job. :)

Re: Rust and Go

#233

Post by Alphasite_ »

grogers wrote: post #160
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…

Except for "static binaries" (which isn't clear what benefits you desire out of them), java has all those things. The other choices are certainly there.

And even Java is getting that.

Re: Rust and Go

#234

Post by holoway »

steveklabnik wrote: post #70
bsaul wrote: post #67

I'm surprised at the paragraph about rust having erlang style actor based parallellism... From what i've read, parallel programming was still heavily a work in design in Rust ( had a very recent discussion on using rust for http server side coding on HN whith people confirming this to me). golang goroutine let me built a standalone binary with embedded https server and websocket support. Would Rust be able to do that…

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 ;)

Re: Rust and Go

#235

Post by ufo »

jaekwon wrote: post #101
pcwalton wrote: post #91

Earlier quoted context omitted.

The article is about Rust. In Rust, the type of the closure indicates whether it can mutate externally visible data (and therefore race on it).

Gotcha! So will Rust then auto-parallelize these "pure" closures?

I wouldn't put my hopes very high on this. They tried doing this kind of ubiquitous automatic parallelization in Haskell but they ran into parallelization overhead issues because its very hard to have the computer figure out the correct parallelization granularity all by itself.

Re: Rust and Go

#236

Post by lomnakkus »

jaytaylor wrote: post #162
rdtsc wrote: post #125

Earlier quoted context omitted.

It is not a black and white situation probably. Golang is better because it has built-in channels and encourages users to take advantage of them. It also has garbage collection. So those 2 things right of the bat help. But there are better things out there -- isolated heaps (Erlang), borrow checkers (Rust), stronger type systems and immutability (Haskell) etc. There are no magic unicorns so those things often come at…

Just out of curiosity - is there a problem with sharing data across goroutines when access to/mutation of said data is controlled by a mutex? func (*Mutex) Lock Lock locks m. If the lock is already in use, the calling goroutine blocks until the mutex is available. http://golang.org/pkg/sync/ It seems to me this is a valid alternative to [rigidly] sticking to pure message passing.

In short: We (as a field) tried them for many many (many!) years now and they have been found lacking -- in practice they're just too hard to get right for large-scale systems.

EDIT: The mutexes themselves are easy enough to get right, it's the systems using mutexes that are too hard to get right.

Re: Rust and Go

#237

Post by masklinn »

zzzcpan wrote: post #227
masklinn wrote: post #223

Earlier quoted context omitted.

> And people make mistakes independent of language features Unless language features prevent the existence of these bugs. Javascript will blindly let you concatenate a number and a string, Go will not. Therefore you can't make the mistake of unknowingly concatenating a number and a string in Go. Thanks to a language feature. Iterators prevent indexing mistakes (off-by-one errors, index overflow or overflow, wrong-var…

> Therefore you can't make the mistake of unknowingly > concatenating a number and a string in Go. Look at this another way: If you need to do that you now have to think about it and explicitly convert a number into a string. But while you are thinking about it you can make mistake of concatenating a number with a wrong string or make some other screw up, because your thinking power is now reduced.

> If you need to do that you now have to think about it and explicitly convert a number into a string.

You have to think about it either way, the feature precludes forgetting about it.

> you can make mistake of concatenating a number with a wrong string or make some other screw up

Which you can make in both cases.

> because your thinking power is now reduced.

Your thinking power is not reduced, it's increased: you don't have to wonder whether you should convert something to a string or it already is one, the compiler will tell you, so you can focus better on the actual work at hand.

Re: Rust and Go

#238

Post by pjmlp »

coldtea wrote: post #206
pjmlp wrote: post #201

Earlier quoted context omitted.

My point was that Smalltalk did not became mainstream, because a few heavy weight vendors decided to switch field to support the new kid on the block.

Well, a counter point then can be: and why did those vendors did not insist on Smalltalk? Why weren't Smalltalk more heavily pushed by some big vendor itself? It's not like SUN was the only player in town. IBM pushed Smalltalk IIRC. I think this (from StackOverflow) tells a more comprehensive story): • when Smalltalk was introduced, it was too far ahead of its time in terms of what kind of hardware it really needed •…

I used VisualWorks at the university in 1995, just before Java appeared and there were presentations with broken Java code[1].

Eclipse 1.0 was Visual Age for Smalltalk redone in Java.

If Java hadn't appeared in the scene, maybe even with those cat fights, the language would have become mainstream anyway.

This just speculation from my part.

[1] The famous "private protected" that was accepted in the very first release.

Re: Rust and Go

#239

Post by zzzcpan »

masklinn wrote: post #237
zzzcpan wrote: post #227

Earlier quoted context omitted.

> Therefore you can't make the mistake of unknowingly > concatenating a number and a string in Go. Look at this another way: If you need to do that you now have to think about it and explicitly convert a number into a string. But while you are thinking about it you can make mistake of concatenating a number with a wrong string or make some other screw up, because your thinking power is now reduced.

> If you need to do that you now have to think about it and explicitly convert a number into a string. You have to think about it either way, the feature precludes forgetting about it. > you can make mistake of concatenating a number with a wrong string or make some other screw up Which you can make in both cases. > because your thinking power is now reduced. Your thinking power is not reduced, it's increased: you do…

No, if conversion is implicit you don't have to think which function to call, where to find it and which library to include. Quite significant cognitive overhead I'd say.

Having separate concatenation operator with implicit conversion could reduce that overhead:

  a := "foo" ~ "bar" ~ 123
Instead of:

  import "strconv"
  
  a := "foo" + "bar" + strconv.Itoa(123)
But this is not how Golang guys make decisions. And I'm fine with that nowadays as long as they don't claim to be right in that regard.

Re: Rust and Go

#240

Post by zzzcpan »

Alphasite_ wrote: post #233
grogers wrote: post #160

Earlier quoted context omitted.

Except for "static binaries" (which isn't clear what benefits you desire out of them), java has all those things. The other choices are certainly there.

And even Java is getting that.

Too late. Also Java is not as easy to learn and to use as Golang.
Post reply on HN