codingbinary

Same here. I thought that's pretty normal. The generic one looks pretty...normal to me. The clang version iss too much compiler voodoo and kinda makes it less readable.

Back when MOSA got created, we were aiming for a pure approach. For example, we were trying to use as few intrinsics as possible and a mostly architecture agnostic approach.

Furthermore we also focussed on Mono compatibility (that was way before CoreCLR came out).

Source: Ex co-creator of MOSA

I'm just wondering how the same statement (if the data would show it) would be perceived if it would be said for males.

Studies could also show that there is a higher chance for mothers to quit along half the way due to child-related reasons (made up studies for the sake of argument). That on the other hand would be considered misogny. And I'd take it with a grain of salt as the sample sizes are vastly different.

That being said, do you have a link somewhere? Would really be interested to read that.

Plus, wouldn't that contradict the whole idea of "we are all equal. Men are not better than women" but suddenly stating the opposite is totally fine?

The data on this would really be interesting.

Which is true, because your child should be your #1 priority. Regardless of your gender.

Wow, they didn't have SSA in there yet? That's quite a surprise as, as far as I understand, SSA is pretty common nowadays in compiler techniques. Even for the MOSA compiler we had this.

"Homogenous european states."

Did I miss something?

Then that's the reason. The config is a dylib, so I have to force it into using jemalloc, which I cannot do when using stable.

But that wasn't always the case, right? I think around the time of 1.3/1.4 jemalloc was not the default.

Really? Last time I checked it still didn't work. Will have to try when I get home.

The problem was that the config is compiled into a dynamic library and gets passed the config struct. The old alloc method kind of died on me when the dynamic library was trying to alter that struct. So I had to enable jemalloc to keep it from crashing.

Yep, exactly that killed my window manager on stable. I _have_ to use nightlies now, because I need the alloc_jemalloc feature.

The one is on a language level, the other on an application/framework level.

Type Erasure is the reason you can't use builtin types as generic arguments. And in a lot of cases it forces you to cast.

And as type erasure happens very, very early in the compilation process, you lose a lot of static type information the compiler could act on or give you warnings.

And don't forget Java's type erasure. Still wondering how they could actually call that a FEATURE.

29, why?

That is exactly the reason I stopped reading halfway through. I couldn't take any more of his narcissism.

Same here. I couldn't care less about Hamlet or other works by Shakespeare. And I cannot recall any of my other friends having _any_ tendency towards Hamlet at all.

Ah that brings back memories. Around the same time Midori was announced we started working on the MOSA Project[1], with the similar goal to create an operating system and accompanying toolchain, completely written in C#.

Really looking forward to the articles.

[1] http://mosa-project.org

According to that logic we can also go ahead and ban all products that rely on the chemical element Bromine.

Because hello_world returns an IronResult, which in turn is just a simple Result type from Rust. Note that the status::Ok is different from the Ok(...).

Iron::new expects a function that returns a Result type, so it has to be there.

That statement isn't constructive either and also tends towards zero signal. Even if "du-jour" languages don't end up being used in production, some of them add really nice new concepts/ideas. Take for example Rust and its compile time borrow/ownership checking.

Judging by your argument, we all should've sticked with C and wouldn't even need C++.

Taking a look beyond the current horizon sometimes ends up being useful.

What you want to get down to is the intrinsic dimensionality. Go below that and you start discarding useful information.

That depends on your clustering algorithms. If it is for example based on shared-neighbor information, then you end up with the same clusters as you did before scaling.

And in your example, I get: (A, B) < (B, C) < (A, C) before and (A, B) < (B, C) < (A, C) after scaling.

So the order is preserved. It really depends on your clustering algorithm. DBSCAN for example could end up with a different result due to its epsilon-range parameter.

You can get around the curse a little bit by using shared nearest-neighbor methods, but that only helps you a little bit.

Although, the curse of dimensionality is no precise. The real problem is due to intrinsic dimensionality. There's a nice paper on how to estimate it http://www.nii.ac.jp/TechReports/14-001E.pdf

How do traits limit you? Could you give an example?

Just tested it. It fails all of the above and just returns a websearch.

Can't agree more. XMonad is what I based my Rust window manager on. Nice, clean, easy to understand code base. No other window manager gave me so many insights into how a WM works.

The switchable layout is a nice touch. Programmable layouts would be nice. And a version without any key labels.

And as soon as everyone starts using s/he, bigender people get annoyed that heshe wasn't used. It's language...it's difficult to get everyday usage "normalized" into a different direction.

I can only speak about the Rust side. Seriously, pick it up. It is more than a replacement for C. You get a total replacement of C + a loooot of extra stuff, like no null pointers, memory safety, C compatibility for FFI, iterator and list comprehension goodness, and just a lot of good practices. At least for me, Rust is the perfect mix between C and Haskell. YOu get the low level stuff of C, and the expressiveness and joy of Haskell, without all the brain-hurt from Haskell.

Side note: I do love Haskell, but let's admit it, the learning curve is pretty steep once you hit monads/comonads.