Yes as far as I know that's a pretty good reason to use noise cancelling earphones. You could still turn the volume up too high though if you didn't care about it.
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
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
as someone who grew up in Texas, I was wondering WTF UB meant and how so many people seemed to know what it was. RPI I knew because I they sent me literature while I was in high school 30 years ago.
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
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.
Rust most probably will be getting hooks that make it possible to safely integrate efficient GCs. Writing a safe nonconservative GC for rust has already been done, and once these hooks are in place it should be possible to write a good GC. Though for a codegenned language on top of rust you may not need these hooks.
callcc and gc are usually not useful operations in rust. That doesn't mean that its not possible to implement them. The implementation might be annoying to use, but of you are codegenning to rust this doesn't matter.
Yes, some semantics won't copy over. I feel like most would though. Those that don't can often be emulated at the lower level with enough codegen.
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?
The reason I gave in https://news.ycombinator.com/item?id=12148269 applies here too. Clean interop. The ability to freely use a GCd language and smoothly transition to Rust when necessary.
And Rust-as-a-target doesn't necessarily mean you're doing it for the borrow checker. It could also be the typesystem (with the perf and safety of lower level code as a unique bonus). Yes, other, better, typesystems exist, but nobody's saying that Rust is the only language you can do this 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.
No, I mean if you want your higher level language to have a typesystem similar to that of Rust. As I mentioned in the other comment, interop between high level and low level languages usually happens through the medium of C, in which all type information is lost. If your higher level language is compiling to Rust, you can easily add Rusty typesystem features with seamless interop.
I'm not saying Rust's compile errors should ever be shown to the user. I don't think that's what the OP is suggesting either. If rustc errors you should emit an internal compiler error, because your higher level compiler should be producing valid rust code.
I didn't even read that far. It was obvious by here:
SONNET #2
The dirty rusty wooden dresser drawer.
A couple million people wearing drawers,
Or looking through a lonely oven door,
Flowers covered under marble floors.
This is exactly how a computer algorithm would conflate drawer with drawers. There is no obvious theme to this verse, no high level construct.
Every human poem in this example has a high level theme, which is non-obvious to a computer. None of the computer ones do.
Also interesting to compare with less thematically structured work. Probably not the greatest example but what comes to my mind is some of The Mars Volta's lyrics; a lot of it is pretty abstract and stream-of-consciousness and it's hard to really pinpoint a narrative as such, compared to the example poems which were pretty straightforward
"Last night I heard lepers
flinch like birth defects
its musk was fecal in origin
as the words dribbled off of its chin
it said I'm lost
I'm lost
Now I'm lost
Dolls wreck the minced meat of pupils
cast in oblong arms length
the hooks have been picking their scabs
where wolves hide in the company of men
it said I'm lost
I'm lost"
All the computer poems were just rambling and rhyming and weren't really even trying to say anything. A lot of the time they phrased things VERY awkwardly too, to the point of being incomprehensible.
Yep, the human poems would often refer back to an idea or word mentioned before. The computer poems read like something from a good markov generator.
Actually, you can kind of reverse engineer the algorithm behind Sonnet #2. It seems like they first pick a bunch of related words that rhyme (drawer, door, floors, apartment, wall) and then build up the line backwards. The problem is that even though the words are related, the actual lines don't form any single cohesive image.
I answered 'human' for drawer/drawers, because "surely an algorithm would be designed to avoid this kind of thing? surely it'd be better than that... must just be a bad poet"
I got this one wrong. I thought no way a computer would be so dumb to have drawer and then drawers in the next sentence and this was a trick question to get one to say machine. Guess I overestimated the algorithm !
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.
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.
