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

201–210 of 311 posts

Re: Rust and Go

#201

Post by pjmlp »

coldtea wrote: post #197
pjmlp wrote: post #185

Earlier quoted context omitted.

> Likewise Smalltalk Java happened. Business were already in the process of adopting Smalltalk. Hotspot is a Smalltalk JIT compiler reborn. Eclipse is Visual Age for Smalltalk reborn. It still keeps the old Smalltalk code browser.

> Hotspot is a Smalltalk JIT compiler reborn. Yeah, but nothing in it is Smalltalk-specific. It's not like Smalltalk survives in the mainstream because of Hotspot (in the way that, say, Algol survives). [edit: survives, not "survices"]

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.

Re: Rust and Go

#202

Post by burntsushi »

masklinn wrote: post #172
burntsushi wrote: post #158

Earlier quoted context omitted.

The parent is referring to the fact that Guido van Rossum (the Benevolent Dictator For Life of Python) is pretty down on functional programming in Python. You can read some of the history (from the horse's mouth) here: http://python-history.blogspot.com/2009/04/origins-of-python... TL;DR - "I have never considered Python to be heavily influenced by functional languages, no matter what people say or think." Python, IM…

> But its broken closures They were "unbroken" in Python 3, though because of the way scoping works in the language it requires marking variables (with `nonlocal`)

I'm aware. The presence of nonlocal and global still makes them broken to me, even if it's a result of how scoping works. Lua and Javascript both manage to have unbroken closures.

Re: Rust and Go

#203

Post by lmm »

tptacek wrote: post #108
nightpool wrote: post #98

Earlier quoted context omitted.

Umm... Am I just interpreting you wrong? Python has map in the builtin namespace: >>> map(lambda x: x*5, range(5)) [0, 5, 10, 15, 20]

Python obviously has those primitives (that's what I meant by the tradeoff between it and Golang) but Guido infamously discourages their use.

Guido discourages map because it should usually be expressed as a comprehension, no?

Re: Rust and Go

#204

Post by NateDad »

gruvector wrote: post #179
twtwtaway wrote: post #66

Earlier quoted context omitted.

I also agree with the Go team. Although I am a big fan of functional language constructs like map & filter, adding them to Go does not feel right. One of the great things about Go is that it's simple but it does not hide much from you. You still know exactly what is going on (concurrency& channels being an exception). That's why I find it easy to read Go code.

The go community reminds me of the java community. Blind faith in the design decisions of the language. Any feature it doesn't have is passionately defended as a good decision because the clumsy old way is subjectively clearer, up until the day it gets added.

mapping and filtering are just functions and/or loops. You can write those in go. Making some generic thing to save you 3 lines of (really simple) code is not an incredibly useful use of the Go author's time.

Re: Rust and Go

#205

Post by lmm »

programminggeek wrote: post #9

Having spent a little time with Go, I ended up feeling like it was both better and worse than Ruby. In many ways it's many of the things that I want from a language - static typing, fast complier, pretty sensible defaults and so on. A lot of things I wish Ruby did, Go does great. I think Go does really well in tooling, but it doesn't feel as great in syntax or language features that I would really like. The two big o…

Maybe OCaml is what you want?

(I'm a Scala guy myself and I understand OCaml has no higher-kinded types and worse performance (in terms of throughput of the code), and its syntax is weird. But it's a general purpose programming language with an emphasis on immutability, at least some kind of keyword arguments, strong types and allegedly fast compilation (though probably not at the same level as go))

Re: Rust and Go

#206

Post by coldtea »

pjmlp wrote: post #201
coldtea wrote: post #197

Earlier quoted context omitted.

> Hotspot is a Smalltalk JIT compiler reborn. Yeah, but nothing in it is Smalltalk-specific. It's not like Smalltalk survives in the mainstream because of Hotspot (in the way that, say, Algol survives). [edit: survives, not "survices"]

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

• In 1995, when Java was released to great fanfare, one of the primary Smalltalk vendors (ParcPlace) was busy merging with another (Digitalk), and that merger ended up being more of a knife fight

• By 2000, when Cincom acquired VisualWorks (ObjectStudio was already a Cincom product), Smalltalk had faded from the "hip language" scene

http://stackoverflow.com/questions/711140/why-isnt-smalltalk...

Re: Rust and Go

#207

Post by masklinn »

burntsushi wrote: post #202
masklinn wrote: post #172

Earlier quoted context omitted.

> But its broken closures They were "unbroken" in Python 3, though because of the way scoping works in the language it requires marking variables (with `nonlocal`)

I'm aware. The presence of nonlocal and global still makes them broken to me, even if it's a result of how scoping works. Lua and Javascript both manage to have unbroken closures.

> Lua and Javascript both manage to have unbroken closures.

Because they use explicit local declaration (and implicitly declared variables are global in both)…

Re: Rust and Go

#208

Post by jacques_chester »

jbooth wrote: post #154
jacques_chester wrote: post #84

Earlier quoted context omitted.

Semantically, loops impose order, maps do not. A map can be auto-parallelised. A loop cannot. It seems to me that for a language aimed at exploiting concurrent features, easy wins for parallelisation would be a feature.

Amdahl's law says auto-parallelising a map operation is usually a big waste of time.

Have you rung up the GPU manufacturers to tell them that they're wasting everyone's time?

Re: Rust and Go

#209

Post by agapos »

I have seen it for many cases how Rust's strictness (no null pointers and other things) has a positive effect on safety, but I am curious: does this also affect reliability or stability to the better?

I would like to know the thoughts of someone experienced with Rust.

Re: Rust and Go

#210

Post by acqq »

dbaupp wrote: post #193
acqq wrote: post #184

Earlier quoted context omitted.

But CPU's have the overflow flag, that is actually set if the operation overflows? You can't write that check explicitly in C, but you can in assembler. Available now, across the different hardware.

As you say, detecting the overflow is easy, but efficiently handling it is not. It adds a branch to every single arithmetic operation, and it makes it much harder for the compiler to optimise things e.g. it is hard to vectorise a loop summing an array, if every + has a conditional branch on the overflow flag. (Also, I believe it introduces a lot of data dependencies, getting in the way of the out-of-order execution o…

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 certainly not the problem of the CPU's.

It can be the problem of the certain compilers if they don't have the infrastructure to reason about overflow flags though. But it's not a hardware problem.

Post reply on HN