andreaferretti

What about noise cancelling earphones? They should allow to listen to music much less loud - any adverse effect is known?

Apparently, according to all the discussion following James Damore being fired, even USA have problems accepting the ideal of free speech fully. I am not sure that Germany is any more illiberal in this respect

You may want to try Nim. It is an imperative language with meta programming capabilities, some functional features and an effect system

Unrelated, but please remember that not everyone here is a native English speaker. It is hard to make head or tails of your comment with all these abbreviations

I think the actual reason why it failed was that it was not Ubuntu at all. When I got mine, I expected to be able to apt-get install everything. The form factor may have been wrong and uncomfortable, but from day 1 I would have access to thousands of applications I was familiar with. I also expected convergence from the start.

It turned out to be a completely separate ecosystem that started from scratch. So, there would be no actual advantage in having the Ubuntu name on it. It was just a marketing move, but it had nothing in common with the Ubuntu I know from the desktop

Nim has pretty decent interop with C++. In general, though, you are right that C is much much easier to interop with

How is Rust type system helpful? If the codegen produces valid Rust, the Rust type system will not give errors. If it doesn't, I'd say it is a bug of the higher level language - and at best the user is going to see a type error of Rust, while working in X, which is not the best user experience.

Really, these kind of checks belong to the frontend.

It's not that writing a GC is impossible - of course it is doable. The issue is that objects written in this hypothetical language will always make use of the GC because they do not have lifetime information in the first place. So the question arises naturally: why bother compiling to Rust if you have to avoid the borrow checker anyway?

In fact, as a compilation target, one wants a language with a lax semantics, not a strict one. This is (one of the reasons) why so many languages compile to C, instead of - say - to C++.

Consider this fact for example: many languages make use of objects allocated on the heap in a way that prevents to know statically when they are to be disposed; then a GC takes care of that dinamically. How are they going to give Rust the necessary information to track lifetimes, when the information is not there to start with? Of course, one can just write a GC in Rust, but how is this an improvement with respect to a GC written in C?

Also - what about typed languages - such as Go - that do not have generics? These are not going to map well to the Rust type system. Or what about lazy languages? Or languages that save the stack on the heap to implement call/cc?

In short, whenever the semantics is different enough, you will not be able to map to idiomatic Rust constructs, and in fact if you don't want to pay the cost of interpretation, you will probably map to unsafe constructs most of the time.

I was tricked by "A thousand pictures on the kitchen floor, Talked about a hundred years or more."

Hi antirez, I think we just have two opposing views about what constitutes simplicity.

I agree that Redis has the rare advantage that one can understand a command at a time, and the cheat sheet is essentially all that is needed to work with it efficiently. Many systems have a documentation that is much more involved, and in this sense Redis is simple.

Still, the reason I find it non simple is that it seems like you (or other contributors) added a random selection of data structures and operations in it. It is difficult to imagine which operations or data structures will be available without consulting the instructions. For instance, there is hyperloglog, but there are no trees or graphs, or sorted maps. And lists have LPUSHX, but no LSETX, nor there is a LLAST operation (I guess it may be for efficiency reasons, but then LINDEX has the same complexity). Sets have SUNION and SUNIONSTORE, but there is no LCONCAT or LCONCATSTORE.

Let me add an example, since I think it highlights the difference in approach we may have. I find the Scala collections very well designed and easy to work with. Each collection has essentially the same (large) set of operations, from `map` and `filter` to more sophisticated ones such as `combinations(n)` or `sliding(len, step)`. Not only that, but usually this operations will preserve the types, whenever possible. This means that, say, `map`ping over a list will produce a list, while `map`ping over a string will produce a string (if the function is char -> char) or a sequence otherwise. Similarly mapping over a bitset will produce a bitset if the function is int -> int, or a set otherwise, since bitsets only represent sets of integers. This allows me to write even very complex algorithms succintly, without needing to consult the API. I find this very simple from the point of view of the user, although the design for writers themselves is pretty complex.

On the other hand, comments such as http://stackoverflow.com/questions/1722726/is-the-scala-2-8-... prove that some other people find it complex and daunting.

In short: I find Redis easy to use (and this is one of the reasons I do use it often!), but not simple in the sense that it is easy to grasp the design.

Can anyone explain the sexual reference? I am not a native English speaker

I think Nim would be ideal for that kind of applications, in particular neural networks stuff. But definitely we are not there yet. I try to explain my reasons in this blog post: http://rnduja.github.io/2015/10/21/scientific-nim/

To get to a point where we have something good to use, though, there are a few libraries to develop. I started working out a basic layer for linear algebra, that is needed in many applications - see http://unicredit.github.io/linear-algebra/

I hoped I would be able to start working on some neural network stuff based on that, but I did not find the time yet...

But this is not at all what you said in the parent post. You said "Rust is in a category of performance that GC languages never reach in practice".

This is not a claim about safety.

Every time I have benchmarked something, Nim has turned out faster than Rust - or anything else, for that matter. Yet, Nim does have a GC. But since one can allocate on the stack, and it is per thread, it is not a bottleneck.

About safety: you can tune it with compile time flags, or even annotate per function what checks to leave.

So, please, stop spreading FUD about Nim.

How does it work exactly? Both languages check things at compile time, but of course in c++ the length has to be known statically. Does idris generate code at runtime for the right size?

This is exactly the use case I ran into most often, and I have designed a small library precisely to do these computations without touching the DOM. If you want to have a look, it is on https://www.github.com/andreaferretti/paths-js

Yeah, the graph chart is buggy, and advertised as such. I have been wanting to improve that for a while, but I did not find the time yet...:-(

Thank you for the feedback! Actually, the whole point of the library is to generate shape information based on data, and the actual rendering is left to the user. So the demo is left as an example, and I don't want to add too many features, because it would make the example more complex to follow

Also, Nim would be a good fit for those domains. Macros and custom operators allow one to write dsl for numeric and scientific programming, and you have complete control over memory layout. There is a gc, but you can tune it very precisely

I happen to find sbt one of the few build tools (together with lein) that are decent enough. Do you have any particular reason for your dislike?

For those who want to try it in a more modern context, there is this recent port of spitbol patterns for Nim: https://github.com/Henry/Nimbol

Yeah, I never noticed this particular reference, not knowing the poem itself

I guess that apart from the "Divina Commedia", it could be "L'infinito" by Giacomo Leopardi. But "If" is pretty well-known, as well as many things by Shakespeare

I may be ignorant, but I find weird that this is reported as the most famous poem of the 20th century in America, and possibly the world. In fact, I had never heard about it at all.

Honest question: is it that well-known? I don't think in Italy it is all that common. Or again, it may be just me...

Done, thanks

For an example of a similar technique in Nim: https://github.com/unicredit/linear-algebra/

If I understand correctly the author remark about the lack of Rust support for value parameters, it seems that it should be equivalent to the Nim feature (static[int]) that has allowed me to write type-checked matrix operations there

Shameless plug: you may want to have a look at my library https://github.com/andreaferretti/paths-js which is made for exactly this purpose. My frustration was that D3 wants to have control over the DOM, but most frameworks let you write components in a declarative style using templates or databinding. So I started paths-js , which takes the data as input and provides an abstract description of the graph as output, that you can then use in your framework to provide rendering. One of the demos that you find on the page I linked is actually made with React

So the author acknowledges the fact tht for many profession, college education is still required, but assumes that his son will get into programming, where it not that needed and hence decides not to save money?

Really nice and easy to use! I have added an example to the Paths.js demo where I show how it can integrate with Vivus to provide animation of the generated paths

http://andreaferretti.github.io/paths-js-react-demo/

Yes and no. In fact, Nim can be used without a GC. Actually the GC of Nim is written in Nim, which certinaly proves the point. Now, it is not really convenient to avoid the GC in Nim, and you certainly do not have the safety features of Rust, but it can be done when needed (and you are still writing in something more productive than C)