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

181–190 of 311 posts

Re: Rust and Go

#181

Post by SamReidHughes »

masklinn wrote: post #176
codygman wrote: post #157

Earlier quoted context omitted.

Who is Amdahl, why should I care, and does he expand on this argument or is it your interpretation of a more generalized law? Going to search for it, but I'd still like to hear your response.

The application in this case is that the mapped operation generally has a fairly low cost and the (sequential) cost of dispatching and resynchronising back into a result are going to dwarf any gain you'd get unless either the collection is huge (and the parallelization is coarsely chunked) and/or the mapped operation is extremely expensive. Same reason why even though mergesort is fairly trivially parallelizable ther…

Your collections don't have to be stupifyingly huge for a parallel mergesort to be faster. It's bad for a standard library to auto-parallelize because that's an unwelcome side effect. If you're writing some program where you actually cared about the performance speedup, in most cases having a sort function spawn threads or use threads behind your back in a way that your system can't control is completely unwelcome.

Re: Rust and Go

#182

Post by pjc50 »

blt wrote: post #152
pjc50 wrote: post #47

Earlier quoted context omitted.

Never underestimate the legacy. I've resolved not to start another C++ project, but I'm learning MFC at the moment for working on a codebase that's 35 years old and was rewritten into C++ at some point in the 90s.

I'm sorry you have to do that.

I'm finding it not too bad; the style is somewhere between 'C with classes' and EnterpriseJavaReallyLongNames, and aggressive testing has kept it working over the years. MFC itself is pretty intuitive and I like the window message system.

Re: Rust and Go

#183

Post by tome »

eridius wrote: post #40
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…

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.

Re: Rust and Go

#184

Post by acqq »

pcwalton wrote: post #128
jaekwon wrote: post #123

Earlier quoted context omitted.

Doh! I fell straight in :) Overflows in general are tricky. How does Rust deal with it?

We have special checked types you can use if you want checked arithmetic. The default is to not check, because CPUs currently make it expensive to check (although I would love it if that could change--we need hardware support though).

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.

Re: Rust and Go

#185

Post by pjmlp »

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.

> 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.

Re: Rust and Go

#186

Post by LunaSea »

pjmlp wrote: post #185
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.

> 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.

So his point stands. People preferred Java to Smalltalk and it thus didn't become mainstream.

Re: Rust and Go

#187

Post by gokr »

Cyther606 wrote: post #80
humanrebar wrote: post #45

Earlier quoted context omitted.

who is still using C/C++ in 2014, and why? Systems programmers. Embedded programmers. Kernel developers. Compiler developers. Language runtime developers. Safety critical software developers. I guess you can group them under "performance benefits" but it's as much about the ability to drop down, write arbitrary bits to arbitrary addresses, and (re)implement low-level constructs as it is about performance. The most ob…

Nim performance compares favorably to C++. It features a Pythonic syntax, optional soft real-time GC, optional manual memory management. Porting an elliptic curve implementation over to Nim from Python was a cinch: elliptic.nim: https://github.com/def-/bigints/blob/master/examples/ellipti... elliptic.py: https://github.com/wobine/blackboard101/blob/master/Elliptic... Others have reported success converting Python cod…

Regarding the parts where I link to out of date docs:

1. I will fix it later today/tomorrow, busy right now

2. I did actually search quite a bit, but that was what I as an outsider found. Consider this an "issue" to fix :)

I think the issue was that the words I was searching for are not the words used to describe these mechanisms.

Anyway, if you can give me a proper link to the canonical place where error/exception handling in Rust is documented - I will link it. Going to http://doc.rust-lang.org/0.12.0/reference.html I still can't seem to find it.

Re: Rust and Go

#188

Post by LunaSea »

bad_user wrote: post #30
ryandvm wrote: post #3

Earlier quoted context omitted.

Hmm. Learning a language/framework that is exploding in popularity is probably one of the best things a dev can do to stay relevant (read: employed). Hell, very few of us would be using Javascript if it weren't for it's ubiquity/community/popularity. I sure as hell am not using it because it's a well designed language.

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…

By learning new programming languages or frameworks you stand out from the crowd.

Guess who's going to get a job:

A) The fool who just learned JavaScript and Angular.js

B) The university student who only knows Java

The answer will be (A) every single time because companies don't have the time to train people for months.

Re: Rust and Go

#189

Post by dschiptsov »

tptacek wrote: post #79
alkonaut wrote: post #17

If you are considering Go, or just want a good laugh, just read discussions where higher order functions are discussed. Or for that matter, generics. Here is a gem: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC... There's a chance you'll laugh at the people dismissing higher order functions as nonsense, in which case Go might not be for you. This is a good test of whether you want to try it out or not.

Let me save the reader of this comment a long and unproductive session of reading tea leaves out of mailing list posts: * Golang doesn't have generics. This comes up so often on the mailing list that it's in the FAQ: http://golang.org/doc/faq#generics * Golang has a similar attitude to idiomatic functional programming tools as Python; it doesn't have map() and it's not easy to write a general-purpose map. (I'll take…

Let me clarify even more.) If a language does not threat functions (procedures) as "first-class citizens" (like any other value it could be another function's argument or return value, a member of an aggregate) then you should't use it for writing programs in functional style.

As long as your language has "everything is a pointer semantics" you should be able to write your own map and filter in a 2 or 3 lines of code.

   map(F, [H|T]) -> [F(H)|map(F, T)];
   map(F, []) -> [].

Re: Rust and Go

#190

Post by nhaehnle »

freyr wrote: post #31

It's not clear how much experience the author really acquired with each language, and whether that experience was sufficient experience to justify his statement: Go felt that way to me — it was good at everything, but nothing grabbed me and made me feel excited in a way I wasn’t already about something else in my ecosystem. He's apparently using each language to write relatively small command-line utilities. If Go is…

Another aspect that makes me hopeful about Rust as a way forward for C++ programmers is that it is designed to play well with the C (if not C++) ecosystem.

Go is in this weird place where they insist that you have to be 100% Go or not at all, at least with the official Go package (gccgo is different, but this divergence in the ecosystem doesn't exactly inspire confidence). This is convenient when you have small isolated processes, but completely prevents Go adoption in other environments.

I'm working in an electronic design automation software system which is basically a large number of C/C++ shared libraries/plugins loaded into a Tcl interpreter which you do not want to rewrite (lots of tricky and finely tuned optimization and design analysis algorithm).

Go is not a good fit in this environment because of its all-or-nothing attitude. Rust, on the other hand, is fairly easy to imagine as an addition to the toolset from a purely technological point of view (ignoring the social and management issues which add a huge amount of inertia). There is an unfortunate impedance mismatch between idiomatic C++ and idiomatic Rust, but communication is possible via a thin C interface.

Post reply on HN