Rust 1.0 beta is released!!!

http://blog.rust-lang.org/2015/04/03/Rust-1.0-beta.html

Ulrik Sverdrup <root@localhost>

LOL.

Everything > rust

I'm tired arguing with these autists thinking their Haskell/Lisp/Rust/etc is going to take over the world, create great software in N years, solve everything bad with programming and revolutionize computing. I'd think i'll bump these "superior language" threads after 10 years, just to showcase their delusional mindset.
Oh, and i'm gonna read whats /prog/ thought of Lisp/Haskell future 10-9 years ago for my amusement as dis.4chan.org still works. I'll start with 2005 and read all threads which have language names.

>>4
I don't care about the world or revolutionization, I care about me having a better language to masturbate my hobby projects in.

I also care about linguistic masturbation and creating new languages for the sake of creating new languages. As for the world, it can continue sucking big Stroustrup dick forever for all I care.

>>6
The languages you masturbate to are all written in C/C++.

>>7
Even if that's true (what the fuck is "C/C++" anyway?), why should I care? The very purpose of creating new languages is so you don't have to use C or Sepples.

>>8
You should care because its hypocrisy, if the autists really wanted something safe and pure they would write the languages in Ada at least. But they choose the most raw, buggy and fragile language that exists. The language they hate the most. The one they supposedly won't deal with.
Yet these master autists deal with it, they write in it daily just so peasant autists like yourself would feel good about yourself. Think about it: Simon Peyton Jones is writing GHC in what?

>>9
GHC is written in Haskell, the runtime system is in C.

Also, the reason shitty buggy languages are used to implement better languages is that the OS infrastructure which is unfortunately written in them already.

Still, there are wrappers and bindings so that the C or Sepples exposure may be minimal. E.g. http://www.stephendiehl.com/llvm/

Anyway, languages like Idris or Agda are implemented in Haskell, so your star argument is actually pretty stale.

>>10

OS infrastructure which is unfortunately written in them already.

Bullshit, you don't have to use C to interface to the OS.
Thats the weakest argument ever. All sane languages have OS interfaces.
>Idris or Agda are implemented in Haskell
Doesn't dodge the main part, Haskell is based on C/C++. The runtime is the most important part, and the Haskell GHC is written in is just using the runtime.

shutdownHaskellAndExit(exit_status, 0 /* !fastExit */);

shutdownHaskellAndExit(exit_status, 0 /* !fastExit */);

>>10

Anyway, languages like Idris or Agda are implemented in Haskell

Did he confused Agda with Ada?

>>11
Most languages must use C in their runtimes because the OS ABI they must use is complex, and the only reasonably complete implementations of same are written in C or C++. Look at libffi for an example of what this means.

>>15 libffi bindings don't force you to go low-level. The real problem is Haskell is shit at low-level tasks and runtime written in it would be incredibly slow and using tons of memory.
Just look at this http://bbs.progrider.org/prog/read/1428012611/32

>>16
The idiot sees monads @ the idiot thinks they're slow.
Guess what, monadic code can be compiled as efficiently as C code.

>>17 yeah, I can already see the code compiling into a single JMP just like C.

>>18
Exactly.

>>16

ffi bindings don't force you to go low level

No, of course not. They do encourage it, though.

The biggest impediment to widespread adoption of new languages is the simple fact that, in the real world, any code written in the new language will eventually need to interface with code written in older languages, and cross language binding is a very painful task. Look at what has become of COM, Java, CLR... all touted as solutions to this m x n explosion of language bindings, and all disappointments because all they ever really accomplished was to codify interface requirements for a superset language (C++, Java, or C#) to the detriment of all other languages.

At least with C, everyone has pretty much recognized that this kind of effort is futile and tries as much as possible to solve it elsewhere. Hence, shitty but fast C ABI where you really need it and slow but robust data oriented IPC where you don't remains the way to go for useful interoperable software.

>>20
At least Java and .Net have mostly killed off that problem within their respective platforms. C only avoided that problem by becoming the common ABI.

>>21
All three solved the ABI problem "within their respective platforms". The problem comes when you need to add a new language to any of said platforms. Defining an ABI for a single, highly expressive language is hard enough; defining one for multiple dissimilar languages is verging on impossible. This is not a big problem for C because C is barely a language to start with.

Microsoft had to make serious changes to CLR to add support for languages like Python; imagine what adding support for Haskell would be like. Meanwhile, Haskell interop with C is already usable.

If you app in Rust, you take cocks in the ass.

>>23
Sorry, I program in Rust!

>>22
They didn't have to change anything. They could have written a python interpreter in C#, compiled it, and glued it in with the rest of .NET. The only problem would be efficiency. It's because python is by it's very nature a shitty, inefficient language that can't even get rid of the GIL. If Haskell actually had people who wanted to write a good compiler instead of circlejerking over monads and Maybe, it could be very efficient. Instead we have 1MB hello world programs. Maybe Microsoft could scrounge up a few competent people if you beg them hard enough.

>>25
You are grossly oversimplifying. Microsoft not only had to add a performant (this is not easy or optional as you seem to imply) runtime system, they also needed to take care to ensure that it could exchange data with other CLR code without violating any typing rules.

The latter would be even more difficult in the case of Haskell because its type system is more sophisticated than the CLR model can even express. Most Haskell code that interfaces with CLR will need to validate its inputs or be explicitly marked as unsafe... which brings me back to my original point. If you need to break your type system to interoperate you may as well just use C + platform ABI because the of sophistication there at least minimizes the possible pitfalls on the C side of the interface.

>>24
Rusted iron dildoes then.