Slashdot Mirror


Google May Adopt Apple's Swift Programming Language For Android, Says Report (thenextweb.com)

An anonymous reader writes: Google has plans to make Apple's Swift object-oriented language a "first-class" language for Android, reports The Next Web. The publication, citing sources, adds that Google doesn't mean to replace the current first-class language for Android -- Java -- at least, "initially." Google sees an "upside" in using Swift, which Apple made open source last year. But a ton of things need to fall into place for this to work. From the report, "All told, Google would have to effectively recreate its efforts with Java -- for Swift. If the company is motivated enough, it's very possible to do so without compromising on its open source values or ruffling any developer feathers along the way." The company is also discussing internally about making Kotlin as a first-class language for Android. "Unlike Swift, Kotlin works with Android Studio, Google's IDE for Android development. Unfortunately, sources tell The Next Web that Google's current mindset is that Kotlin is a bit too slow when compiling."

172 comments

  1. God damn it, just PICK A FUCKING LANGUAGE ALREADY! by Greyfox · · Score: 2, Funny

    Damn it Google, just pick a fucking language already and make it an option as an alternate to Javascript on the browser. Anything strongly typed and notably lacking in magic goddamn bullshit (Looking at YOU, Ruby) would be better than what we have now.

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

  2. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Jeremi · · Score: 4, Insightful

    Damn it Google, just pick a fucking language already and make it an option as an alternate to Javascript on the browser.

    I thought the trick for web browsers was to pick your own favorite fucking language, and compile it to JavaScript for deployment? Then every programmer can use whatever language he/she prefers, rather than everybody having to use the same language.

    Of course, this article isn't about web browsers, it's about application development.

    --


    I don't care if it's 90,000 hectares. That lake was not my doing.
  3. Opt for Swift, not Kotlin. Please! by Anonymous Coward · · Score: 3, Interesting

    I would much prefer to see them go with Swift.

    I've dabbled with both Swift and Kotlin, and the Swift community is a much nicer one to deal with. The Swift community is a lot like the Python and C# communities. They're friendly, not too opinionated, and when they are opinionated it's because they're right. If you have a problem, they'll help you out and everyone's happy. They aren't there to tell you what to do or how to do it. They just try to help you do what you want to do.

    I've found the Kotlin community to be more like the Rust, Ruby and Nim communities. There is a lot of cockiness, and they're way too opinionated, especially when their opinions are factually wrong so often. If you don't do things their preferred way, even if their way is the worst way possible, well you can just fuck off and die as far as they're concerned.

    Maybe the difference has to do with the age of the participants. Those working with Swift, Python and C# tend to be older, more mature and generally laid-back. Those working with upstart languages like Kotlin, Rust, Ruby and Nim tend to be young, angry, passive-aggressive, and perhaps impotent.

    If I were developing for Android, I'd much rather deal with the Swift/C#/Python type of community than the Kotlin/Rust/Ruby/Nim type of community.

    1. Re: Opt for Swift, not Kotlin. Please! by tepples · · Score: 3, Informative

      What do you need a community for? Read the language spec, read the api spec, done.

      For helping to clarify things that you failed to understand in said specs, and to help explain practical ramifications of said specs.

    2. Re: Opt for Swift, not Kotlin. Please! by Anonymous Coward · · Score: 3, Insightful

      Uhhhh, are you serious?

      The community will develop the libraries you use. You'll want to use libraries developed by a community that cares about doing things right, providing proper releases of these libraries, and maintaining them over the long term. Swift, Python and C# are good communities for this. Rust, Ruby and JavaScript are not. The Rust, JavaScript and Ruby communities just shit out partially-done libraries over a weekend, throw them on GitHub without any sort of formal releases, and then forget about them.

      The community will also help discover and document the best practices for using the language. This collective knowledge will do far more to help make the language efficient and effective for everybody to use. Anyone who is a lone wolf will waste a lot of time rediscovering what the community found out much earlier.

      The community also influences the direction the language will take. We see the Python, C# and Swift communities continually improving their languages. On the other hand, we see communities like Rust and JavaScript constantly spinning their wheels, since their "best practices" change every other day. That's why it took forever to get Rust 1.0 out, and it's also why JavaScript is only now getting proper class-based OO, 20 years after it was created!

      Programming language communities are very important. The last thing any programming language user needs is to deal with a community like the Rust community, where they often treat you like dirt.

    3. Re:Opt for Swift, not Kotlin. Please! by jrumney · · Score: 2

      when they are opinionated it's because they're right.

      Isn't that true for any community (for their own definition of right).

    4. Re:Opt for Swift, not Kotlin. Please! by DraconPern · · Score: 1

      I am curious where node.js/V8 stands... Coming from a C++, C# background,I am trying to learn 'the next' thing, and javascript with it's write once run anywhere seems like a very good idea.

    5. Re:Opt for Swift, not Kotlin. Please! by Anonymous Coward · · Score: 0

      How about using C#? It's just as open as Swift these days with a larger developer base...

    6. Re: Opt for Swift, not Kotlin. Please! by Anonymous Coward · · Score: 0

      Considering I debug specs, that's not much of a problem.

    7. Re: Opt for Swift, not Kotlin. Please! by Anonymous Coward · · Score: 0

      What about PHP???

    8. Re: Opt for Swift, not Kotlin. Please! by Anonymous Coward · · Score: 0

      I'm not what sure what you mean by "debug specs", but if it means you read through them to make sure they're clear, you seem to suck at your job.

    9. Re:Opt for Swift, not Kotlin. Please! by irrational_design · · Score: 1

      Don't forget about React Native. Write native IOS and Android apps using JavaScript.

    10. Re: Opt for Swift, not Kotlin. Please! by TechyImmigrant · · Score: 1

      I'm not what sure what you mean by "debug specs", but if it means you read through them to make sure they're clear, you seem to suck at your job.

      I'm sure of what he means because I've done my fair share of debugging specs too. They have bugs just like software has bugs. Signaling between entities with lockup states. Arrows of causation pointing in different directions (A pushes data to B when data is available. C pulls from B when it needs data, A and C don't have a clue what each other are doing). Huge architectural mismatches with reality (802.11i started out treating 802.1X as a protocol layer (google "802.1X misuses" to my run in with that one)). References to specs that don't exist. References to specs that are parameterized without providing the necessary parameters. Sometimes making really basic mistakes like thinking X.509 certs will address their authentication problems without generating an intractable pile of impossible to solve problems.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    11. Re: Opt for Swift, not Kotlin. Please! by TechyImmigrant · · Score: 1

      What about PHP???

      Wash your mouth out!

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    12. Re: Opt for Swift, not Kotlin. Please! by JadeBurton · · Score: 0

      This. And with C# they don't have the annoying habit of changing the core syntax with every language version in a breaking way. They literally just changed the syntax for for loops in Swift. I've never seen that done before, and I couldn't believe it. C# is fast, mature, and modern.

    13. Re:Opt for Swift, not Kotlin. Please! by KGIII · · Score: 1

      I've been getting back into both programming and coding lately. This is after a nearly 10 year hiatus or a 15 year coasting period. I really haven't done much since about 2001. Some small stuff online, that's it. I did some stuff with SMF for a while, was on their team actually, and I stopped that in 2007 or 2008.

      The thing I've noticed is how much has changed. Oh wow... But, to be more specific and lend what I can, I've noticed that there's a JavaScript library for everything. There's also a Java library for everything. I'd have never guessed it. In 2007, I was kind of hoping JS would die. I knew that Java in the browser, as applets, was gonna go away. (No, I'm not confusing the two, I'm referencing them both at the same time. I know the difference.)

      I did some C++ but I was most proficient in C. I never learned all the new things - I'd hired professionals by then and my code was being written for me, more often than not, by around 1998. So, for what it's worth, I'd ignore the JavaScript and go with Java - unless you're planning on doing web development. If you're going to do web dev then JavaScript is the way to go. If you're gonna write apps and things that you write once and run everywhere, then Java's not bad. I'm told you can nearly do that with C now but I've not looked into it much deeper than just listening to someone describe it for me.

      I'm also assuming you are not confusing the two, as well. Chances are pretty good, however, that you know more than I and are far more adept than I so I'm making sure that you know that I'm not confusing 'em. Strangely, lots of people do confuse them. One was for the annoying applets and the other was for the scrolling text and falling rainbow crap that littered GeoSomethingOrOther pages. Thankfully, those types of things have gone away but we seem to have somehow kept JavaScript around.

      What's even stranger, some people are doing some neat things with it by mashing up stuff from other people's sites. Of course, each web page is now 2.9 MB in size - even with ads blocked. You have to allow third party scripts to run to actually click links on some of the pages. But, damn, it's trendy... Also, I admit, some of it is kind of cool. I might be old, I'm just not a relic stuck in his own time. It is kind of neat what they're able to do.

      Me? I'm gonna stick with bashing other people's PHP into shape and probably learn some JavaScript and more of the new, to me, CSS and HTML5 stuff. I'm also brushing up on my C. Even that has changed. There's a billion libraries - and they're all free. It's awesome! The thing is, with JavaScript - if you want to build a robot that runs JavaScript - someone's figured it out. Hell, someone's written a library to make it a robotic cat with three legs, a broken tail, and a horrendous mewing sound whenever someone walks by - based on accelerometers that they desoldered from a cell phone.

      I'm not actually sure when this happened but JavaScript grew up when I wasn't looking. At the same time, Java has done pretty well for itself too. It's eating up a lot of my time but that's a great thing and what I wanted.

      Also, there's this caveat... I never actually took any formal classes in programming. I just did it because I had to. Computers didn't really do anything useful back then, not unless you knew how to tell it what to do. So, I had no choice in the matter. It worked but I'd not lay claim to being good. With that and the fact that I've not really done a whole lot in a while - and am just getting productive as of late, weigh my opinion accordingly. But, there it is if you want it.

      --
      "So long and thanks for all the fish."
    14. Re: Opt for Swift, not Kotlin. Please! by Anonymous Coward · · Score: 0

      It's a quote from Fred Brooks. Hand in your card and fuck off.

    15. Re: Opt for Swift, not Kotlin. Please! by NotInHere · · Score: 1

      The Rust, JavaScript and Ruby communities just shit out partially-done libraries over a weekend, throw them on GitHub without any sort of formal releases, and then forget about them.

      I have dived into the rust ecosystem a bit, and can say that some crates are indeed how you describe it. Most of the crates I used however fulfil their tasks as they should.

      That's why it took forever to get Rust 1.0 out

      And now as Rust 1.0 is out, their promise of stability should be believed.

    16. Re:Opt for Swift, not Kotlin. Please! by phantomfive · · Score: 1

      The Javascript tech stack is in huge flux right now, with new frameworks coming out, and no convergence yet (this list isn't anywhere near complete, for example. If you really want to, and only have time to learn one, I'd go with Angular or Backbone. React.js is interesting but is still immature).

      The biggest coming wave is WebAssembly, which will let you write front-end code in C++. It's going to turn everything on its head, and my guess is we'll see completely new frameworks.

      --
      "First they came for the slanderers and i said nothing."
    17. Re: Opt for Swift, not Kotlin. Please! by Anonymous Coward · · Score: 0

      Please yes this. Swift is an Objective-C hack job. Give me C# and you've saved my clients time and money. Give me Swift and I'll procrastinate right up until the deadline.

    18. Re: Opt for Swift, not Kotlin. Please! by BasilBrush · · Score: 1

      Not only that but they removed the ++ and -- post and prefix operators.
      It's a policy not to get stuck with syntax that is was acknowledged to be a mistake, and to update code from old to new with refactoring tools.

      Despite their familiarity to C programmers, "for (;;)" and ++/-- are not good syntaxes.

      "for item in collection" and "for i in 1...10" are far clearer. And any other loop shoe-horned into for (;;) is clearer as a while.

      And ++/-- encourage side effect computing. Better to explicitly increment a value on a line of it's own, than hide the increment in the middle of another statement. It's original C purpose as an occasional hand optimisation is no longer valid in the days of modern optimising compilers.

      C# has been around for a while. I doubt if there isn't some syntax that is regretted in hindsight. It's a shame of they can fix that.

    19. Re:Opt for Swift, not Kotlin. Please! by Anonymous Coward · · Score: 0

      ... and perhaps impotent

      Well, it's better they use forking for project persistence instead of sex, given how few females tend to be in programmer communities.

  4. Google should then buy RemObjects... by Faw · · Score: 1

    and be done with it. RemObjecs Elements compiles Swift/C#/Oxygene(Delphi-lile language) to ios/windows/java/mac.

    1. Re: Google should then buy RemObjects... by Anonymous Coward · · Score: 0

      Yup. Already there.

  5. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Anonymous Coward · · Score: 1

    Next year's announcement: as we've realized that Swift wasn't invented by Google, we're deciding to replace it with a new own in-house language that will sit beside Go, Dart, Angular, and the rest of our toys that suckers think will be godsends, until we've got 'em hooked and change how everything works again.

    Next-next year's announcement: we're dropping support for the Internet, as we've realized that it wasn't invented by Google. We're making our own version, as in-house studies have shown that we can save ourselves some money, and nobody cares how much we fragment things anymore, because you're all happy to let us take control of everything.

  6. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by tepples · · Score: 1

    I thought the trick for web browsers was to pick your own favorite fucking language, and compile it to JavaScript for deployment?

    If you treat JavaScript as "machine language" to which the client side of a web application is transpiled, how does source-level debugging work?

  7. Not JVM by Anonymous Coward · · Score: 5, Informative

    I hope they don't intend to run Swift on their JVM.

    What makes Swift so performant is that it lacks a tracing garbage collection. It only uses reference counting. Reference counting is a kind of garbage collection, but it doesn't by itself detect cycles. It's the cycle detection that is costly in languages like Java or Python (which uses reference counting along with a tracing collector for cycles.) People argue that cycle detection is cheap, especially in generational GCs. But the generational assumption presumes too much. Likewise when passing references between threads. Cross-generational (yet temporary) and cross-thread value passing can happen often. (See, e.g., MoarVMs problems.)

    Plus, tracing collectors often need 2x RAM to be performant. Again, people wave away that requirement by arguing RAM is cheap and plentiful. But that assumption is broken all too often, as well, _especially_ on embedded devices.

    So Swift offers both lower latency, more consistent latency, and requires fewer CPU and RAM resources. The cost is that you have manually break cycles, otherwise you'll leak memory. But tracing collectors don't fix all leaks, either. It's common to "leak" memory through caches. Some languages provide ephemerons (e.g. ephemeron tables in Lua), a special reference type that is more semantically powerful than, e.g., weak references, and provides the necessary hints to the tracing collector. But it's still something you must explicitly declare. And the Big-O complexity of ephemerons is pretty bad, so it can degrade performance significantly if there are lots of cycles passing through the ephemeron.

    1. Re:Not JVM by Phydeaux314 · · Score: 4, Interesting

      I do some application development in Swift on iOS. It's... well, it has some issues, many of which stem from the issues you've pointed out.

      First, not every interface or function you need is available in Swift, so you end up spending a lot of time converting back and forth between the two languages in your code. This massively increases complexity and is generally a Giant Pain In The Butt. I really wish they'd finished making their system calls on iOS available in Swift (rather than having to bounce back to objective-C all the damn time) before they pushed it out to the public.

      Second, swift (and specifically how they use it on iOS) is an irritating blend of "we want things to be user friendly" (read: idiot proof) and "we don't want to hide too much out of the way." As a result, people coming from lower-level languages (like C or C++) will spend time fighting a some of the assumptions the system makes, and people coming from higher-level languages (like Java or Python) oftentimes will fall through the gaps.

      Take memory management, for example - it has garbage collection, so you don't need to worry about malloc and free, but it doesn't have extensive garbage collection, so as soon as you start using multiple references - sorry, pointers - in multiple places you start needing to worry about keeping track of how you're referring to things (strong vs. weak) so you don't end up using more memory than you need to.

      So, no, I don't really like Swift. It's not bad, and I'd work with it if I had to, but it's sort of sitting awkwardly between something lower level and something higher level and fully abstracted, and figuring exactly what they did and did not include is a pain in the butt to work with and around sometimes.

      --
      Never underestimate the stupidity inherent in all human beings.
    2. Re:Not JVM by Gr8Apes · · Score: 1

      Wow, some of that sounds exactly like my C# experience. Except C# has been around years and years.

      --
      The cesspool just got a check and balance.
    3. Re:Not JVM by Alomex · · Score: 1, Insightful

      The JVM exists because Sun assumed Java would be running in very different devices without a proper OS and without ready access to a native compiler. None of these things hold true today. So the JVM is essentially just a layer of cruft slowing down your app. Android nowadays compiles the app into native code and modern JVMs compile at run time. So let's get rid of the JVM.

    4. Re:Not JVM by lokedhs · · Score: 2, Informative
      I wouldn't be so quick to assume that reference counting requires less CPU cycles unless you have actual data to back up that claim.

      With reference counting every single allocation, as well as every single object ownership transfer requires extra CPU cycles and memory accesses to manage the memory as well as manage the counter (yes, I know Swift does some clever tricks to avoid the counting which frankly is the only reason it's as performant as it is). Also remember multithreading issues when updating the refcounter.

      With garbage collection, you obviously don't need to do any reference counter management, saving a lot of CPU and memory access cycles right there. But what is less obvious is that memory allocation itself is much faster with (compacting) garbage collector. After collection, all free memory will be in a single contiguous block, reducing the memory allocation operation to a single ADD instruction.

      So, in summary:

      With refcounting you have:

      • Slow memory allocations (need to manage a fragmented heap)
      • Slow accesses and pointer handovers (updates to the refcounter)
      • Slow free (need to manage the free list)
      • No asynchronous pauses (since there is no garbage collector)

      With a GC, you get:

      • Fast allocations (usually just an "add" instruction since the heap is not fragmented)
      • Zero cost accesses and pointer handovers
      • Zero cost free (just stop using the pointer)
      • Some asynchronous pauses and CPU usage while running the GC

      There have been plenty of research on memory management, and we're well past the time when you could say "GC is slower than the alternative".

    5. Re:Not JVM by Anonymous Coward · · Score: 1

      dude, if you don't grasp that Swift does reference counting and does not do garbage collection, nothing else of what you said has any value. that is literally the fundamental distinction of swift's programming model.

    6. Re:Not JVM by Puff_Of_Hot_Air · · Score: 1

      Yes, there are trade-offs in both directions. Apple made the choice for ref-counting so that you have a consistent UI experience and generally lower memory overhead. For phone based apps I think this is the right choice. By the way, I don't think you can say that a GC is faster, just that it can be faster, in the real-world it can also be slower depending on how it's being used.

      Personally I find GC to be a pain the rear due to the fact that it's generally a lot harder to resolve GC performance issues that are affecting you than RC problems. I think that for strongly typed languages a GC is the wrong choice, but it's certainly not a black and white issue, and most of the time it really doesn't matter.

    7. Re:Not JVM by Tablizer · · Score: 1

      Why can't cycle detection be a programmer option choice rather than a language choice? Maybe even with a threshold setting such as only do cycle detection when more than N bytes are consumed by a program or thread.

    8. Re:Not JVM by AlphaBro · · Score: 1

      How, exactly? C# doesn't use ref counting, and pinvoke works great for reaching native APIs that aren't exposed through the BCL. What kind of projects did you have trouble with?

    9. Re:Not JVM by phantomfive · · Score: 1

      Maybe even with a flag at declaration time, something like:

      Object o = new [cycle_detect] Object();

      Or maybe make cycle_detect the default, so if you want cycle-free objects and know what you are doing, you can declare:

      Object o = new [dangerous] Object();

      --
      "First they came for the slanderers and i said nothing."
    10. Re:Not JVM by Kartu · · Score: 2

      JVM has no problem being performant (thanks to advanced JIT, which, at least in theory, can even be faster than static compiler, as it has runtime information such as which branch is more likely to be taken).
      The only inherent disadvantage of it is memory footprint.
      But that's the price you pay for not having to malloc/free.

    11. Re:Not JVM by brantondaveperson · · Score: 1

      Not necessarily, reference-counted memory management, plus weak pointers if you insist on creating circular references, free you from freeing, and don't have a memory penalty.

    12. Re:Not JVM by Anonymous Coward · · Score: 0

      Why AC? This is really smart comment.

    13. Re:Not JVM by Andreas+Mayer · · Score: 2

      Take memory management, for example - it has garbage collection, [...]

      No, it has not.

      Swift uses Automatic Reference Counting (ARC).

      Stop developing now until you read and understood that document.

    14. Re:Not JVM by Anonymous Coward · · Score: 0

      you are just a dumb who doesn't know how to program. Simple fact checking.

    15. Re:Not JVM by Elledan · · Score: 2

      My approach to mobile development (Android & iOS) is to write all of the logic and everything else I can in C++ ('Objective-C++'), then use some glue logic in Java/Objective-C/Swift where needed and native APIs aren't available.

      Writing an entire app in Java, Objective-C or Swift seems illogical, even if the app isn't intended to be cross-platform. Just being able to debug the core logic with mature C/C++ tools on a Linux/BSD PC is a godsend, and reusing the same code across two (or three, or four) mobile platforms is just awesome.

      --
      Site & blog: http://www.mayaposch.com
    16. Re:Not JVM by Alomex · · Score: 1

      You are ignoring two other disadvantages: the power consumption of the first compilation pass is non-negligible, and the garbage collection mechanism creates quite a bit of overhead. So while in theory the JIT could be faster in practice it has never been. So if we are now JIT compiling (which precludes static analysis and optimizations) what is the use of the JVM?

    17. Re:Not JVM by Anonymous Coward · · Score: 0

      Reference counting, including ARC, is a form of garbage collection.

    18. Re:Not JVM by Hizonner · · Score: 1

      As a user, having seen the kind of code that's actually offered for me to use, I don't want it to be any easier than it absolutely has to be to leak memory. It can be really easy to drop a cyclic reference, or conversely really hard to keep track of when you have them. The programmers writing phone apps have shown that they're not up to that kind of challenge.

      In this day and age, programmers shouldn't have to think about the internals of the runtime. Stuff should just work. And I'm willing to take a performance hit for that if need be.

    19. Re:Not JVM by Gr8Apes · · Score: 1

      With the constant bouncing back into Win32 constantly to do anything meaningful with the system.

      PS - in this case I was writing system management code, right about the time that .NET 4.5 came out. The documentation was flat out wrong as 4.5 removed quite a few internal calls because they were trying to secure the process space. However, IMNSHO, what they really did was make the situation even worse, by removing token manipulation routines instead of actually implementing real security. But that's another post.

      --
      The cesspool just got a check and balance.
    20. Re:Not JVM by Lally+Singh · · Score: 1

      Apple made the ref-counting choice decades ago and now has to keep supporting it to maintain compatibility with their APIs.

      --
      Care about electronic freedom? Consider donating to the EFF!
    21. Re:Not JVM by Anonymous Coward · · Score: 0

      No they don't. They started a move to GC somewhere around 2005 and made their libraries GC-compatible at that point. If they had wanted to, Swift could simply have required GC. However, they realized a few years into the move that GC wasn't the best choice (probably at least partially because that's when the resource-constrained iPhone came on the scene) and started work on an ARC implementation instead. Swift continued from there, but it didn't have to.

    22. Re:Not JVM by Chalnoth · · Score: 1

      There's also the fact that garbage collectors tend to require much more memory in order to maintain performance than reference-counting schemes. This is a huge part of the reason why Android requires so much more RAM than iOS.

      This also means that performance just tanks on devices that rely on GC as memory gets close to full, which can lead to really nasty experiences.

      I really think that making use of a garbage-collected language as the primary language in embedded devices is a bad, bad idea all-around. I still prefer Android to iOS, but I really wish that Google could undo the decision to use Java. I have a hard time believing that Google using Swift for Android is at all likely.

    23. Re:Not JVM by Chalnoth · · Score: 1

      Because quite a lot of how the language is designed rests upon garbage collection assumptions. Try to do this with Java, and first you'll have a really difficult time coming up with a coherent set of rules for destruction of objects so that developers can understand the lifetimes of their objects. Then you'll have the problem that any existing codebase is likely to break in unpredictable and difficult-to-debug ways (e.g. sometimes objects will be destroyed before they should be, leading to crashes or security nightmares as references point to the wrong objects, other times objects won't be destroyed creating memory leaks).

    24. Re:Not JVM by gnasher719 · · Score: 1

      Garbage collection doesn't detect cycles. Garbage collection ignores a second reference to an object (as would be created by a reachable cycle, but also happens just normally), and garbage collection ignores unreachable objects (which may include complete cycles that are unreachable, but also any other object or a tree structure that isn't reachable).

    25. Re:Not JVM by BasilBrush · · Score: 1

      Clearly he does understand it as he talked about needing to use weak references to break retain cycles.

      What you don't seem to understand is that reference counting is a technique to do garbage collection. In Apple parlance they don't usually refer to ARC as a form of garbage collection, as they don't want to confuse it with the other and now abandoned auto garbage collection approach that they did just call the garbage collector.

    26. Re:Not JVM by BasilBrush · · Score: 1

      Yeah. I like Swift, but the debugging isn't mature yet. XCode regularly crashes when you start putting breakpoints or single stepping though Swift.

    27. Re:Not JVM by BasilBrush · · Score: 1

      Given Oracle suing Google for IPR issues on their Dalvik rip-off of Java, it seems quite likely. Swift is open source and so doesn't carry that problem.

      They could use another language other than Swift and Java. But Swift is fit for purpose, having been designed specifically with smartphones in mind. And although young, already has a lot of mobile developers who know it.

    28. Re:Not JVM by Anonymous Coward · · Score: 0

      You're an idiot. Oracle is suing Google over the SSO of 37 Java API packages. Do some research next time, idiot, and you just might know what you're talking about.

    29. Re:Not JVM by Tablizer · · Score: 1

      Well, okay, I will agree that it can make a fairly large impact on general language design, but it seems there's a need for BOTH kinds of GC handling, and it's probably still better to have a "near twin" pair of languages that caters to both types to simplify the learning curve and perhaps library creation.

      Making it a mere keyword or compile switch would be nice, but if the differences MUST be great enough to force having two different languages, at least make them similar. Maybe there is a way to consolidate that nobody's thought of yet...

    30. Re:Not JVM by Chalnoth · · Score: 1

      I think it's very possible (even reasonable) to have a language which provides the option between different sorts of memory management. My point was mainly that it's really difficult to modify Java to use reference-counted memory management instead of the current garbage collection scheme. It's also going to be very difficult to move Android off of Java.

      Currently Android developers can help the memory management situation by using the NDK and using C or C++, but I don't think that's very common. These languages tend to result in more complicated code than Java.

  8. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by pushing-robot · · Score: 5, Funny

    compile it to JavaScript for deployment

    I have officially lived too long.

    --
    How can I believe you when you tell me what I don't want to hear?
  9. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Anonymous Coward · · Score: 3, Insightful

    Poorly.

  10. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Anonymous Coward · · Score: 5, Informative

    The browser developer tools actually support source "map" files that allow you to step through the source - it's already used in the case where you concatenate and minify multiple javascript files into one

  11. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by TheReaperD · · Score: 3, Informative

    compile it to JavaScript

    That word. I don't think it means what you think it means.

    --
    "Be particularly skeptical when presented with evidence confirming what you already believe." -
  12. Google - A disconnected beast? by NaCh0 · · Score: 2

    Google has put a ton of effort into Go, why not add that as a first class language as well?

    I suppose Go/Java syntax are "close enough" at a high level. But kotlin? There are only so many ways to shuffle C & Pascal syntax before everyone is dazed and loses interest.

    1. Re:Google - A disconnected beast? by Anonymous Coward · · Score: 1

      Go has no classes, swift has, It would be painful migrating a large api surface that currently heavily relies on classes to a language that has minimal support for OOP.

    2. Re:Google - A disconnected beast? by Anonymous Coward · · Score: 1

      The lack of classes is a feature, and similar functionality can be achieved in a more elegant way. The absence of a rigid class hierarchy also allows Go code to be very flexible and easily adaptable. As an added benefit, there are also no exceptions. (only an elegant panic/recover mechanism, for truly exceptional circumstances...)

      Go is a simple and powerful language with a pleasant build environment. It would be very welcome as a first class language on Android, though Swift (or anything else really) would still be preferable to java. If having a common language on iOS and Android can take a bite out of Java, that would be more than worth the compromise.)

    3. Re: Google - A disconnected beast? by tshawkins · · Score: 1

      Yep agree, but if you are porting a big oop based api set, you want to minimise the adjustments the devs need to make to use it.

    4. Re:Google - A disconnected beast? by Anonymous Coward · · Score: 0

      ... As an added benefit, there are also no exceptions. ...

      LOL. That's not a benefit. That's a failing of the language.

    5. Re:Google - A disconnected beast? by Anonymous Coward · · Score: 0

      and similar functionality can be achieved in a more elegant way

      Sure but Go doesn't support any of those ways. Go is just a very shitty language and even most Googlers understand that and are fighting against it.

  13. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by HiThere · · Score: 3, Informative

    I think it actually does. At one point CDC was contemplating a machine that was going to use APL as the assembler language, to which other languages would need to compile if they were to run as native. So JavaScript can define a virtual machine that can be compiled to.

    Now whether that's a good idea is a different question.

    --

    I think we've pushed this "anyone can grow up to be president" thing too far.
  14. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Anonymous Coward · · Score: 0

    Dart from Google is pretty much that. We use it on several large client and server-side projects. It's worked spectacularly the past three years, but it does suffer from lack of focus from Google especially with regard to the test framework.

  15. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by binarylarry · · Score: 1

    It becomes web scale.

    --
    Mod me down, my New Earth Global Warmingist friends!
  16. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by binarylarry · · Score: 4, Funny

    perhaps there's a better term for this process?

    Kludging
    Webbing
    Derping

    --
    Mod me down, my New Earth Global Warmingist friends!
  17. What happened to C? by GuB-42 · · Score: 5, Interesting

    On GNU/Linux, you can use whatever langage you want as long as it supports the C calling conventions, and most of them do. Same thing for oldschool Windows and pretty much every system running native code.
    Why should a platform be tied to a particular language?

    1. Re:What happened to C? by Lisias · · Score: 2

      Because corps wants to have locked in mindset developers tied to their solution.

      --
      Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
    2. Re:What happened to C? by squiggleslash · · Score: 4, Interesting

      For what it's worth, you can program Android in C. It's not recommended.

      C is widely considered unsafe, a language that makes it far too easy to accidentally introduce security holes that end up with attackers being able to execute arbitrary code. Managed languages like Java aren't perfect, but they fix 90% of these errors, leaving developers able to focus on the types of error that are because something was badly designed, not because a buffer's size is too small for the data being read into it.

      Mobile operating systems have enough security problems as it is without making it easier for programmers to introduce more.

      Java, FWIW, has only two major problems: it's absurdly bureaucratic, and its master, Oracle, isn't really happy with anyone writing incompatible variants of it and is trying to prevent that from happening.

      Meanwhile, nothing else has taken off. C# is almost as bureaucratic as Java, and, well, then there's Swift, but I'm having difficulty believing Apple will be less possessive of it than Oracle is of Java.

      --
      You are not alone. This is not normal. None of this is normal.
    3. Re:What happened to C? by GuB-42 · · Score: 3, Interesting

      C is widely considered unsafe, a language that makes it far too easy to accidentally introduce security holes that end up with attackers being able to execute arbitrary code. Managed languages like Java aren't perfect, but they fix 90% of these errors, leaving developers able to focus on the types of error that are because something was badly designed, not because a buffer's size is too small for the data being read into it.

      Right, but the core of Android (where security matters the most) is actually C or C++. In unprivileged mode, where apps run, security is important but not as much, because that arbitrary code will have no more permissions that the exploited app. Also, nothing prevents you from using a safe language that have C bindings.
      But there are advantages to managed languages, which bring me to...

      Meanwhile, nothing else has taken off. C# is almost as bureaucratic as Java, and, well, then there's Swift, but I'm having difficulty believing Apple will be less possessive of it than Oracle is of Java.

      C# is just the tip of the iceberg, the CLI backend is the interesting part here. There are plenty of languages that target the CLI platform (see: https://en.wikipedia.org/wiki/... ), no lockdown here. For me, this is how managed should be done. And now that Microsoft opens up a bit, that's even better.

    4. Re:What happened to C? by Anonymous Coward · · Score: 0

      Language bindings and ABI are only one part of the problem.

      When you get to runtime environments you have to think about the parallelism and concurrency models. Too many C libraries either presume they can block the thread, or they require callbacks. Both of those can break various assumptions in the host language runtime.

      Well written C libraries neither assume blocking nor require callbacks. Like the read syscall, a function or method will return EAGAIN (or an equivalent value) that says you need to try again, as well as provide access to underlying resources like file descriptors that tell you when to try again. But that requires runtime environments or library frameworks to expose a proper API to regular code, which even fewer do.

      Example: Go. While you can seamlessly call into C from Go, Go will switch you to a special stack (for several reasons). So if all your goroutines are regularly calling into C libraries, you lose the light-weight goroutine footprint. A well written C library could be written in a way that allows you to integrate it into Go's runtime (e.g. makes guarantees about required stack size by not using recursive functions, won't block on I/O, etc). But Go doesn't expose a runtime interface that allows you to do that.

    5. Re:What happened to C? by Anonymous Coward · · Score: 0

      While you can program apps using the NDK, you don't have access to the vast majority of Android API's. You can do low-level stuff but try writing a graphical Android application using only C. Or something that accesses any of the hardware (Bluetooth, Wifi, audio, gyro/accelerometers, NFC, etc). While all devices have low-level libraries for that stuff, they're all different and undocumented. The only documented Android interfaces are Java.

    6. Re:What happened to C? by MikeBabcock · · Score: 1

      Unsigned int would be awfully nice ...

      https://en.wikipedia.org/wiki/...

      --
      - Michael T. Babcock (Yes, I blog)
    7. Re:What happened to C? by phantomfive · · Score: 1

      Yeah, that's a good idea. Make the base libraries in C, then any language can use it.

      --
      "First they came for the slanderers and i said nothing."
    8. Re:What happened to C? by fuzzyf · · Score: 2

      I think C# is getting really interesting. Watching the language specs being discussed and implemented on github is very nice.

    9. Re:What happened to C? by jeremyp · · Score: 2

      I'm having difficulty believing Apple will be less possessive of it than Oracle is of Java.

      Swift is already open source and while the core developer team (Apple employees) retains a firm grip on the language's direction, they have a process whereby anybody can propose new features for the language.

      https://github.com/apple/swift...

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    10. Re:What happened to C? by NotInHere · · Score: 1

      I prefer a firm grip over a language over adding features without much afterthought, and then having to support those for all of eternity.

    11. Re:What happened to C? by jeremyp · · Score: 1

      Yes, for what its worth, I think Apple has the balance about right.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    12. Re:What happened to C? by jhol13 · · Score: 1

      1: Memory model. That is, how "volatile" *really* behaves. 99.9% programmers do not understand volatile (i.e. memory barriers in SMP, etc).
      2: Threads. 90% of programmers do not understand threads, and of those who do, most have no clue how memory barriers and atomic operations work.

      We need a language where explicit threading is not needed. We do not (yet?) have one.

    13. Re:What happened to C? by Nemyst · · Score: 1

      Actually, I'd say that C# is a pretty good middle ground. It still has a "master" in Microsoft, so you don't have the design by committee issues (no clear direction, slow development cycles, etc.), but they've also been listening to feedback and implementing it pretty consistently, on top of adding their own stuff. As a result, C# has evolved really quickly and overtook Java many releases ago. They keep pumping out more features, from the convenient to the groundbreaking, with every release. With the opensourcing of many elements of the language, C# could actually be an excellent alternative to Java for Google to consider (and with Xamarin, they already have an idea of what it'd look like).

    14. Re: What happened to C? by Anonymous Coward · · Score: 0

      What drives a man to post things like this? Is it hatred or disgust directed outwards? Show us on the doll where the weakly typed interpreted language touched you.

    15. Re:What happened to C? by SoftwareArtist · · Score: 1

      Android does let you write your apps (or at least, the bulk of them) in C or any other language your want. But it's not the recommended approach. A lot of its libraries are written in Java, so you have to jump through a few extra hoops to use them if your code is running outside the VM. And you have to worry about providing binaries for different architectures, whereas with Java it takes care of that for you.

      So you presumably could already use Swift when coding for Android. But that's not what this is about. It's about Google turning Swift into a "first class" language and making it easy for you to use it on Android.

      In the same way, you can use Java to code for Linux, but it's never really been a first class citizen. You have to jump through hoops to use a lot of libraries and to integrate naturally with the rest of the system. Sun and Oracle have put a lot of effort into trying to work around that, but it's still an issue. Every platform supports some languages better than others. They just differ in which languages those are.

      --
      "I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
  18. Embrace,extend and extinguish by Anonymous Coward · · Score: 0

    always a viable strategy if you're big enough...

  19. Apple fucked up by Anonymous Coward · · Score: 0

    Open sourcing Swift is looking like a bad move for Apple. They just allowed Google to take all the fruits of their development *for free!* Google doesn't have to spend resources to build it's own language and it removes a hurdle for iOS devs becoming Android devs. SMH.

    1. Re: Apple fucked up by Anonymous Coward · · Score: 1

      Software development is no a zero sum game.

    2. Re:Apple fucked up by D.McG. · · Score: 3, Informative

      Apple open sourced the language. They did NOT open source UIKit, CoreAnimation, etc. Many iOS devs are Android devs as well. While this will allow for a common language between the UI and the shared C++ code, the UI code will still be platform specific.

    3. Re: Apple fucked up by topham · · Score: 1

      I love the idea. I've got swift running in a raspberry pi and will be using it develop a game; while I've also done iOS development and want to keep my skills there too.
        I love it. Bring me a well designed, performant language any day.

    4. Re:Apple fucked up by Gr8Apes · · Score: 1

      It is actually looking like a great move on Apple's part. More people using Swift, more potential developers.

      --
      The cesspool just got a check and balance.
  20. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by radarskiy · · Score: 3, Funny

    Why do you hate YACC?

  21. Re: God damn it, just PICK A FUCKING LANGUAGE ALRE by Anonymous Coward · · Score: 0

    Not as bad as binary debugging. If you want to do js debuggingfor a higher level language, you have too much time on your hands.

  22. Might want to open source by Anonymous Coward · · Score: 1, Insightful

    Android Studio first.
    All the open talk is so false.

    1. Re:Might want to open source by Tony+Isaac · · Score: 1

      There's always Eclipse, if you really want an open source IDE for Android. Ugh.

    2. Re:Might want to open source by MikeBabcock · · Score: 1

      How is the open talk false because something isn't open?

      --
      - Michael T. Babcock (Yes, I blog)
    3. Re:Might want to open source by non0score · · Score: 2
    4. Re:Might want to open source by PCM2 · · Score: 1

      The IDE for Android used to be Eclipse, but Google ended that.

      --
      Breakfast served all day!
  23. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Anonymous Coward · · Score: 2, Funny

    You're an idiot. A compiler takes code written in one language and translates it in to code written in another language. That the source and target languages are typically a high-level language and a machine language is irrelevant.

    Find yourself a copy of the dragon book. It's right there at the beginning.

    Kids these days...

  24. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Anonymous Coward · · Score: 0

    And it will continue to suffer. Google has essentially abandoned it like so many other silly projects. The only reason it gets any attention is the investment they moronically made in the language. It will continue to rot for a few more years before it becomes a distant memory to all but a few frustrated maintenance developers.

    Never invest in a fad language. Particularly one from a company with a long history of abandoned projects. Especially a fad language intended to solve a minor problem with a popular mainstream language that introduces horrendous complexities and problems well over and above those caused by the minor problem the fad language was intended to eliminate.

    You deserve everything you get.

  25. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by binarylarry · · Score: 3, Funny

    Hold on.

    Before I can parse your expression, I must first derp the statement into javascript.

    Web scale, bitches!

    --
    Mod me down, my New Earth Global Warmingist friends!
  26. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by rtb61 · · Score: 0

    The reality is just like the English dictionary for the English language, everyone needs a core computer dictionary for a core computer programming language around which schools can base computer education programs. So to facilitate teaching computer studies at earlier ages, more needs to be done to dump qwerty in favour of the ABCs (easier to teach children and adults should simply relearn), and better logical alignment of the English language and computer language and maths formulas and computer language formulas. At the very least a core language, a starter computer programming language that can taught all over the world, free of encumbrances, patents et al.

    --
    Chaos - everything, everywhere, everywhen
  27. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by DraconPern · · Score: 2

    You are describing asm.js. It's scary, and amazing at the same time.

  28. Re: God damn it, just PICK A FUCKING LANGUAGE ALRE by pchasco · · Score: 1

    Transpiling to JavaScript is a decent crutch for those who prefer another language over JavaScript, but even with transpiling you cannot escape the semantics of the JavaScipt environment (barring writing a VM in JavaScript). The one major benefit that I have experienced in using TypeScript is that it enables some common mistakes to be caught at compile time, as well as better support for refactoring tools. The one drawback to working with Typescript that I've experienced is .d.ts files. DefinitelyTyped helps a lot, but I've found that they are typically just wrong enough that they cause more headache than they're worth for all but he most well-supported libraries.

  29. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by keltor · · Score: 1

    Actually ... this is exactly how you use compiled. You compile C to an intermediate language (possible just a special type of ASM, but an intermediate language all the same.) You compile Java to Java Bytecode. So yes you can in fact compile C to Javascript. In the very long term, we could build a better safer intermediate language and compile everything to that.

  30. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Anonymous Coward · · Score: 1

    If you treat JavaScript as "machine language" to which the client side of a web application is transpiled, how does source-level debugging work?

    The same way it does for any language compiled into a machine language.

  31. What this really means... by __aaclcg7560 · · Score: 1

    1. Google adopts Swift programming language!
    2. iOS developers port their iPhone apps to Android!
    3. ...
    4. Profits!

    1. Re:What this really means... by Kartu · · Score: 2

      I frankly think this is most likely just an attempt to bring attention to Swift.
      It's hard to imagine Google switching to it, to say the least.

    2. Re:What this really means... by BasilBrush · · Score: 1

      Yeah, that'd be like Google basing their Browser on Apple's open sourced WebKit... and then forking it... Oh...

  32. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Anonymous Coward · · Score: 0

    Yes, it's a precompiler that translates the code to an intermediate state prior to its final state.

  33. How "same" is it? by tepples · · Score: 1

    If you treat JavaScript as "machine language" to which the client side of a web application is transpiled, how does source-level debugging work?

    The same way it does for any language compiled into a machine language.

    So how do I attach, say, gdb to the JavaScript virtual machine of Firefox?

    Or perhaps you did not mean "The same way" so literally. In that case, what would you describe as the same between debugging a program compiled to a machine language and debugging a program transpiled to JavaScript, and what would you describe as different?

    1. Re:How "same" is it? by exomondo · · Score: 1

      So how do I attach, say, gdb to the JavaScript virtual machine of Firefox?

      I doubt gdb supports such a thing.

      In that case, what would you describe as the same between debugging a program compiled to a machine language and debugging a program transpiled to JavaScript, and what would you describe as different?

      I assume the OP probably has a similar view but you need your source and your symbols so that you have that link between the source code and the compiled code.In the case of javascript it is called a "source map" and all the major browsers support them.

    2. Re:How "same" is it? by Anonymous Coward · · Score: 0

      In that case, what would you describe as the same between debugging a program compiled to a machine language and debugging a program transpiled to JavaScript, and what would you describe as different?

      There is no difference but why do you think there would be any? Think of javascript as the "machine language" in this case and the machine it operates on is the browser's javascript engine. For an example if you were to code in TypeScript you can set your project settings so the compiler generates a source map file and you can then attach visual studio's debugger to chrome or edge or firefox (pretty much any browser that supports source map debugging of javascript) and debug your TypeScript code.

    3. Re:How "same" is it? by tepples · · Score: 1

      chrome or edge or firefox (pretty much any browser that supports source map debugging of javascript)

      Thank you. That was the piece I was worried about.

  34. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by yithar7153 · · Score: 1

    I wrote that on my compilers midterm #1 and I got points taken off :( When we got them back, my professor explained yeah that's what a compiler does but that's not the whole thing. Then he proceeded to tell us a story about how students raced to eat their lunch and one guy always won. But he wasn't a fast eater. Before they said go, he'd shout WAIT! and dump his mashed potatoes onto his plate, then the gravy, then the turkey, then the grapes and then pour milk all over it and stir it. Then he'd say he was ready and slurp it down. And that's what a compiler is supposed to do.

  35. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Anonymous Coward · · Score: 0

    We must teach the following:
    Some variant of BASIC for a first introduction
    Shell environments (basic interaction) - BOTH Unix and Windows
    C (basics)
    Something like C++, C#, or Java... preferably all three
    Common Lisp
    Another high level language like Ruby, Python, etc
    Something like F#, ML, Haskell

    People are in school for a long time, plenty of time to build that up.

  36. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by irrational_design · · Score: 1

    The OP needs to be upvoted. Source Maps is the correct answer.

  37. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by irrational_design · · Score: 1

    Do you prefer transpile?

  38. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by irrational_design · · Score: 1

    transpile

  39. I like swift but its still half baked by floatpt · · Score: 1

    I have been developing on Swift for about 6 months now for a project. Today I discovered that in Swift 3, increment(++) and decrement(--) operators are being removed (as well as some other things). Our project isn't that big, so it won't take long to fix the 400 or so warnings that this has introduced, but it's probably causing real pain to anyone maintaining a larger code base. I like Swift, and am glad to hear its popularity is increasing so quickly, but I would like to see it stabilize.

    --
    d-_-b
    1. Re:I like swift but its still half baked by Anonymous Coward · · Score: 0

      A language, that is not even half the age of Java, and it is already making backwards incompatible changes... in other words, another C#. They've lost me already.

    2. Re:I like swift but its still half baked by NotInHere · · Score: 1

      Lol, funny. Swift with its millions of operators actually removes one.

    3. Re:I like swift but its still half baked by jeremyp · · Score: 1

      I followed the debate about removing them on Swift-Evolution and at the time I was meh. However, I'm finding that I miss them. Maybe it's just muscle memory, however, I wish I had objected at the time.

      There are a lot of breaking changes being proposed for Swift 3. While I don't think breaking changes should be banned because such a rule can stifle language development (see Java for example), I don't think the core team sets the bar high enough and I think they will get a bit of a shock at the backlash following the release of Swift 3.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    4. Re:I like swift but its still half baked by jeremyp · · Score: 1

      It's removing four actually. x++, x--, ++x, --x

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    5. Re:I like swift but its still half baked by Anonymous Coward · · Score: 0

      The very day it was announced, Apple said they'd be making significant breaking changes for the next two years. (This timeframe will be up with the release of swift 3.) They wanted to see how the language would get used and what sort of ideas came up during real-world usage rather than get stuck forever dealing with what may have turned out to be suboptimal assumptions. Anyone who isn't interested in dealing with an evolving language could continue to use objective C - it didnt go anywhere.

    6. Re:I like swift but its still half baked by Anonymous Coward · · Score: 0

      Millions? The standard library has about 40, the vast majority being equivalents to standard C operators.

    7. Re:I like swift but its still half baked by BasilBrush · · Score: 1

      I work on a code base of multiple mature apps, originally written in Obj-C, but gradually being transitioned to Swift.

      It took a couple of hours to fix everything up. Most of it is automatic fix-ups. I'm glad for the change as it'll stop one of my co-workers writing stuff with this archaic syntax. The alternatives to "for (;;)" in particular are all superior.

  40. Re: God damn it, just PICK A FUCKING LANGUAGE ALRE by Anonymous Coward · · Score: 0

    It also can't interface with the dom

  41. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by phantomfive · · Score: 1

    WebAssembly is on the way. Soon you'll be able to program in any language for the browser.

    --
    "First they came for the slanderers and i said nothing."
  42. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by davester666 · · Score: 1

    Everybody has to debug your web site?

    --
    Sleep your way to a whiter smile...date a dentist!
  43. Why not just use c#? by Barlo_Mung_42 · · Score: 2

    It's already open source and it already runs well on Android. What do they think they'll gain by doing a bunch of work to use Swift?

    1. Re:Why not just use c#? by Anonymous Coward · · Score: 0

      Does it? I had no idea Android shipped a .net virtual machine.

    2. Re:Why not just use c#? by Anonymous Coward · · Score: 1

      see xobot os, a fork of android where xamarin replaced the dalvik with mono

    3. Re:Why not just use c#? by Barlo_Mung_42 · · Score: 1

      It does. Xamarin is pretty cool.

  44. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Anonymous Coward · · Score: 0

    Compiler is a program that translates one language into another. I have no idea what a precompiler does, it compiles before it compiles?

  45. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Anonymous Coward · · Score: 0

    Your professor had suffered a stroke and nobody noticed. He/she must have been on tenure. The professor was also most qualified to teaching compilers, because of the stroke. He probably also taught number theory or really deep axiomatic number theory. There You can babble nonsense and nobody notices.

  46. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Anonymous Coward · · Score: 0

    Especially a fad language intended to solve a minor problem with a popular mainstream language that introduces horrendous complexities and problems well over and above those caused by the minor problem the fad language was intended to eliminate.

    You deserve everything you get.

    You pretty much described C++ and Rust at the same time.

  47. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by KGIII · · Score: 1

    His professor was the reincarnated Cantor.

    --
    "So long and thanks for all the fish."
  48. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by KGIII · · Score: 2

    I'd argue that they also need to learn the history of computing and networking as well as the physical components (how they actually work - physically) and the basics of safe hex. I'd say that those are just as essential as any use is at this point in time. A good grounding in real computer science should actually cover the science of computing, no? They should actually know that what they're using is a tool and, like all tools, it should be operated both with skill and safety. In order to do that, one needs to truly understand the reasons that things are the way they are.

    Beyond that, or along side that, they could learn the software aspects that you're suggesting. However, learning to program is not learning computer science. Learning to program does have value but that would be greatly improved by actually having a healthy dose of computer science so that they can tie it all together. If we just want cheap code monkeys, we can go buy those. If we want people who are actually skilled, we have to teach that.

    I think that one, without the other, is not nearly as valuable as both of them combined. Someone who understands what ring 0 is actually might understand why code that doesn't race is imperative. Someone who understands the history, will know what mistakes have been made and learn from them. Someone who has an understanding of the networking, how it physically works, might actually be able to code with security in mind. Someone who knows the actual physical aspects of memory will understand that buffer overruns are bad - and why. Then, they will know who, what, when, where and how they worked to avoid them. They'll understand what sanity checking actually means and why it's essential.

    And those that can't? Well, someone's gotta work help desk, manage, and be QA.

    --
    "So long and thanks for all the fish."
  49. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Anonymous Coward · · Score: 0

    It is like pre-heating. It heats before it heats.

  50. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by jandersen · · Score: 1

    Damn it Google, just pick a fucking language already ...

    Really? In my experience, this is one activity that doesn't in itself require much in the way of language skills; others may have a different perspective, of course.

  51. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Anonymous Coward · · Score: 0

    So essentially, You are saying that a browser will become a platform to distribute binaries? Because that's pretty much what You are suggesting.
    Alternatively, You might mean that there will be a standard for the javascript VM, which is pointless because all browser vendors already interpret extisting standards however they want.

    Basically, I might also write an interpreter for any language in javascript, so writing in $my_favorite_language is already not a problem. My problem is debugging, not writing.

  52. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Hognoxious · · Score: 2

    And those that can't? Well, someone's gotta work help desk, manage, and be QA.

    And if they can't do any of those, they become UX designers.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  53. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by phantomfive · · Score: 1

    So essentially, You are saying that a browser will become a platform to distribute binaries? Because that's pretty much what You are suggesting.

    Yes
    (there will still be the HTML/CSS component which is not a binary)

    --
    "First they came for the slanderers and i said nothing."
  54. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by KGIII · · Score: 1

    LOL That's lower than even *I* was went.

    --
    "So long and thanks for all the fish."
  55. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Anonymous Coward · · Score: 0

    We already had that. We had java applets, flash, activeX and probably some other garbage that I can't think of. Remember web-pages written only in flash? Because I do. Now You want to sell this crap again to me. The next great idea will be to create something that is essentially only a web browser with some rudimentary OS capabilities added to it, and sell that. So we will have a vm (browser) that runs bytecode (webassembly), which is exactly java, and with exactly the same problems as java. Oh wait, node.js.
    All with the cruft of what is basically obfuscated javascript, with only one advantage: it runs faster. So now I can have ads load even faster.

  56. Have they learned nothing? by sad_ · · Score: 2

    Google has, how many languages that they developed themself available they can use?
    But still they would pick a language, not developed themselves, but by a competitor.
    And they would do this why? Because they didn't learn from the whole Java debacle?

    --
    On a long enough timeline, the survival rate for everyone drops to zero.
    1. Re:Have they learned nothing? by Anonymous Coward · · Score: 0

      They're picking the best language for the job rather than an inhouse language that's not as suitable. (Kotlin is a much nicer language than Dart, for example.)
      They're also making life easier for developers that want to target both iOS and Android.

      As for licensing, both Kotlin and Swift are Apache-licensed, so Google can do pretty much anything with them and it's safe from patent suits too.

    2. Re:Have they learned nothing? by Chalnoth · · Score: 1

      I don't think there's any reason to believe that the Apache license alone means they'd be safe from patent suits.

  57. Response to Xamarin by MadcapMac · · Score: 2

    This has all the smell of a response to Microsoft's purchase of Xamarin. By extending their reach, Google is attempting to diminish the effect C# may have on their ecosystem.

    1. Re:Response to Xamarin by Anonymous Coward · · Score: 0

      Makes sense. With the acquisition of Xamarin and Microsoft's other changes to .Net, you can now write an application in C# and get it to run almost anywhere, Windows, Linux, OSX, iOS, and Android. It's becoming the Java killer it was always intended to be.

  58. Why don't they use GO? by thatjavaguy · · Score: 2

    I know that Go is being pitched as a systems language - but surely it would be easier for Google to do the work necessary to switch to Go and improve it than use Swift.

    Based on my (brief) look at Swift it seems to me that they have tried to be too clever by half - throwing everything in to it. Love or hate Java, C, Go - they have the benefits of being clean and simple languages.

    1. Re:Why don't they use GO? by Anonymous Coward · · Score: 0

      Because Go sucks, and they know it. Go doesn't have generics. Go doesn't have real class-based OO. Go is just a hobby of some influential, but outdated, oldtimers who are living out their last years at Google. Serious programmers don't use Go.

    2. Re:Why don't they use GO? by Anonymous Coward · · Score: 0

      But then there is the danger that you end up screwing up Go so it serves neither task well.

      One of the big points of Go is to keep things very basic and simple, a goal that works well for the current use case for go. That likely is not going to be compatible with the needs of Android (just look at how C# and Java keep getting ever bigger).

  59. Dear idiot Google! by Anonymous Coward · · Score: 0

    Python, Lua or even Javascript.
    Not Object-C, not Swift, not whateva Apple craps out...

  60. More Lawsuits by Anonymous Coward · · Score: 0

    That way they can be sued by both Oracle and Apple

  61. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by LWATCDR · · Score: 1

    Good or not the idea is useful.
    You want to write code to run in the browser but not in javascript.
    Browsers support javascript.
    Solution?

    Is it a compiler? That is up for debate since I have seen programs that translate between pascal and c and they are called a translator.
    I guess it comes down to how you define javascript is it a language or a vm? In the end it doesn't matter much since this is a tool that does something useful.

    --
    See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
  62. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by Anonymous Coward · · Score: 0

    It's being used correctly here.

    Even a C compiler actually compiles to assembly before the assembler produces machine code. It's possible (though largely an obsolete skill) to edit the compiled assembly code before assembling it.

    Not to mention all the modern languages that compile to bytecode for a runtime interpreter.

    Compiling to javascript isn't conceptually any different.

  63. Apple will love you for this! by Anonymous Coward · · Score: 0

    By Google writing horrific Swift code they can help pollute the Swift community like they've done with the Java community.

    1. Re:Apple will love you for this! by Vlijmen+Fileer · · Score: 1

      I don't think Java ever needed that type of assistance.

  64. It is still here (was Re:What happened to C?) by atrimtab · · Score: 1
    Why do so many of the "new" languages remind of good ol' fashioned UCSD Pascal p-code or even original Microsoft BASIC where everything is compiled to a tokenized intermediate platform independent pseudo assembly language that is interpreted or JIT compiled to the native CPU on the fly.

    In the 70s and 80s and 90s the stuff designed this way ran slow slow slow. And all the new similar designs still do compared to code compiled or assembled to run on the target processor.

    Give me a safer C like what Rust appears to be. Something that produces fast native code, but prevents programmers from doing stupid stuff.

    Let's not even get into the disaster that Javascript is in the browser: Download a tarball of Javascript and execute: What browser am I running in? If this is browser of version X run this pile of code instead of all these other special piles for other browsers with multiple versions.

    C hasn't gone away because it continues to be the best tool we have for producing fast code.

    Don't believe me? Write almost any program in both C and ??? (except assembler) then run them on the same platform. Compare.

    --
    Facebook is billions of individual "Skinner Boxes." And if you use it you are the pigeon!
    1. Re:It is still here (was Re:What happened to C?) by BasilBrush · · Score: 1

      C only has the fastest code because it has no safety. Use modern container classes that are safe, and it's no faster than other fast languages. In virtually every case the lack of safety for speed trade off of C is no longer necessary.

      C still exists for the same reason COBOL exists, but it simply isn't as far down the road yet.

    2. Re:It is still here (was Re:What happened to C?) by Anonymous Coward · · Score: 0

      C only has the fastest code because it has no safety. Use modern container classes that are safe, and it's no faster than other fast languages.

      C with classes?

      I thought they renamed that to "C++" !

  65. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by radarskiy · · Score: 2

    Cannot unread: http://zaa.ch/jison/docs/

  66. app privilege on Jellybean by emil · · Score: 1

    In unprivileged mode, where apps run, security is important but not as much, because that arbitrary code will have no more permissions that the exploited app.

    I do not agree with this statement. The Towelroot kernel vulnerability impacts some KitKat and all versions below - any app that is able to download a small binary and run it from a shell can obtain root privilege.

    KitKat and below are over 50% of the Android ecosystem at the moment, and app privileges are dangerously weak there.

  67. Control by Vlijmen+Fileer · · Score: 1

    What's with companies inventing their own, superfluous, languages?
    Simple: It's about control. By not using one of many available, non-company controlled free languages, you increase your stranglehold of "your" ecosystem, giving more options to abuse^Ddemonetise your customers.
    So why would Google even consider using one such monster, when while being touted as having been open-sourced, its obviously under control of its competitor?

  68. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by microbox · · Score: 1

    In the same way that you can do source-level debugging in C/C++, even though it get preprocessed. Coffeescript has features like this for source-level debugging in webbrowers.

    --

    Like all pain, suffering is a signal that something isn't right
  69. Re:God damn it, just PICK A FUCKING LANGUAGE ALREA by gohmifune · · Score: 1

    So essentially, You are saying that a browser will become a platform to distribute binaries?

    This has been the case for a very long time. If anything, I would argue the only reason why we've had JavaScript for so long is that there really haven't been other languages worth replacing it with until recently. Now, it is really feasible to use your server-side language as your client-side one as well.