181–190 of 209 posts
Earlier quoted context omitted.
I hear you! Basically same here. I had not come across this one...
I haven't either. FWIW, myself and one of your cohorts at Mozilla had a phone call with Intel (a while ago at this point), and while there were no lawyers on the line, the engineers we talked to sounded very happy about what we were doing.
Earlier quoted context omitted.
I used to like Go a bit, but never did a full blown application in it, just did enough to get a feel of it. Having tried Rust recently (after not liking the idea of not having classes like in Go) I have to say I prefer Rust for several reasons. For starters the tooling for Rust is well done. If I want to install Rust on any machine I'm on I just go to https://rustup.rs/ and go from there, then I can use rustup to upd…
You mention tooling and IDE where Go is better than Rust in that space and as for Cargo just use go dep problem solved.
Earlier quoted context omitted.
I always find this argument really strange. How is making a complicated decision (which language is best for this task) easier using less information (the benchmarks are only one facet of the decision)?
The name of the website used to be the language shootout; it was subsequently changed to be called the benchmarks game to emphasize that its not a rigorous comparison between languages. Benchmarking is hard. You have to identify workloads that are realistic and representative, large enough to be sure you're hitting the steady-state performance yet small enough you can run them on a regular basis. And, of course, you…
Earlier quoted context omitted.
more benchmarks source generics Rust 100% Go 0% source if err!=nil return { nil, err }; Rust 0% Go 100% source undeserved hype Rust 100% Go 100%
source: good generics implementations Haskell: 100% All Other Languages: 0% source: flawed generics implementations Haskell: 0% All Other Languages: 100%
Coq: 142%
Haskell: 91%
All Other Languages: 0%
Earlier quoted context omitted.
Go makes writing networking services like a dream for sure, and Rust also seems have it's own plan[0] on network service field. It could be awesome to see they compete with each other and come up something good. [0] https://internals.rust-lang.org/t/announcing-the-network-ser...
Rust is still figuring out its "async" story. Go figured it out, and went full steam ahead before the language was even made public - day 0, basically. I'm not holding my breath for Rust dethroning non-perf-critical Go projects anytime soon.
I'm also use Go primarily to write any application that may needs parallel (Not just network service).
For me, Rust is a exciting new language that I could love to use if they can finally put all the async/await things together.
Earlier quoted context omitted.
> Oh yea, and green threads, god do I wish Rust had green threads. They still don't? I thought they were working on that years ago, no?
1. long ago, we used to have green threads and a runtime 2. we decided to eschew the runtime, and therefore, the green threads. 3. Since then, various libraries have implemented green threads in various ways 4. Tokio is basically green threads today. It really depends on what you mean exactly by "green threads".; but it schedules N tasks on M OS threads, so...
> 2. we decided to eschew the runtime, and therefore, the green threads.
The most important bit I guess, regarding the question of whether Rust will ever have green threads/fibers/trails/whatever (answer: no, because no runtime).
Earlier quoted context omitted.
1. long ago, we used to have green threads and a runtime 2. we decided to eschew the runtime, and therefore, the green threads. 3. Since then, various libraries have implemented green threads in various ways 4. Tokio is basically green threads today. It really depends on what you mean exactly by "green threads".; but it schedules N tasks on M OS threads, so...
Thank you for clarifying! > 2. we decided to eschew the runtime, and therefore, the green threads. The most important bit I guess, regarding the question of whether Rust will ever have green threads/fibers/trails/whatever (answer: no, because no runtime).
Earlier quoted context omitted.
APL and co kind of undermine that metric, wouldn't you say?
Kolmogorov complexity is "ideal compression", in that it bundles the axioms and the expression to reproduce the desired output using those axioms. So it really is a perfect measure for this type of thing. Gzip is an approximation of this metric of course, and the only flaw in the benchmark suite is that it should really include the size of the runtime which provides the programming language's axioms. APL is also a go…
I mentioned APL because programs in it usually consist of a handful of symbols with very little repetition. The symbols/performance ratio is really good for APL. Or to be even more on the nose: think of code golfing languages[0].
[0] https://en.wikipedia.org/wiki/Code_golf#Dedicated_golfing_la...
Earlier quoted context omitted.
Kolmogorov complexity is "ideal compression", in that it bundles the axioms and the expression to reproduce the desired output using those axioms. So it really is a perfect measure for this type of thing. Gzip is an approximation of this metric of course, and the only flaw in the benchmark suite is that it should really include the size of the runtime which provides the programming language's axioms. APL is also a go…
I know what Kolmogorov complexity is, I was trying to get at something else: removing boilerplate is one thing, but the other extreme isn't all that helpful either. When discussing information theory, one should always remember that white noise has the maximum amount of information , so the theoretical best scoring programming language of your measurement would be indistinguishable from white noise. Hardly productive…
The compressed program is necessarily shorter than the output it's trying to reproduce, unless the output is itself pure noise. Therefore noise and programs must be distinguishable.
> One of the key things about higher programming languages is that they add structure and patterns - in information theory terms: redundancy - to make it easier for programmers to follow what is going on.
Structures and abstractions don't introduce redundancy, they are actually compression. A while loop is clearly more compressed than an infinite sequence of if-statements repeatedly testing the termination condition. An abstraction, like a list or monad, eliminates significant boilerplate that would be needed to reproduce the output of the list or monad.
Adding redundancy makes things harder to follow because you need to keep more state in your head. Adding the right kind of compression makes things easier for humans to follow (obviously there are bad kinds of compression, like alpha conversion to random strings).