It was going to be C and C++ killer they said

It was going to be C and C++ killer they said.

What was wrong with this other than it being made by Apple?

Other urls found in this thread:

rust-lang.org/conduct.html
geekfeminism.wikia.com/wiki/Conference_anti-harassment/Policy)
github.com/rust-lang/rust/pull/25640
doc.rust-lang.org/1.2.0/book/dining-philosophers.html
gist.github.com/egonSchiele/5566641
ghc.haskell.org/trac/ghc/wiki/Records/NameSpacing
lpaste.net/75222
twitter.com/SFWRedditImages

Idk but i just started working on an ios app and xcode sucks shit. Swift is ok so far but how does anyone use xcode to make apps?

It's a sloppy gross mix of javascript and python.

It was meant as an objective c replacement, retard

Apple didnt advertise it as such

>the facts are whatever i say they are, not what they actually are

ok, fampai

>not arguing the topic
Stop shitposting

>What was wrong with this other than it being made by Apple?

That's specifically what was wrong with it.

I just started too but it seems pretty simple and intuitive so far aside from having a pretty mediocre workflow. I hate Apple shit but all the good internships want at least a little iOS experience. Plus it gave me an excuse to finally try a hackintosh setup.

Xcode really is a piece of shit. I think the problem with swift is it works well until you need to interact with any of the libraries like nsview and so on. Which are all still written in objective c so it doesn't feel like a new language, literally just a layer of abstraction over all the old objective c shit, a paper thin layer that makes you ask if it's worth the trouble at all.

I used android studio
it's worse

go - shit
D - shit
nim - shit
swift - shit
rust - sjw

we're stuck with c++, boys.

Just because that other languages are shit, it doesn't mean that the postfix incremented meme isn't shit.

sjw's are too stuped to comprehend the beauty of rust. they'll never be able to wield it properly. i think it's safe to say rust users are immune to the sjw bullshit that happens in the FFx community

btw i'm a rust user and i hate sjw's

C++ is okay too, but rust has all the good stuff of it build in, and more

yeah that's like 4 years old dude, before even swift 1.0

i'm a sjw and i hate rust users

It's a "yet another" that brings nothing valuable to the table

For the people who are capable of making meaningful applications instead of dmenu tier shit, the less elegant parts of an older language aren't even speed bumps, and "elegant" languages from hipsters and elegant languages from academics are mere novelties that don't offer significant benefits outside of forum circlejerks

On a forum circlejerk if it's not stdlib it's not there
In real life with real programming if it's not in the stdlib you just use another fucking library who fucking cares

>It was going to be C and C++ killer they said.

Nobody said this.

>they'll never be able to *weld it properly.

The core contributor to rust is a SJW (surprise he is also a ruby dev)
Not to mention Rust is a Mozilla project, mozilla who fired their CEO because the SJWs inside the company wanted him dead

Rust which includes this
rust-lang.org/conduct.html (where you will find it references directly from geekfeminism.wikia.com/wiki/Conference_anti-harassment/Policy)


Rust which did this
github.com/rust-lang/rust/pull/25640

>For the people who are capable of making meaningful applications instead of dmenu tier shit, the less elegant parts of an older language aren't even speed bumps, and "elegant" languages from hipsters and elegant languages from academics are mere novelties that don't offer significant benefits outside of forum circlejerks

I guess this explains why everything's written in COBOL and assembler these days.

The distance between legacy cobol and C++ is has no functions vs. functions and much more

The distance between C++ and swift is syntax that's friendly to worse programmers that make up a less significant section of the market

The distance between C++ and rust is novelty features that C++ users have anyways with collections of macros and libraries like boost, and some barely-features that are just more "elegant" ways to write without loops or blocks of conditionals.

doc.rust-lang.org/1.2.0/book/dining-philosophers.html

that's a closed pull request, meaning it was rejected

>sjw's are too stuped

C++ doesn't have lifetime notations or borrow checking, doesn't guard against reference invalidation, doesn't have constraints on type parameters, doesn't have ADTs or support variants for complex types, and has dumb 70s style copy-and-paste in place of a module system or hygenic macros.

The utility of all of these things has been proven for the last few decades in the form of problems caused by bugs in widely-used C++ programs or mind-numbingly obvious design choices in every language that isn't beholden to C's legacy mistakes. If you think they're "barely-features", or "elegant" with scares quotes added, you've succumbed to the blub paradox. Sheltering yourself from better alternatives and advances in technology is one thing, being complacent and self-assured about it is worse.

>Monsieur Foucault should have 4, 0 as arguments, but instead, has 0, 4. This is what prevents deadlock, actually: one of our philosophers is left handed! This is one way to solve the problem, and in my opinion, it’s the simplest.
Is this the part where I'm allowed to roll my eyes?

That's not a “solution”, it's a hacky work-around.

Meanwhile in Haskell, we actually have good solutions to deadlock

gist.github.com/egonSchiele/5566641

I hope C# wins against Swift and all this other shit. C++ is also fine.

Whoa cool, maybe next they'll have a solution to record fields shitting all over the global namespace. Wait, nevermind, who wants crazy academic wank like that in their language?

>Whoa cool, maybe next they'll have a solution to record fields shitting all over the global namespace.
There are like 10+ solutions to this, ranging from lenses to heterogeneous typed records.

Also, there's no such thing as a global namespace in Haskell. I'm beginning to think you don't even have a baseline understanding of it but are just regurgitating memes from hn written by others with equally poor knowledge of haskell

Why none of the new languages have easy interface for calling c++?
D has but even that is somehow really gimped.

swift is way better to write in than c#

tuples are encouraged, option types are encouraged, etc.

not to mention it has no VM

IntelliJ software is amazing.

because the point is to move on from C++

yeah, C, and C++ got us into space, but it's not gonna get us to another galaxy. we need new languages to take full advantage of quantum computers, don't you see?

>but bugs

In short, git gud.

>IntelliJ software is amazing.

yeah, if you're used to writing your software with a hairy turd and a whiteboard, and IntelliJ is your first IDE

>but it's not gonna get us to another galaxy
I doubt anything's gonna get us to another galaxy, unless wormholes really exist.

yeah but still, quantum computers could exist within the first half of your lifetime

but why not make a library for c++ then?
It seem to be a lot easier to maintain than a new meme language only a few people will use (as moving away from existing code is a pain nobody wants)

Consumer-level, quantum personal computers? I can only hope, but the clock is ticking.

>we need new languages to take full advantage of quantum computers, don't you see?
Have we actually found anything at all that you can do with a quantum computer besides factorizing integers?

That's what nearly all criticism of Haskell seems to be.

git lernt

The company is called JetBrains, also I agree.

Because a lot of what we already have isn't applicable to quantum computing, and quantum computing requires (should require, as I believe errors can be quite catastrophic) a type system that isn't expressible in C++.

Most likely, quantum computers will be marketed as coprocessors, like GPUs. In that case, there will be something similar to OpenCL.

>and quantum computing requires (should require, as I believe errors can be quite catastrophic) a type system that isn't expressible in C++.
C++'s type system is turing complete, it can express your QC constraints.

Well, it sort of can, through monads. It's far too weakly-typed to be taken seriously for that, though, and not to mention the syntax would be horrible (compared to Haskell, which has a monadic QC EDSL which can take advantage of its syntax).

I don't see any reason to try and retrofit C++ to quantum computing. You claim maintainability of a new language to be an issue, but anything would be more maintainable than the clusterfuck of C++.

The new approaching languages have nothing to do with quantum computing.

>There are like 10+ solutions to this

I don't even know where to begin to tell you what's wrong with this, but just to give you a nudge in the general direction it probably has something to do with having a dozen competing and over-engineered library solutions to getting a field member from a struct.

>Also, there's no such thing as a global namespace in Haskell.

Maybe you should tell that to the GHCi developers who refer to it as such when describing the present state of the fuckup they're trying to spitshine:

ghc.haskell.org/trac/ghc/wiki/Records/NameSpacing

They'd probably appreciate the brushup on terminology, being that they're without a baseline understanding of Haskell and all.

And? Neither does C++.

You're assuming QC can be expressed as a monad. Isn't that a pretty big assumption?

I brought up monads because that's usually how linearity is encoded in languages that don't support it natively. QC is heavily based on linear logic (i.e. a linear type system).

That article only seems to refer to the global namespace of Agda terminology.

but maintaining C++ isn't the issue.
You have the language and then you have the libraries for it.
The libraries for it is what could be the clusterfuck to maintain.
And the reality is that not all people will use all features of the c++ language.


C++ isn't more of a hindrance with quantum computing than the alternatives.

I'm saying make a new language for QC. It's already such a massive departure from classical computing that the alienation factor of a new language is a non-issue.

>that's usually how linearity is encoded in languages that don't support it
Really? Do you have any examples of this?

>I don't even know where to begin to tell you what's wrong with this, but just to give you a nudge in the general direction it probably has something to do with having a dozen competing and over-engineered library solutions to getting a field member from a struct.

A: Waaah, there are no solutions to this. Please give me one!
B: Here are 11
A: Please don't give me the burden of choice! Can you take power away from me so I only have one way of doing things? Thanks

I bet you're a python programmer

What do these "new" languages add to the table?

Everywhere in Haskell. For example, the IO monad basically is isomorphic to passing around a linear resource that represents the "outside world" (in fact, in GHC it's implemented as a special state monad).

If you consider a monad as a region, that region's lifetime is essentially the lifetime of a linear resource, and that resource has unique access due to the sequential nature of monads.

It's not a great way to do it, and it complicates usage scenarios that aren't essentially a stack, but it's all that's possible most of the time.

Being based on a foundation that is appropriate for QC (type system, syntax, back end, etc.) instead of trying to shoehorn it in to Von Neumann languages?

>C killer
Why kill something that is perfect?

>Being based on a foundation that is appropriate for QC
Nobody has claimed to do that and no programmer is searching for such language.

Concurrency is the new meme but they are not doing anything new with it.

>nobody had claimed to do that
There are several QC-specific languages out there. Of course, they don't run on real quantum hardware yet.

>no programmer is searching for such a language
Gee, I wonder why.

>A: Waaah, there are no solutions to this. Please give me one!
>B: Here are zero. The language mandates you access record fields using helper functions which occupy the same namespace as regular code because we screwed up real bad some two decades ago, so basically everything's real retarded and this is the well-established practice in our language. Optionally, you can use these laughably overwrought lense modules employed by a thin minority of the language's devoted neckbeards which will make your code yet even more idiosyncratic and obnoxious than regular Haskell code already is.
>A: Wow, that's dumb
>C: I bet you're a python programmer

Oh, I thought you were talking about actually embedding linearity *in* Haskell (which is still decided non-linear)

Yeah, monads can be used to enforce a consistent ordering of a access to a single resource, but it can't be used to e.g. express a linear computation in which every label will be used exactly once.

For that I think you need other embeddings, like this embedding of linear logic: lpaste.net/75222

It was made by Apple.