251–260 of 311 posts
Earlier quoted context omitted.
> 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.
Haskell is an academic language with a focus on language research rather than pragmatism. One sentence. Is that sufficient?
Earlier quoted context omitted.
Oops, you're right. Fixed.
And that's why I like go. 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 woul…
Earlier quoted context omitted.
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 cert…
This isn't just a jump, it is a branch. Especially when the body of the loop is 6 instructions, adding an extra branch is going to be noticable.
> Also, modern compilers could optimize the checks away if they aren't used
This is equivalent to the halting problem, and most code will not be able to optimise them away. Suggesting otherwise is invoking "sufficiently smart compiler", which is invalid.
In any case, you haven't addressed the problem of missed optimisations (especially vectorisation) caused by having to maintain semantics.
> It's certainly not the problem of the CPU's.
Yes, it partly is: the data dependencies and linearisation caused by checking the CPU flags is bad.
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. I also said "or one of its direct descendants" (like Agda or Idris in all likeliness). > To wit, Lisp never became mainstream Clojure doesn't count? And the good parts of Perl, Ruby & Javascript are essentially Lisp without the homoiconicity.
> Clojure doesn't count? Perfect example. Clojure != Lisp. But it is a pretty obvious descendant.
Earlier quoted context omitted.
Re 2. as my comment states, we have tried to fix it, but we cannot: the administrator of that server is powerless. 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…
Regarding "ignoring the major difference", I explicitly tried to not compare them too much - because I know too little of both. Now I know more about Nim, but not Rust. Regarding GC, its not fully "required" in Nim either, but yes, the GC is a big differentiator and probably one of the things making someone prefer one over the other.
Earlier quoted context omitted.
> 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 wit…
c := a + b
Using literals is not a useful comparison because there is no confusion about types in that case.
Earlier quoted context omitted.
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?
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…
How does Rust's borrow checker cause a slowdown of sequential code? It's a purely compile-time construct and allows for the elimination of a GC, so it's actually a net win in code execution speed.
It doesn't, it was just grouped with the other two. But immutiblity-by-default could lead to slowdown.
Earlier quoted context omitted.
> Clojure doesn't count? Perfect example. Clojure != Lisp. But it is a pretty obvious descendant.
"Lisp" is a family of languages and Clojure is one member of this family.
Beyond that, I'm not quite sure Clojure counts as "mainstream" yet. According to the TIOBE Index, it doesn't even rank in the top 50 languages. Heck, the top 20 includes R, and Dart, neither of which I would call "mainstream" (I'm actually really surprised at how high R is ranking). I don't know how significant that is, though the TIOBE Index is measuring "number of skilled engineers world-wide, courses, and third party vendors" and that seems like a reasonable approximation for "mainstream" to me.
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…
The way structs are supported, it feels much more like objects than C structs. I prefer it much more than say, OOP classes. It's something you need to immerse yourself in to appreciate, IMO.
What about "user created objects" would you miss?