191–200 of 311 posts
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.
So his point stands. People preferred Java to Smalltalk and it thus didn't become mainstream.
Which is quite different.
Earlier quoted context omitted.
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 h…
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 ignore the major difference between Rust and Nim in your little list of differences: Rust does not require a garbage collector (there is no GC used or implemented in the standard library). Lastly, unless you've participated in Rust development (I encourage everyone to do so, it's fun) it may be difficult to judge what the influence of the 'corporate' backing is... you're actually talking to a volunteer (no association with Mozilla) member of the Rust core team right now.
Earlier quoted context omitted.
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.
(Also, I believe it introduces a lot of data dependencies, getting in the way of the out-of-order execution of modern CPUs.)
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…
> 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…
Earlier quoted context omitted.
Were there any code examples provided that show how to easily trigger races & deadlocks? I mean, the Go team needs to be aware of these problems and provide a fix or something.
> show how to easily trigger races & deadlocks? I mean, the Go team needs to be aware of these problems and provide a fix or something. You mean file a bug like "issue #1935 -- stop sharing memory between goroutines" (I just made it up to be silly there is no such bug report) In other words, they have explicitly designed in the ability to share memory between goroutines. You can certainly file an issue or bug report…
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…
As a separate comment I want to address your final paragraph. Rust definitely provides a solution to buffer overflows. Specifically, all data structures that represent buffers of any sort always do bounds checking. This includes using the indexing operator (`foo[idx]`) on a fixed-length compile-time array. It's possible to skip the bounds check but you have to do so very intentionally, using an `unsafe {}` block (whi…
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.
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"]
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…
>(2) large yet maintainable systems I have never seen anyone suggest Go for large systems or seen any open source code that even comes close to enterprise system size. I would argue that Go is inadequate for large systems compared to the JVM languages. The absence of operational tooling, exceptions, declarative annotations, runtime management etc all make it much harder to support and scale to large numbers of develo…
Saying it's not for large systems is just showing ignorance of what it's already being used for.
Earlier quoted context omitted.
I've written in both paradigms and I mostly agree with the Go team. That it blows your mind blows mine, and I suppose it's good that we have these choices so we don't have to agree. Could you show me a code snippet of maps and filters used that you believe is more readable than for loops? Maybe I'll get a laugh out of that. :)
let descending_squares = range(0u, 5u).rev().map(|x| x * x).collect(); versus: let mut descending_squares = Vec::new(); let mut i = 4u; loop { descending_squares.push(i * i); if i == 0 { break } i -= 1 } (Note that if you try to use a for loop here you will infinite loop due to unsigned underflow.)
Also, I can count the number of times in my 15 years of professional development experience that I've wanted to count down to zero using an unsigned int as the index... never. Which is not to say that the declarative isn't nice, just saying that the example of the infinite loop is not exactly compelling.
Earlier quoted context omitted.
You need a collect on that first example, you end with a Vec in the second, but an Iterator in the first.
Oops, you're right. Fixed.
Sorry, that's not really fair. I'm sure the compiler would have caught that when you tried to feed it into something that wanted a vector (or would have not cared if you were just iterating over it).
To be honest, I think Rust has a lot going for it. I just think Go has a lot going for it too... they're just different things. Which is fine, because if everything were the same, the world would be a really boring place. :)