Hacker News Reader

Comment by nickysielicki | Hacker News Reader

Too little too late. Apple could have got my attention if they had done this from the start, but at this point I find it hard to get excited about this. Half the reason I find myself drawn to a new language is the culture and community surrounding it. You might think this seems silly at first glance, they're programming languages, not fraternities. But hear me out.

Golang is a pragmatic crowd. Go into #go-nuts on freenode, you'll notice that discussion rarely deviates from solving problems. Many links to the go playground. Go, from the beginning, shaped their community in this way. Consciously? Who knows. But the community turned out the way it did and I believe that's a result of their start.

Haskell is a computer scientist crowd. People write in haskell because they enjoy the functional paradigm and haskell is a purely functional language. Discussion on freenode? Very dense. People are expected to grasp topics easily and the community initially gives everyone the benefit of the doubt that they are capable of understanding it until they ask for more help.

When I look at swift, the only thought I have is that it is the new iOS language. I don't believe they'll be able to deviate from that. I don't see myself making iOS apps, so I don't see myself every writing a single line of the language. When I first looked at swift, my impression was that it was a wierd and somewhat-functional language that had a few unique things. Maybe I would have taken an interest in it. But at this point, I don't want to have to wade through a bunch of iOS specific questions to get what I need. I don't want to have to deal with being a beta tester for their linux implementations. I don't want to use the language when I'm probably going to be using it in a vastly different way than the rest of the community is. My interests are going to be second class.

It's not necessarily set in stone, but I think it is. In a world where there's a new language every day, I just don't see why I'd go with swift.

View on HN

Hey, look me up in a year and explain why you were wrong.

Go has been out for 6 years and has less than 10,000 questions on StackOverFlow: http://stackoverflow.com/questions/tagged/go

Swift has 37,000 questions in its first year: http://stackoverflow.com/questions/tagged/swift

I'm a fan of Go. I built my websites in it and I've written a few small apps.

However, you really are overlooking how much of a difference the bigger Swift community will be.

All bets are off if Google officially supports Go on Android.

Anyway, 1,000,000 Swift developers will change everything.

Of course, all bets are off once Go becomes a first class citizen on Android.

This cannot happen soon enough.

I'm not saying this because of anything to do with Apple's Swift announcement. I'm saying this because it'll be a huge benefit to Android.

> I'm saying this because it'll be a huge benefit to Android. reply

How so?

The language has a weaker type system than Java, doesn't support exceptions and requires error checking every other line, has very poor tool support (because the compiler was not designed with IDE's in mind).

Except maybe add a few developers who refused to write code on Android because of Java, I really don't see what Go would bring to Android.

You shouldn't be getting down-voted. The idea of anyone rewriting the entire Android Framework in Go when you can use better languages like Kotlin, Scala, Groovy, Clojure is asinine. Go will compile to Android architectures so you could do shared code in Go between iOS and Android like a C++ lib. That makes sense.

Did anyone say anything about rewriting the entire Android Framework? Nope. It was about Go becoming a first class citizen on Android. That doesn't mean it can coexist with Java for someone who needs a fancy IDE.

It already IS. You can compile Android NDK libraries with Go today. It isn't that useful because the NDK isn't hooked up with the Android framework which means you don't get lifecycle events. There was a whole Android framework written over the past decade or so in Java that abstracts this.

> That would leave you with Kotlin/Groovy/Clojure/Scala for the view layer of your Android app if you choose not use Java

> when you can use better languages like Kotlin, Scala, Groovy, Clojure is asinine

You seem to be piggybacking an aspiring JVM language (Kotlin) on top of three other alternative ones that have already made it (Scala,Groovy,Clojure). Because that trick's already been done before with them (i.e. Groovy piggybacked on the quality of Scala and Clojure), it makes your list of examples of alternative JVM languages seem disingenuous.

Sorry about that. They all have tools that make them work on Android. Kotlin is reasonable option imo. It doesn't effect app startup and runtime size is so much smaller compared to the others. Clojure Android adds 3 seconds to startup time for example. I haven't used Scala so I am not sure how nice it is for Android.

Type system strength does not correlate with language adoption. Else, nobody would use C, Python, PHP, Javascript, Perl, Ruby ; C++, C#, Java would be outsiders and almost everybody would use Ada, Haskell, OCaml.

I agree with your last sentence, however.

Unless all those devs with apps on Android want to port all their code?

While that would be nice, every indication is saying that Google has no interest in this right now.

OTOH There are 70k Go repos on GitHub vs 31k for Swift (vs ~5k for Rust)

- https://github.com/search?l=go&q=stars%3A%3E-1&ref=searchres...

- https://github.com/search?l=swift&q=stars%3A%3E-1&ref=search...

- https://github.com/search?l=rust&q=stars%3A%3E-1&ref=searchr...

Swift repos will pass Go within 12 months. I think most iOS developers were holding off on Swift. Heck, Xcode and Swift, etc only became usable earlier this year.

Most people aren't writing open source iOS apps.

No but there are a lot of components.

The numbers of results there vary wildly upon refreshing the page repeatedly. I'm getting ranges of 39k-79k for Go, 12k-42k for Swift, and 3k-9k for Rust. Also, in the absence of knowledge of what precisely is being measured (e.g. does it include forks?), we should probably only interpret these numbers as order-of-magnitude comparisons.

I think that doesn't support your hypothesis--- 31k in one year compared to 70k in 6 years implies a lot more momentum for swift than go.

I think part of the parent comment's point was that Swift does/will have a lot of users. Right now those 10,000 Go questions cover a lot of server related issues; the 37,000 Swift questions are almost completely iOS questions.

If I started writing an HTTP server in Swift the day it comes out I won't find much help but I'll have a mountain of unrelated answers to filter. Essentially Swift's adoption for iOS apps doesn't help and might hurt efforts to use it elsewhere.

Look at Object-C: extremely common writing software for Apple; almost non-existent elsewhere, despite the fact that it has never been limited to Apple.

Objective-C never caught on outside of the Apple/NeXT ecosystem because its biggest advantages were in the application frameworks, not the language itself. By the time iOS made Objective-C popular there were entrenched alternatives in the C++, Java, and .NET ecosystems. Swift is facing the same challenges, but against a newer generation of competitors that are much less established. It's probably still an uphill battle for Swift to gain outside adoption, but it's not climbing a cliff.

Not to mention, Swift the language itself, which is basically Rust with arguably an easier memory management model (all ARC) and Scala-like pragmatism (an OOP model built-in). Coming from ObjC, developers are showing a high level of interest in Swift. I might look it up when it comes out for Linux!

I have carefully compared the two languages and I do not see more similarity than between Go and Swift or any other language. You have yourself cited the different memory management models, and this is the main characteristic of Rust. The sole common feature is the use of LLVM.

Why would I ever care about Go for Android when I can write apps in Kotlin? Kotlin is fully interoperable with Java. I don't have much experience with Swift but Kotlin is so nice. It has the best features from numerous languages such as Ruby. C#, etc. It's being made by Jetbrains who makes the the core of Android Studio so it will have support. Kotlin is also nearly as fast at runtime as Java with a tiny 200kb runtime. Almost all the magic happens at build time so your build time will be a little longer. Kotlin also works with any existing Java library, even annotation processing libs.

Again, why would any Android developer choose Swift? Kotlin also runs fine on the server and it even compiles to Javascript.

If I were a startup doing an iOS, Android, and a backend I would do either Go or Rust on the backend. You will be able to distribute a native lib with your Android or iOS that shares network and model logic. Go and Rust both are planning on supporting cross compilation to iOS and Android.

That would leave you with Kotlin/Groovy/Clojure/Scala for the view layer of your Android app if you choose not use Java. Which is a good idea since there is no indication from Google Java 8 will be supported which means no lambdas unless you use an alt JVM language. On iOS you write your view layer in Swift. Both apps use the shared binary library.

If you use Scala for your view layer, why would you even want to use Go for your back end?

Very true. I am starting to not see the point of Go. It's about the same performance as the JVM languages and the JVM is just as easy to deploy. On the JVM you get to choose between Clojure, Scala, Ruby, Groovy, Kotlin, and more. JVM is just as easy to deploy as a Go binary too. Personally, I plan to stick with JVM languages plus Rust.

Here is how to see the point of Go:

Open the rosettacode web site. Choice any algorithm you are familiar with. Place Go version and Java version. Compare the number of words and lines.

Compare the Maven hell with how Go solves the same problems.

So, a more succinct Java, that can't leverage the JVM ecosystem? Why is that better than Scala, which can also be more succinct than Java, but can leverage the JVM ecosystem?

Go is enormously simpler than Scala.

(I also don't agree that the deployment story for the JVM and Go are similarly complex, but that's a different argument).

I bet my Clojure or Groovy version will be simpler. I agree Scala is super complex :). Maven does suck. Gradle wraps it and does not suck. Probably the best build tool I have ever seen.

> Why would I ever care about Go for Android when I can write apps in Kotlin

Power consumption.

I guarantee you could write a more power efficient app using the Android SDK versus Go in the NDK.

Since Android Java is compiled to native code on installation time, I don't see any benefit using Go in terms of power consumption.

I found this comparison between Swift and Kotlin interesting, and the point that it would make switching between Android and iOS development easier:

http://blog.translusion.com/posts/swift-is-kotlin/

Kotlin is positively awesome, but when I tried it (admittedly last year) it didn't seem ready for production yet. It worked all well as long as stuff was kept simple, then I used Realm.io, wrote some unit tests and got all sorts of NoClassDefFoundError exceptions, dexmaker errors etc. Long story short, I couldn't fix it. As I said, it's been a while. I hope things have been improving and continue to improve. The language itself is superb

It's pretty damn closed to 1.0. They just released M12 which adds support for interop with Java libs that use annotation processing such as Dagger.

With the just released support for annotation processing Kotlin is now working with e.g. Realm.

I've just been playing with it some in the last couple of weeks. I get the impression that they're still iterating pretty rapidly on it - at least partly because the official practice repo uses trait all over the place, which they apparently deprecated and changed to interface.

I will say that it It looks very promising so far, and seems to have the best of C# and Ruby, assuming you're sticking with compile-time type checking, plus a few more tricks besides. I'm not that up on JVM languages though, so I'm not sure that it's definitively better than any of the other choices.

It seems to me that Dart would be a more obvious choice should Google choose to push a new application development language for the Android platform. It's closer to JavaScript and has more GUI/visually-oriented libraries. Plus, it's a no-brainer to box such apps in a HTML5 container for iOS/Windows.

> Anyway, 1,000,000 Swift developers will change everything.

All of these objective-C developers changed nothing for non-ios crowd. Why would swift be different?

Linux support.

GCC has supported Objective-C since at least version 2.0, released in 1992

(based on http://www.informatica.co.cr/linux/research/1992/0222.htm)

This is very very true. I remember trying to look into Objective C years and years ago and trying to get somewhere on my Linux box but due to the lack of standard GUI libraries etc. it seemed a non-starter.

>Too little too late. Apple could have got my attention if they had done this from the start, but at this point I find it hard to get excited about this.

That's just like your opinion man.

If Swift is Open Source it's gonna be a huge thing, for two reasons: (a) it already attracts millions of developers because it's the suggested language to develop iOS apps in, and (b) it's a nice modern language that plays in a very hot niche (with languages like Go, Scala, Rust etc).

>When I look at swift, the only thought I have is that it is the new iOS language.

OTOH, tons of people and HN and elsewhere expressed their liking for the language and how they wished it was open sourced so they can use it elsewhere too.

Have you tried Go, Scala or Rust? All of those language are from their separate leagues, how can you compare swift with them?

In my experience, in the wide world of programming languages Rust and Swift are really not very far apart. Swift's designers even cited Rust as an influence.

> Swift's designers even cited Rust as an influence.

Specifically, http://nondot.org/sabre/

     > Of course, it also greatly benefited from the
     > experiences hard-won by many other languages in the
     > field, drawing ideas from Objective-C, Rust, Haskell,
     > Ruby, Python, C#, CLU, and far too many others to list.

...you can say they looked at <add your favourite language here> as an influence.

It seems to me that Microsoft and Apple are -- quite consciously -- in a war to own the next ubiquitous language (the precursors being Javascript, PHP, Java, C++, C, Fortran, and COBOL). This is the language that Comp Sci students will spend their time in, that kids and hobbyists will tinker with, and so on. It's a huge deal -- the stakes are enormous.

C# was in good shape and got better with Microsoft's recent cross-platform moves; Swift has started way behind, but is doing very, very well.

Luckily for us, the two languages are not worlds apart. Crossing from one to the other won't be a terrible thing -- so lean back and enjoy your popcorn.

Very true. I wonder if they'll both earn the same? C# seems well paid here in the UK.

It'll be interesting to see how effective how many people make that transition to server side development. I mean we now have node for server side after JS becoming ubiquitous because of web browsers.

And Swift doesn't have the stigma of being a "bad" language when compared to JS.

are you trying to compare JS using Node.js with Swift?

> And Swift doesn't have the stigma of being a "bad" language when compared to JS.

Except Swift has the stigma of being a "dumbed down" Objective-C.

PHP has a huge developer base, and Hack is wonderful. The OSS ecosystem for it hasn't really developed in a significant way. So I'm not nearly as optimistic as you are that Swift will do better.

> it already attracts millions of developers because it's the suggested language to develop iOS apps in

Which I pointed out isn't always a good thing. You know how Rails kind of overshadows Ruby because so much use of Ruby is related to rails? Well I think swift will face the same exact fate. I'm not interested in developing iOS frontends or iOS backends in the language. I firmly believe Web will win, and I believe it's going to happen sooner than most people do.

And I firmly believe that Google, Apple, and Microsoft are scared shitless of that idea. Why do you guys think we've seen such a recent renaissance in programming language development and availability? From the years 2000 -> 2010, what did these companies put out? Microsoft had .NET, just as they have since the dawn of time. As far as I can google, it seems that Google put out absolutely nothing. Apple revived Objective-C. Absolutely no progression or innovation whatsoever.

Cut to the last 5 years. Microsoft is dabbling in functional programming in the form of F#...in spite of the fact that their developers are in enterprise and presumably have no interest in this voodoo functional programming. Just in these past few months, they released Visual Studio and .NET on Unix! Meanwhile Apple's making Swift, a language that is simple enough to be used by hipster Apple developers who make iOS apps but also complex enough to have some decent functional elements. Google develops Golang and Dart? They decided to go with Java for android, but now they're interested in spending money developing languages with names on them like Rob Pike and Ken Freakin' Thompson?

Ballmer has been quoted as calling linux "cancer". Now Microsoft is hosting linux VMs for cheap and paying people to develop tools for unix users. When apple launched the iPhone in 2007, they had only 8.1% of the PC market, and yet they opted to risk the success of the iPhone in exchange for maintaining a closed ecosystem and require iOS developers own a mac instead of providing development tools for Windows. Now, when that risk turns out to have paid off and they have a dedicated community of developers, they're suddenly deciding multiplatform support for Swift is important?

Web is winning.

What happens when we can make our apps with ReactJS and cut Google out of their android adsense money because it's just a webview? What happens when we can make our apps with ReactJS and suddenly the iPhone advantage is nil because every app is available on every device and they look exactly the same on every device? What happens when we interact with computers solely through the web and mobile, and Windows continues to lose PC marketshare and maintain their pathetic 2.5% with Windows Phone?

This is embrace, extend, extingush at it's purest. Microsoft wants you developing on their languages using their tools because they know that .NET isn't really licensed under free licenses, and since that means they control where applications run best, they hope they can outperform web and get developers on their platform. It's certainly a stretch, but they're scared.

Apple is operating on the same principle, but theirs is actually permissively licensed. It makes no difference, you can be sure that Swift will be most conveinent for iOS and OSX developers. It's a first class product for Apple devices, but they say they want the community to help them provide support for other devices? Have fun relying on that.

I don't have Google totally figured out. Their goal is probably to bring Golang to android. They're investing in providing a very unified Android experience enhanced strongly by the power of Google Now and their google services, just look at recent android releases. If I can write a backend in golang, host it on google services, and write the client side in go as well, it's a very attractive environment. To be honest, when it comes to Google, I have more faith that they can, sometimes, act altruistically. I don't think Go was an altruistic action, but look at how they give back to open source via GSoC. No one else does anything close. The only big name I think is better than Google is Mozilla.

Speaking of Mozilla, why do you think they're developing Rust and Servo, with lots of experimental rendering techniques? They're betting on web and at being the best at it.

TL;DR: They're giving you new languages and development environments because they are holding on for dear life, and I'm not willing to accept being charmed into closed development environments. The state of tech is a direct result of truly free software that is dictated by the community and the community only. Accept nothing less.

"Web is winning."

If you mean "everything but HTML-based web sites", that's accurate. If you mean the actual Web sites, I really don't see it. The Web is huge, so isn't exactly dying, but it certainly isn't winning.

Native mobile is "winning", in terms of being usually a far superior UX, and by sheer numerical demand. Native still often (thankfully) uses architectural elements of the web (URIs and HTTP) and the UX of Hyperlinking. But the HTML web as we know it hasn't kept up well with the native experience. With the massive investments in IoT being laid down along with VR/AR experiences coming out of Facebook, Google, and Microsoft, this trend will likely only continue, unless someone releases a new innovative hypermedia format & client that catches on.

"They're giving you new languages and development environments because they are holding on for dear life, and I'm not willing to accept being charmed into closed development environments."

I applaud your commitment to openness, truly, but I suggest you need to look at the global market little harder. These companies are not holding on for dear life. They're growing in power. I watched the WWDC Keynote. The crowd just about had kittens when they announced Swift will be open sourced. Twitter nearly exploded. These are anecdotes yes, but the numbers are backing Swift's meteoric rise.

Apple has a vested interest to promote Swift far and wide, perhaps even going so far as Sun did with Java, with the hindsight of their mistakes. Whereas Google could have done this with Golang but seem to be keeping a lid on it for unknown reasons. Best theory I have is that Apple is a product company and Google is a technology company. Golang is making good headway as a server-side language mainly by several companies that aren't Google.

> Native mobile is "winning", in terms of being usually a far superior UX, and by sheer numerical demand.

Yeah?

I could type a URL to anything here, and you could view it.

If instead hide my content behind an app, I can't deep link to it. The likelihood of you installing the app to see the content is way lower. You need space on your mobile device to install my app. Potentially a password entered to install it. It needs to be compatible with your device. You need to approve my permissions. The content of my app isn't searched in any search engine. You can't bookmark where you were.

I'm not at all convinced that native mobile has "far superior UX." Sure, aspects of it, no question.

And sheer numerical demand? Again, I'm not so sure. Actually, I'm quite sure you're wrong.

I am a huge proponent of the web architecture, I just think HTML is dying from the politicization of the standards process and resulting slow pace of innovation.

"If instead hide my content behind an app, I can't deep link to it. "

This is not true. I enter a URL into my iPhone's Safari, it deep links into the App associated with the domain. We just watched a WWDC keynote that showed plenty of deep linking between apps, from Siri, etc.

"The likelihood of you installing the app to see the content is way lower..."

This is also contrary to the data - people love apps, download and use apps like mad. Over $100 billion in revenue is expected to be from mobile apps this year. That's bigger than Hollywood box office 3x, bigger than book publishing 10x, bigger than PC software. The only thing it doesn't eclipse is packaged/server software yet.

Installing and using apps is demonstrating to be less effort than using the web on a mobile device: I have to do it once, vs. have to deal with a slow web browser every time I use the website.

This isn't to say people don't use the web on their phones, it's that if an app is available, people will pick the app.

"Potentially a password entered to install it... You need to approve my permissions"

Same on any website I have to sign up with via form or OAuth2.

And if an app has in-app purchases, I do none of that (just sign in on the store or use my thumbprint).

"The content of my app isn't searched in any search engine. You can't bookmark where you were."

That's interesting, most of the apps I use are searchable in the app, or on the Web. That doesn't mean I'm using a web browser to do most of the interactions.

Again, I don't think the Web is going away, just that HTML is becoming the new command prompt. That might change if something awesome comes out via open hypermedia. Doesn't look like it though... given how rich experiences are getting and how political the HTML standards process is.

"And sheer numerical demand? Again, I'm not so sure. Actually, I'm quite sure you're wrong."

By what measure? I mean, I don't claim infallibility here, I'm just saying that (a) mobile smartphones are quickly becoming the most common device on the planet, more common than a toothbrush, car, or toilet, (b) all of these support apps, (c) almost every company with a service or content has an app, (d) almost every user will prefer an app over over an website, and (e) thus almost all the money spent on consumer software is moving to native mobile. I'm following the money and the usage figures..

> We just watched a WWDC keynote that showed plenty of deep linking between apps, from Siri, etc.

True, apps are beginning to figure this out. But in general, I can easily share a link to any web page. Sharing a deep link into some content in some app is nowhere near a "solved problem."

> This is also contrary to the data - people love apps, download and use apps like mad.

Really? If I share a link to a CNN or HN article, you're less likely to view that? I don't think you're remotely correct. It depends on the kinds of content, I guess. I'm just saying there are cases where web wins huge.

> Same on any website I have to sign up with via form or OAuth2.

Yes, each of us is inventing situations where the other is wrong. But I think you agree with my fundamental premise there are times when the web utterly destroys apps.

> I'm following the money and the usage figures.

I'm sitting here typing to you on ycombinator.com. After spending time on reddit.com. facebook.com. plus.google.com. cnn.com. Yup, there are apps versions of those, but I sit at my desk for 8-10 hours a day, and my desktop experience is WAY better than my mobile experience...

I'm not saying web is better, I'm saying web is better at some things, still.

"Really? If I share a link to a CNN or HN article, you're less likely to view that? I don't think you're remotely correct. It depends on the kinds of content, I guess. I'm just saying there are cases where web wins huge."

I didn't say I would be less likely to view the link if t was a website, nor would most people avoid it. The web architecture (linking) is alive and well.

I'm saying that many websites have an app link at the top of their content once I click it and if I found myself visiting that site often i would click "Get" and grab it.

Then future links would not open my browser, they'd open the app.

"I'm sitting here typing to you on ycombinator.com. After spending time on reddit.com. facebook.com. plus.google.com. cnn.com."

Right - my habit for many years as well. But IME most people use app versions of those sites on a mobile device (except HN - and the UX suffers for it)

"Yup, there are apps versions of those, but I sit at my desk for 8-10 hours a day, and my desktop experience is WAY better than my mobile experience..."

Here we fundamentally disagree. The mobile experience FAR exceeds the desktop experience for most casual computing tasks. I use my phone and iPad way more than my laptop for reading and replying; I use my laptop more for coding and system administration.

> This is also contrary to the data - people love apps, download and use apps like mad.

I just think you and I are talking about way different things...

If I look at the HN main page right now, I see these URLs:

placebobutton.com

talkpythontome.com

dice.com

aol.com

tripwire.com

qz.com

aracrown.org

phys.org

spring.io

250bpm.com

lornajane.net

digitalocean.com

phys.org

csmonitor.com

smartdatacollective.com

golgi.io

fortune.com

ridiculousfish.com

lessthunk.com

whitehouse.gov

thesolutionsproject.org

pamelafox.org

attentiv.com

adp.com

linkedin.com

I could easily see myself spending 15 minutes reading EACH of those webpages.

THERE'S NO FRICKIN WAY I would install apps from each of those places, in order to read their one article on HN this morning. NO WAY.

Right. The web was originally meant for, and is still intended for HTML document sharing. Thankfully, HN is a basic, sensible site that doesn't cause cancer of the eye. Let most web developers around it and it would be.

That said, as the parent suggested, when it comes to opening my Gmail via Safari or the app, like everything beyond a simple document- I'm going to pick the app everytime.

...except when I'm on desktop.

GMail via web, every time.

That will change soon with Windows 10. If you're on Linux you have no choice. And if you personally had to maintain Gmail on the web, you couldn't do it yourself. Enormous time put into an application such as Gmail. So suggesting you'd build Gmail on the web vs an app is disingenuous to suggest. It's quite an edge case for many reasons.

If I had to personally maintain GMail app, I couldn't do it myself, either. I don't see how this is remotely relevant.

I'm not suggesting I'd build GMail one way or another. I'm saying that since GMail web is available to me on my desktop, where I spend the majority of my day, that's how I prefer to use it. It's nice to also have an app, but that's way less percent of my time. And I think reading and typing in GMail is way nice on my desktop.

Sure, it's an edge case, but so is Reddit, so is HN, so is G+, so is Facebook, so is CNN, so is Github, so is StackOverflow, so is xkcd, so is news.google.com...

I spend way more time on those sites on my desktop than I ever would in their corresponding apps.

Add all those edge cases up, not to mention all the websites those things link to, and it's a HUGE part of my day. Apps? Sure. I like em.

And sure, when I'm on mobile, any given content is probably nicer in an app. But sharing, mixing, quickly browsing... web wins hand-down for me.

I wouldn't even know how to take a page from my CNN app (unless they give me a web URL) and discuss it on my Reddit app. Do you?

Again you're back to what we've already established the web is ideal for. It's original intended purpose- simple document sharing. It's been doing this since the early 90s.

While sharing info on Wikipedia is great, where the web fails is competing with native apps. Other than sharing HTML text documents (and there are projects working to replace that too), it doesn't get chosen over native apps.

Also, I'd still say that you'd come a lot closer to being able to maintain a Gmail-style app on iOS, than you ever could on the web. As a 1 man operation. Plenty of people actually do personally maintain email native apps alone on mobile. But unless you go with basic HTML or little to no features, I don't think 1 person is keeping a web email client up to date for all browsers, all the time.

The reason you prefer using webapps on the desktop, is simply because that's where you are all day. At a desk. If you were in anything but a desk job, it'd be the complete opposite. It's not an issue of superiority, it's a matter of convenience. For most people, that convenience is flipped and the experience is equal or better. Which is why native apps are winning.

Why do I get to target iOS only with my email client on the one hand, but I have to support "all browsers" on the other? Stop stacking the deck, ok?

> If you were in anything but a desk job, it'd be the complete opposite.

...and if I were a banana, I'd probably prefer sunshine. I'm saying there are cases for me where the web is way better, even on mobile.

You can't prove to me that's not true, because it is. It's like you're trying to talk me out of observational data on my own life experience.

I just said iOS as an example. I didn't mean to make it appear I was stacking the deck, you could use Xamarin and target all platforms if you wanted. That's still easier than supporting all browsers over time. All browsers over time with a complex app like Gmail? Forget it.

But the issue I was trying to convey is that you're an edge case and in an increasingly marginal pool as time goes on. Most people aren't sitting at the computer all day, and even if they do (we'll say so for sake of argument), they stay off personal email at work (a good idea). And they use their phone yet still. That's what I do. I'm at a desk all day as well, and never login to personal stuff on my work network/machine. That's where iOS gets its use.

for many of those, they're not apps they're websites. Apps are for repeat use of aomething more complicated than reading documents. Usually websites with a lot of JavaScript are better off as apps.

LinkedIn I have an app, and it's usually better than the website except for some features they maddeningly haven't carried over. Dice too. The rest I would use a website.

This isn't contradictory to my point that apps are the future of how we interact with the web. In effect apps are about a proliferation of user agents - rather than a single hugely popular type of user agent (the browser) and a handful of busy singular agents (the crawler). I am not saying the Web is going away, I'm saying HTML browsers are becoming relatively less important. They're not going away they're just not where the money and growth is.

Why would I prefer to type a URL? I can just as easily get an URL for the app in ap store and have it right there. Having app stored on my device is an advantage, unless you like your web apps download in full even on crappy mobile connection. And you really want the content of your app indexed by external search engine? I like being able to control the permissions my app has. Or does your web app not ask for the permission to use your location, camera, microphone? I don't need to bookmark where I were in the app: I open it and I am there at once.

You don't want to type URLs, especially on mobile, but the fact that all the items on the home page of HN are links to web pages and not to screens inside apps should hint to a definitive advantage of the web over apps. And to why having a web site is mandatory and having an app is optional.

If the web and apps where in the same competition I'd say the Web can't lose, but I don't believe they compete. They serve different purposes with some overlaps (think Google Docs, the web site and the apps).

> Why would I prefer to type a URL?

You can just click on URLs if I type them. Maybe if you go to your local library, someone can give you a demonstration of how the internet works.

> I can just as easily get an URL for the app in ap store and have it right there.

You're ignoring the deep-linking I'm talking about. Not just the app (like cnn.com), but to actual CONTENT on it, like some specific story.

> Having app stored on my device is an advantage, unless you like your web apps download in full even on crappy mobile connection.

Web Apps can store most of their content in your browser, now. So additional views are not downloading the full app.

> And you really want the content of your app indexed by external search engine?

Yeah, I really want content I produced to be indexed by search engines, so users can actually find it. Not 100% of the time, sure, but I'm in control of that. Explain to me how I can possibly get a search engine to index my content if it IS in an app?

> I don't need to bookmark where I were in the app: I open it and I am there at once.

If you want multiple bookmarks, then no, what you're saying isn't remotely true. If you want to share a bookmark, no, this isn't possible.

Or are you just being argumentative for the sake of being argumentative?

It depends what the app is for. If it's for viewing content over HTTP then yes a native app probably is a dumb idea (unless the platform has wildly different browser capabilities, like on Android - you never know what you're going to get so have to write a dumb website).

However, if the app is for something useful (and not just a content viewer) then native is far superior.

Lets say I'm searching for a house.

If I go to redfin.com on my phone vs the native redfin app, there is a distinct difference in UX. The native app by far surpasses the mobile app in terms of performance and usability.

Now this is one example but can be said for many sites whose functionality isn't just to display static content.

I feel like people are ignoring my fundamental point -

There are things the web can do that native currently sucks at. Sometimes those things are really important to me.

I'm not saying web is always better than native. Far from it. But I am saying web is sometimes way better than native. Even on mobile.

Sorry, but you are too deep in your illusion. Your TL;DR is funny. How will you then explain dozens of JS frameworks coming out every day? The web holding to it's dear life? Please, stop talking about the things you know nothing about. Or at least give native development a honest try and see for your self, that web is not winning anything, and web apps are just a huge pile of mess. Or for a start just try to make the app with ReactJS which looks the same on every device. Good luck.

> Golang is a pragmatic crowd

Why do people keep on saying that? Would people say javascript is for the pragmatic crowd because jsfiddle exists ? no

Go is a badly designed language period. the type system forces devs to write runtime type assertions which should be the job of the compiler thanks to parametric types, if go designers knew one or 2 things about types. The fact that Go dismisses 30+ years of type theory isn't pragmatism. It's ignorance.

Nobody would call PHP pragmatic yet even PHP is more expressive.

I had the same opinion as you until I started some code with it.

The true is that I had never been so productive writing code. The friction from what is in your head and the code is almost 0.

It is true that I ended writing a few functions that were there only because the lack of generics, the type system and other stuff being "built-in". But at the end, I think it was an order of magnitude less often than I was expecting it to. I was wrong.

Your comment is interesting, it has made me want to look at the language, so thanks.

But I think that the "friction from what is in your head to code" probably betrays that you weren't settled in a previous language? I only say this because I have zero friction writing C++, and have to think mildly backwards when it comes to C# or Java, and definitely Objective-C. Even PHP is like simplified C++ to me, so I write everything like it is a dumbed-down dialect of C++.

I suppose it is just what some people find comfortable.

> But I think that the "friction from what is in your head to code" probably betrays that you weren't settled in a previous language?

I had the same feeling as the user you're answering to. And I have used quite a bunch of languages I've been quite productive with (C, C++, PHP, Python, Java, Ada), but I've never felt with these languages as little "friction" as with Go.

I mean, that language is so dumb that you don't have to think about the right way to do stuff. It's obvious. Boring, sometimes verbose, but obvious. It doesn't stand in the way between me and the problem.

That's really good that it's so dumb that you don't need to jump through hoops to think of the way to do it. Clever! Just code and go!

It is not unicorns either.

* Transforming a collection means doing boring for loops instead of one-liners. * interfaces/duck typing is great. But hey, []interface{} does not fit into interface{}. * Structs with fields are encouraged, but there is no uniform Uniform access principle and that sucks. * etc

But definitely, my own "science" confirms that it turned to be out less of a problem (for my own usage) compared to better languages with more friction.

Yep. I've been bored by the fact that putting an []int into an []interface{} doesn't work, too (although the reason is obvious).

I was following Rust very entusiastically. But at some point the language was getting itself in the way of the problem I was solving.

I am not only talking about the strict compile checks. I am talking about that extra thinking in the ten ways you can design it and how it should be done in "proper" Rust.

And the friction is not only in the language, but also in the standard library. A language that comes with XML/json marshal/unmarshal plus a quite decent http client/server framework covers most of what I need to do.

I am sure if Rust had included in the standard package http/xml/json it would be far more popular. I understand the voices that say "It does not belong there", "the language is not targeted at that". Fine. But then I found myself having not much user for the language, even if I loved the idea/theory behind it, plus that I could not get comfortable thinking in it.

[I'm a Rust user, and not particularly fond of Go, but...]

Not having great static typing doesn't make it not pragmatic.

Given Go's purpose, it is extremely pragmatic.

One of the reasons Google uses Go is because their employees are often fresh out of college and might not be familiar with the depths of type systems.

If you look at most professional Java/C++ code (starting to see this with Rust too), the features of the language are used to their full extent to create really convoluted APIs (to an outsider not familiar with the language). So, to work on it, one must first become familiar with the intricacies of these languages (this is not as easy as picking up a book, you need experience), and then with how the language is used in context, which is another time consuming thing.

Instead, go trades off some higher level features for compilation speed and ease of learning.

After programming in Go for a week I was able to pick up any Go code -- ranging from the standard library to various other applications, and know what was going on. I cannot say the same about Java or C++ or Rust; generics/templates/virtual/friend/advanced typesystem gymnastics all are used to great extents in the code for a standard library or some large application. one may be able to use the language for your own stuff after a week of learning and hacking, but one will need much more time before they're well suited to contribute significantly to existing codebases.

A course I took recently was taught by a PL aficionado. He knew Rust, Nim, and Go, along with many older languages. Go, Rust, and Erlang, among others, would have worked beautifully for the project topic (concurrent stuff). He made everyone write in Go because he wanted a uniform language for project evaluation, and because Go is something students could reasonably pick up in a week without constraints on their background.

=========================

At the same time, the Go community is pretty awesome. There is a "go way" of doing things, and while it is pretty rigid, that doesn't make it not pragmatic. From my (admittedly limited) discussions with them, they do seem to think practically/pragmatically. There are good reasons for wanting to use Go. These folks know those boundaries, and think practically within them.

Though there might be much to say about the different implementations of generics, I've found them to be easy to understand and use in languages. No type theory required. That has been more like "Oh, so that's the name for that thing/aspect, neat".

If I don't have a problem with that, those coveted master race Google developers should have absolutely no problem with it.

Well, variance can be hard for many to grock. The combination of generics, mutation, and subtyping is problematic, complicating nice feature like type inference. I can see why Pike and company left it out, though I think it's quite feasible to fix their problems.

It's not that generics are hard to grok, it's that they get used in a hard to grok way. Wrapping your head around such things gets more and more hard as the app complexity grows.

The base point is that languages like Go let you think of the program at runtime, only. Types are a runtime concept, everything is a runtime concept. Structuring APIs to use compile time safety requires a whole other kind of thinking, one which they may not expect to be uniformly available.

Ultimately it's a choice of whether or not you want to the programmer to think of data and flow (runtime), or metadata (types, compile time). Once you're used to both the difference is blurred. For newbies, the concept of using compile time safety can be daunting.

Right, don't have to think about compile time. Instead they sometimes have to think about post-compile time[1], i.e. code generation. Now you don't have to think about those weird bracketed capital letters. Just take care to check where you have comments[2] that happens to include directives to some external tool.

With how Go programming seems to work for some people, I can perfectly well imagine a system with commands that do code generation as a hook for other commands, or by 'listening to the file system' for changes in certain files. That could get out of hand pretty easily. And yeah, one can say "anything can be taken too far". Just like you said about generics. The difference might between having well-encapsulated and behaving mechanisms that does most of what you normally would need. As opposed to a "simple" system that just pushes the problem to another level, in more ad-hoc ways.

[1] I honestly don't know if the code generation typically is pre-, post-compile or a mix of those two. It's too complex for me.

[2] I thought single-line comments was supposed to be a safe haven...

Not everyone uses codegen or other tools. You can write generic-ish code in Go which is just runtime checked via vtable pointers (interface objects).

And of course, the loss of static checking means that one has to write more tests for mundane things. But again, designing tests requires "runtime thinking", designing statically checked APIs requires "compiletime thinking".

> Too little too late.

This is a toxic attitude. It suggests that if people don't get something right on the first try they shouldn't try to improve it.

"Better late than never" is true in many cases, and this is one of them.

Also, Apple tends to figure out what they have and try to get it right before releasing it widely. They don't want to throw things out there and then cause a lot of forks and language wars. The idea that it should be open source from the beginning, or it's worthless, is kinda dogmatic. Apple knows that the most core technologies need to be open source, which is why Darwin is there, Webkit, etc. And which is why Apple's work on LLVM is open source, it's extensions to Objective-C and of course Swift.

Swift was always going to be open source, but Apple launches OS products differently-- it gets them to 1.0 so they are strong enough to stand on their own.

Golang is a pragmatic crowd ? Weird because it seems like an ideologically driven language.

Their attitude towards exception handling and generics has never strike me as being overly pragmatic.

I really like Go and have written quite a bit.. But go into #go-nuts and ask about unsafe. Just as a counter point.

Reply on news.ycombinator.com