Kotlin General

This is the general thread for the Kotlin programming language. https://kotlinlang.org/ Kotlin is a statically-typed OO language heavily influenced by and inter-operable with Java; existing Java APIs or libraries work with Kotlin. Its main compile target is JVM byte code, though it can also compile to JavaScript. Compilation to native code is in the works. It greatly reduces the verbosity of equivalent Java code through a more expressive and comfortable syntax. For example, some control flow statements are expressions in Kotlin, which allows you to write code such as: val max = if (a > b) { print("Choose a") a } else { print("Choose b") b } Or: val a: Int? = try { parseInt(input) } catch (e: NumberFormatException) { null } Kotlin also provides null-safe types. Any variable which doesn't have a type suffixed with `?' cannot be null. There are quite a few other nice features in Kotlin. A comprehensive guide can be found here: https://kotlinlang.org/docs/reference/basic-syntax.html It's being developed by JetBrains, the company behind IDEs such as IntelliJ IDEA, PhpStorm and CLion. Google have announced that they will officially support Android programming with Kotlin. This will no doubt have a positive effect on the languages life expectancy and ecosystem. https://blog.jetbrains.com/kotlin/2017/05/kotlin-on-android-now-official/ Have you tried Kotlin yet? What are your thoughts on it?

From what I can tell, it looks like a nice language to use in an enterprise setting where you don't want to big of a skill gap to emerge between between employees. I wouldn't use it for my own projects but if I were to apply for a job, I'd pick it over Java.

I've tried to write an Android app with it a few months ago, it didn't go well but I got to see a bunch of the language's features. IDEA support is pretty good, and it helps you translate Java into Kotlin. Interop between the two languages is also effortless, you can incrementally rewrite a Java program in Kotlin without any boilerplate. To me it feels like a better version of Java and not much more, because there's not much about this language that would make me pick it over Clojure or Scala or some other more interesting JVM language. I'd pick it over Java any day of the week, but that's not saying much.

When I took a look at it, my first impression was that it was a lot like swift. I wasn't the only one to think that: http://nilhcem.com/swift-is-like-kotlin/

I've only taken a cursory look at it, but I definitely like what I see. Especially the way they syntactic-sugar'd their Maybe-type pleases me. I've never gotten enough into Lisplikes to pick up Clojure, so maybe this can be what wins me over to do Android dev again.

>>1310 Well, this language climbed the pypl index really quickly: http://pypl.github.io/PYPL.html

>>4160 I just ended up trying it out for the first time today. The integration with IntelliJ's IDE is top notch, I especially like how you can paste Java code into a Kotlin file and have the IDE automatically convert it into Kotlin code.

>Kotlin also provides null-safe types. Any variable which doesn't have a type suffixed with `?' cannot be null. This is a huge improvement over the traditional reference to object type used by Java that lets any object be null. It's worth using for this reason alone; binary compatibility with JVM bytecode means you lose nothing by using the language. C# also evolved this feature. If I remember correctly, the compiler supports transformation of Type? into Type; when you test for null using if, the type of the variable becomes non-nullable inside the associated block. Does Kotlin also have this feature?

>>4181 Support for null references in Java was a huge mistake There are so many bugs caused by careless devs forgetting to check for null There are so many millions of lines of assertions and tests to check for null They should have had a sort of typeless no value object, like Python's None

>>4191 >They should have had a sort of typeless no value object, like Python's None I'm genuinely interested, could you give a rundown on the differences between Java's null and Python's None? I always thought of them as more or less the same.

>>4192 Java's null is just a null pointer. Under the hood, Java's object references are just pointers to an object on a heap When you attempt any operation requiring a deference of a Java object reference, this causes a NullPointerException if the reference is null This is expected behavior in a more C like language where you have the ability to manage memory yourself and control pointers directly However, in a garbage collected OOP environment like Java you are less consciously aware of the fact that references are really pointers to stuff on the heap The java syntax dereferences reference types automatically, you don't need a * like in the C family, and that * helps remind you of what you're really doing In a language like C++ where you still have full control of the memory and pointers, you are more conscious of the possibility of a pointer being null In java, the existence of null pointers goes against the philosophy of the language and all the safety features build into the language, and makes it easy to fuarrrk up In contrast, Python's None is not a null pointer. Python uses reference types as well, but does not permit null references The keyword 'None' in Python is not really a special keyword in a sense, it is just a globally defined singleton object The python None object exists in memory, it has a type (NoneType), and has implementations of the magic methods for equality testing, string representation and more Since it is a real object that really exists on the heap, you can say stuff like "VariableName == Expression" in a test and that's ok even if VariableName might be None Whereas in java, if you were to say "VariableName.equals(Expression)" in a test and VariableName was null, your program will crash Its also worth mentioning that in Python "==" tests equality not identity. Java uses "==" for identity for references and ".equals()" for equality, which is ugly imo I guess it comes from the fact that Java has primitive types as well as reference types, which is another design flaw, Java would be better off if it were pure OO The python syntax for equality testing makes more sense, since testing equality is usually what you want. Python can still test for identity with "is" though if needed Since the python NoneType object has an implementation of __eq__, you don't have to explicitly test for None, since None.__eq__ returns false for anything other than None In java, you frequently see stuff like "if (VariableName != null && VariableName.equals(VariableTwo))" which is just a PITA to write and you might forget to check for null Python's approach with null allows you to say "if VariableName == VariableTwo" without having to worry about testing for None explicitly Also, since None has __bool__ implemented, you can just say "if VariableName:" or "if not VariableName:" to test if the var is null, zero, False, anything like that, which is very clean In python, None behaves just like a normal object in most ways, and attempting to call methods on it will be attribute errors, not null pointer exceptions That allows you to have an object that you can use as a placeholder without having to risk crashes or anything like that

>>4198 That's just having a special object be treated as null by the language implementation. Ruby had the same feature; you can call methods on nil. This is a cool feature for dynamically typed languages. Note that calling undefined methods on these objects will raise errors which will stop programs just as cold as a NullPointerException. Kotlin probably allows null just like Java does. The difference is it separated null from object types, so that Type is guaranteed to hold an object while Type? may hold an object or null.

>>4200 Also it has a bunch of operators that basically give you very basic monadic error handling. For example, foo?.bar() will evaluate to foo.bar() if foo is not null, or it will evaluate to null if foo is null. There is also an elvis operator foo :? bar which will evaluate to foo if it isn't null, and bar if it is. This makes handling nulls very convenient. With that said, after trying out the language for a while, I felt that I didn't really get any sense of intrinsic enjoyment from using the language like I feel when writing say Haskell/Julia/Rust/Clojure/Python. It just feels like writing boring old Java, except that it's slightly better at interfacing with Java libraries than Java itself is. It completely eliminates/automates a lot of the boilerplate and adaptor class BS and ahs a bunch of syntactic sugar specifically for delaing with Java libraries that introduce the whole kingdom of nouns hell. For example, you can pass a lambda to a java function that expects a SAM interface objects and it will just work. With that said, while it is a bit boring, Kotlin is a very practical language. The cost of switching from Java is basically zero. The gain is immediately noticeable, though it's not necessarily as expressive as many other language. If I was an executive at a software company that used Java, I'd be all over that soykaf. In that sense it feels slightly worse-is-better in the way that it empathizes ease of switching over long-term potential ensuring that it will grow very quickly in adoption once it's declared as a standard.

If you have discipline to test the fuarrrk out of your programs, surely you can avoid NullPointerExceptions.

>>4203 If you have discipline to write good code, surely you can avoid using higher level languages and just use assembly.

>>4205 Well then, let's put EVERYTHING as syntactic sugar of programming languages. Makes a lot of sense. Why to bother the programmer for ensuring the correctness of the program?

>>4208 The whole point of computers is to automate tasks. Why shouldn't the compiler automate checking for null? They do for all sorts of other features already

>>4208 The whole Type+null thing is a rather minor adjustment to Java's type system. The whole checking process happens at compile time; you lose nothing by using it. Makes it easier for the programmer to check for null by denoting right on the types of variables whether they can or can't hold null. Dereferencing a Type? object becomes illegal and a compile-time error; you must turn it into a Type first by checking for null.

>>1310 Meh. Kotlin is an improvement on something I didn't want to use in the first place. I'd prefer to start from scratch on a language I want to use.

>>4215 i think a big part of the appeal is being able to reuse existing java libraries if you've never worked in the enterprise world, its impossible to fully stress to you just how much old, obsolete, soykafty java is out there that still has to be used because there's no time to rewrite it

>>4216 I have, and I think the solution is to stop writing Java entirely instead of bolting on another language. The problems that make Java bad are only partly Java's fault; it's the enterprise atmosphere that perpetuates the stereotype.

>>4218 I think there's no one pointing a gun to your head and obligating you to code in Java.

>>4218 >The problems that make Java bad are only partly Java's fault; it's the enterprise atmosphere that perpetuates the stereotype. This is something I also realized recently. I had to write a medium sized project (~3 klocs without tests) in Java for university. As it turns out, the functional features of Java 8 aren't half bad. If you just steer clear of all of the pattern cargo culting, Java isn't as bad as most people make it out to be. The truly annoying stuff is all cultural.

>>4218 >I think the solution is to stop writing Java entirely instead of bolting on another language. Any suggestions on how to make everybody switch their whole infrastructure with something else?

>>4218 >I think the solution is to stop writing Java entirely instead of bolting on another language >not respecting legacy code that people depend on Hey, if you insist on being irrelevant...

>>4222 >If you just steer clear of all of the pattern cargo culting It may be cargo cult now since nobody even knows why people came up with things like factories anymore but there are real reasons for their existence. I talked about this in the Java thread. The truth is they exist to get around limitations of the Java language. Factories are just better constructors that allow you to return whatever type you want. Object constructors invoked with new can only return an object of exactly one concrete type but a method can return an interface type and allow you to change the actual object being constructed any time you want. It hides new behind a method. If you don't do this, every caller who uses new on your class is tightly coupled to it and if you delete that class you break their code. Better languages turned new into a method that can return any object and can be overridden. In those languages new is a factory method so you don't have to create factories yourself.

>>4218 >>4219 Its not that we're starting new projects in java Its the 20+ year old codebases that we inherited and have to keep using Try convincing management at a large company to spend thousands of man hours rewriting legacy code Big companies run on a cover your ass principal All the managers know the legacy code has to go at some point None of them want to risk being the guy to approve a rewrite project if there's even the slightest chance something will break And things always break

>>4226 In addition to this, most companies just don't really care about their codebase. If you're a clothes manufacturer or an insurance company, your software development division is just another expense. Why the hell would you be undertaking a hugely expensive project to rewrite your infrastructure if it still works? Just to please the aesthetic sensibilities of your code monkeys?

>>4226 >Try convincing management at a large company to spend thousands of man hours rewriting legacy code Big companies run on a cover your ass principal Even fuarrrking Cobol today, there's tons of legacy code and nobody wants to rewrite it. If it works, don't fuarrrking touch it, that's their motto.

>Even fuarrrking Cobol today, there's tons of legacy code and nobody wants to rewrite it. If it works, don't fuarrrking touch it, that's their motto. Not only that, but a lot of Cobol codebases are still being extended to this day. There really is no reason for them to move away until maintaining it becomes more expensive that rewriting / migrating it.

>>4239 What could possibly make starting from scratch less expensive than maintenance? It's always going to work until the computer itself breaks down and, unless it's so unique that it's not even made anymore, you can simply buy a new one. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ This is why binary interfaces are important. If you can adhere to the same ABI the legacy software uses, you can use C to extend a Cobol program, or Kotlin to extend a Java program, or Pascal to call a C function, or use some sweet Fortran libraries from Python. It's a polyglot world out there.

>>4243 COBOL programs are gigantic. Typically you would want to have multiple programs operating on the same data, like one program to put sales records in a transaction file, one to sort the transaction file, one to apply the transaction to the master file, one to generate a sales report, one to generate a different kind of report, etc... However, COBOL didn't add support for subprograms or programs sharing record definitions, etc.. until the 85 standard, so it's not uncommon for you to see million line plus lines in the wild. If you want to do something slightly different than an existing program, step one was copy and paste the entire program. Additionally, in the 80s and 90s there was a huge fad of 3LL, third level languages, where you just specify what you want the report to look like and it generates code for you. A lot of that code was generated in cobol, and that was a sales point, if the 3LL failed you would be left with cobol code that could still be maintained. You don't see many 3LLs around today. Modern, more popular languages like java also lack many business oriented features. For example, numbers in cobol are always handled in base 10 and you can specify if you want to truncate or round numbers. So number like 1234.56 will always be held with a minimum of 6 bytes, one for each digit. If you had a rounding error on half your employees and you're doing payroll for a gigantic corporation it could cost you a ton of money. Java supports this with the BigDecimal class, but it's really bolted on and not easy to use. There are many other business oriented areas where cobol shines, like sorting an entire file of employees can be done in a record definition and 3 lines of code. To do it in java would take at least two classes and probably hundreds of lines. It also has a specialized report writer, with control breaks built in, which can let you generate really comprehensive reports with things like the sum of all sales for each state printed at the end of the list of all agents for that state, etc..., really easily. It would be easily ten times the amount of code to do that in java. Many, many companies have spent millions to have a monolith of a cobol program rewritten in Java, only to find that it doesn't do what they need or doesn't exactly match the cobol program, and can't be used.

>>4246 Yeah, COBOL also runs on Mainframes where the main feature is tons of I/O bandwidth. Java isn't necessarily tuned to exploit that advantage. WRT to respecting the legacy, I disagree. There is a difference between maintaining code and authoring it. Legacy Java codebases should stay Java. New codebases should use new languages. Many legacy applications should be retired. Some can be salvaged, many shouldn't.

>>4243 >What could possibly make starting from scratch less expensive than maintenance? You have to get into the mindset of a middle manager at a large company to understand this, but it makes perfect sense To mr manager, the worst thing in the whole world is having to tell upper management that something is broken Mr manager does not program Mr manager does not know what the codebase looks like Mr manager does not even use the applications the developers are working on Mr manager uses an email client and powerpoint Mr manager knows that the applications are only for use by other teams in other parts of the company Mr manager knows that most of the users are minimum wage employees at the company's stores Mr manager does not know these employees, and would not care about them even if he did Mr manager hears the developers complaining about how bad the codebase is Mr manager does not understand their complaints Mr manager knows there are bugs in the codebase Mr manager hears the store managers complaining Mr manager tells his bosses those bugs aren't his fault, they have been there since the last manager Mr manager sends out a memo "Don't use this feature, it will crash the inventory software" Mr manager considers the bug fixed, he wasn't responsible and he stepped up and kept people from running into the bug Mr manager hears the developers talking about fixing the bug Mr manager knows that when developers do things, sometimes they introduce new bugs Mr manager considers the bug not to be his problem, but a new bug would be his problem Mr manager tells the devs not to bother with that bug Mr manager repeats this for hundreds of bugs Mr manager does not care that there are hundreds of bugs, they aren't his fault and don't affect his team Mr manager knows that someday these bugs will have to be fixed Mr manager is an ambitious man, he doesn't plan on sticking around in that position for long Mr manager hears the developers talking about rewriting part of the inventory system Mr manager sees danger Mr manager reacts Fear.

>>1310 but why would you want to write val max = if (a > b) { print("Choose a") a } else { print("Choose b") b } instead of val max; if (a > b){ max = a; } else { max = b; } ?

>>4259 The 1st version doesn't make me repeat myself.

>>4259 Why would you want to write the second one? You'd probably write such a simple condition using the ternary operator, which is the same as an if expression. The first one is much superior for both writing and maintainability. If you want to change max's name it only takes one edit, while in the second you'll have to either go through every branch and change the name manually or use a refactoring tool. Also, what if you need to add a new branch at some point and forget to assign the variable? At some later point in the program you'll get a NPE, and good luck debugging that if you don't use it right away. Having if as an expression makes it return a certain value, so the type checker can easily tell you that you forgot to return the right value.

>>4259 Val means constant (as opposed to var for variable), so the second part doesn't compile. Also, it only looks shorter because of the print statements in the first snippet, otherwise you can just write it inline as: val max = if (a > b) a else b Which is much easier than the version with intermediate assignments.

>>4256 It's simple. Stop bolting on new features into balls of mud. Don't let programs become gargantuan monstrosities. Many times the new program is smaller and more maintainable than the old one.

A fun Kotlin example: inline fun <T> Boolean.ifTrue(body: () -> T) : T? = if (this) {body()} else {null} fun main(args: Array<String>) { (1 == 1).ifTrue { print("This gets printed") } (1 == 2).ifTrue { print("This does not get printed.") } } A pair of curly braces not included in a syntactic structure is a zero-argument lambda, kind of like a smalltalk block (if you have arguments, they go on the left of a ->). Furthermore, there is a nice bit of syntax sugar which lets you omit the function parentheses whenever the only argument that goes in there is a lambda. This lets you build your own control blocks to some extent. It's not as powerful as lisp macros, but it's a neat feature to play around with and it helps to activate the "programs as language" part of my brain. Example of doing something slightly more useful that I used in a quick program I wrote to automate something I needed done: import java.awt.Robot import java.awt.event.InputEvent inline fun <T> Robot.whilePressingShift(body: () -> T) : T { this.keyPress(java.awt.event.KeyEvent.VK_SHIFT) val ret = body() this.keyRelease(java.awt.event.KeyEvent.VK_SHIFT) return ret } fun Robot.rightClick() { this.mousePress(InputEvent.BUTTON3_DOWN_MASK) this.mouseRelease(InputEvent.BUTTON3_DOWN_MASK) } fun Robot.shiftRightClick() { this.whilePressingShift { // Personalized control structure for all your shifty needs this.rightClick() } } (Also worth mentioning is that the fun Class.functionName(...) function definitions just define a regular function acting on that type, but with method syntax.)

>>4310 But it isn't up to me. It isn't up to any of the devs. We take orders from management, and management sees changing or replacing old code as a risk. They do not care at all if the software is broken, as long as it doesn't become more broken under their watch.

>>4317 Stop working at banks, and shops selling bad software. There are more than enough good software jobs.

>>4318 >Stop working at banks, and shops selling bad software. There are more than enough good software jobs. Why would anyone give up a job with high job security where you have to do very little but sit in meetings (from my experience)? Some youngsters might shout: "But programming is my passion!" Sure it is, but only until you gain more experience in life to find out what really matters.

>>4319 This man knows what's up I can easily go a week without doing any real work I am untouchable because I'm one of the only people here who know a couple of the real old codebases My health plan covers dental, and I get a 50% match on 401k contributions, I get a good salary and bonuses Only downside is dealing with some of the worst code I've ever seen in my life In the grand scheme of things that ain't so bad though

>>4318 >drop a great salary, position, benefits because the code isn't perfect Are you kidding me?

>>4322 There's more to life than money, anon.

>>4324 And there's more to life than your job, too. A good salary allows you to pursue hobbies with peace of mind and to sink some money in them, or to retire earlier to travel around the world, or ...

>>4319 Hey man, it's up to you if you want to give up. I live in a part of the country where good software development jobs are in more than ample supply. There's no reason to continue the horror of enterprise Java in a new application, and for that reason I see no reason to lessen that horror with a bolt-on language. It's possible to make just as much money if not more than a bank at a startup, and even if your startup dies the gravy train to "leadership" is almost inevitable - even if you suck at your job.

>>4326 Eh, I find Kotlin to be a perfectly usable language on its own merit. At least as much as Swift, but with perfect IDE support on top of that. It's pretty hard to come up with a big mainstream language that is significantly better. Looking at the redmonk ranking of programming languages by popularity ( http://redmonk.com/sogrady/2017/06/08/language-rankings-6-17/ ), the only languages that I'd find inherently more "interesting" among the top 20 would be Scala and Haskell. Kotlin is compatible with Scala so not mutually exclusive with it, and it has much more libraries available to it than Haskell.

>>4327 Yeah, I'm not sure I buy your reasoning there. > Kotlin is compatible with Scala so not mutually exclusive with it Then your Java-based mess would have three languages to comprehend, and at least two paradigms programming paradigms. Nothing would be uniform, nothing would be pure, and the advantages of each language would likely be lost in overhead of keeping people educated about what things mean in each language. > and it has much more libraries available to it than Haskell. More isn't always better, not that I suggest you write your Java business logic apps in Haskel. Java has a trillion libraries, but a much smaller subset of them are actively maintained. If the recent struts vulnerabilities are any indicator, those libraries are just as much a liability as an advantage. How many libraries "maintained" by the Apache foundation are something close to abandon ware? How much digging around in Maven would I have to do before I found a serious XML parser, or deserialization exploit? Java flourished in the "bad old days" of both software design and security best practices. A lot of these "advantageous" dependencies are really just ticking time bombs waiting for you to have to get your hands dirty and do a pull request. At least with C++, you know you can trust nothing, and there isn't something like Maven encouraging every dev to include 1,000 dependencies in every project. So convenient! >the only languages that I'd find inherently more "interesting" Go is plenty interesting, and is making some actual inroads toward relevance. There would likely be more interesting languages there if list didn't include nonsense entries like: "CSS" - Barely a programming language. Seriously shouldn't be on the list. "Shell" - Are we sure the repos being opened with "shell" are really full projects written in shell? I think we are counting collections of peoples short scripts here. There is a very small number of people who write non-trivial applications in shell. "CoffeeScript" - More metaprogramming bullsoykaf. It's a Javascript superset, count it with Javascript. "TypeScript" - Same. It's a Javascript superset. "Matlab" - Technically a programming language, but also more like a toolbox. Can we count Wolfram Alpha too? Is anyone seriously writing apps for business in matlab? I can't imagine there is enough of that kind of coding going on to give it a ligitimate place on the top 10. The numbers are bolstered from students doing homework. And arguably "R" - Legitimately popular, but more a stats environment than a programming language. People do write this full time, but it's more a conduit for their ML/stats ability than a language with many of it's own strengths. Can we leave domain specific languages off the list? IMO your interests don't necessarily line up to me. What could you be programming that would equally well in Haskall as Kotlin? If you just like languages with cool syntaxes, then go check out OCaml, or maybe Rust or something. Certainly Kotlin can't be the most interesting among those choices.

>>4338 > Is anyone seriously writing apps for business in matlab Yes. Sadly. The number of large-LOC projects written in Matlab is staggering. There's a significant subset of older engineers who know only Matlab and Fortran.

>>4338 > More isn't always better, not that I suggest you write your Java business logic apps in Haskel. Java has a trillion libraries, but a much smaller subset of them are actively maintained. If the recent struts vulnerabilities are any indicator, those libraries are just as much a liability as an advantage. Having seen the Haskell ecosystem, I can say that the average Haskell library is much worse in that regard. Hackage is flooded with abandonware projects written by people who don't know what the time & space complexity of their algorithms are. > Go is plenty interesting, and is making some actual inroads toward relevance. Go is an abomination against mankind and should be purged with fire. Also, Kotlin passed it in a few month on the pypl index as soon as Google made it an officially supported standard, while Go achieved less despite getting pushed by Google for much longer. CSS/Shell/Matlab/R - yes, those are domain specific languages used in specific contexts. The first three are horribly designed. R slightly less so but it's age is showing. As for coffeescript/typescript, those are Javascript transpiling but they are enough of a change that people are interested in their development. Either way, if the list is too short for you, there are 100 languages in included in that scatterplot for you to look at. I'd still argue that among those, Kotlin is among the top 20% or even in the top 10% of those languages imho. For the intended purpose of building applications quickly by combining the power of functional programming with the power of dot syntax and tab-autocompletion in a good IDE, it's sitting pretty close to the local optimum in the design space

>>4340 >Either way, if the list is too short for you, there are 100 languages in included in that scatterplot for you to look at. I'd still argue that among those, Kotlin is among the top 20% or even in the top 10% of those languages imho. It's new, and it has hype. Let's see where it is in a couple of years. Scala has failed to really establish itself as a mainstream language. One reason languages like Scala struggle, is that since it has interop with Java there is no reason a whole team has to write the codebase in Scala. This makes it easier for the lazier coders to revert to Java when things get hard, and ultimately for the suits to downsize all the smart people and outsource the whole mess. You can just hear the consultant saying "we have a hundred engineers out in Bangalore who can do what your employees used to do. It shouldn't be a problem for them to bolt on more Java" If a consultant takes my job by knowing Lisp, he earned it. >Having seen the Haskell ecosystem, I can say that the average Haskell library is much worse in that regard. Hackage is flooded with abandonware projects written by people who don't know what the time & space complexity of their algorithms are. Hackage is full of college and personal projects. In my experience Hackage has had *more* obsession with *asymptotic* complexity than just about any other package repo I've seen. Actual performance is another story, but algorithmic efficiency is something that at least comes up there, where it's relevant. That's a funny criticism when leveled against Java's typical "what if everything was an XML parser" attitude. I wouldn't exactly characterize the average Java dependency as being "performance driven." What *hackage* and just about any other non-Java programming language based package management system does *not* have is a host of aging software that is a) Highly insecure. b) Used by huge businesses. I would totally buy the argument that "Hackage is like kicking dead whales down the beach and the projects there are spaghetti cooked up by CompSci post grads who think type theory buzzwords are the same as measures of quality." That would be closer to the truth. I would not buy the argument that many of the projects on hackage expose their users to security issues. I doubt it would be hard to find instances of vulnerable XML parsers in Java package management system repositories, however. The point here is that just because a language has a *lot* of libraries doesn't mean they are good, or even safe. The average Haskel library is much newer than the Average Java library, and Haskel libraries are usually built to serve some limited, often academic function, rather than a wide range of business needs. I really am interested in how using something like Kotlin with a massive sea of dependencies that don't take the languages features in mind is supposed to be anything but a depressing exercise in trying to avoid reading more Java. >Go is an abomination against mankind and should be purged with fire. I mean, I don't much care to write it, but it has a unique ecological niche that people seem to like. It's a language unto it's own. >Google made it an officially supported standard I'm sure their Java programmers are grumpy, overworked, and opinionated. Maybe people in more agile situations should choose a language that better enables people to make new stuff? >R slightly less so but it's age is showing. R only has to blow less than the competition. I'm not sure why Julia isn't overtaking it. >but they are enough of a change that people are interested in their development. I acknowledge interest from the development community, but I don't think those languages are as relevant as they appear on the list. I would say that most Javascript developers would be more interested at mastering front-end MVC frameworks than bolting on a type system to their code. >power of functional programming with the power of dot syntax and tab-autocompletion in a good IDE, it's sitting pretty Sounds like a pitch for Javascript. Not sold.

>>4348 Actually, you're right regarding performance. My IRL-ish Haskell experience is more recent than my Java experience, so running out of memory in Haskell or getting a stack overflow in a supposedly tail recursive function because one parameter doesn't have a strictness annotation is fresh in my mind, while Java's OutOfMemoryError isn't. > I really am interested in how using something like Kotlin with a massive sea of dependencies that don't take the languages features in mind is supposed to be anything but a depressing exercise in trying to avoid reading more Java. It's really not that bad. For example, if a Java method expects an object with a single method, you can pass a lambda to it instead and it will just work. Seas of getters and setters are replaced by Kotlin's properties. Many of Java's standard design patterns are captured by Kotlin's language features, so the overengineered behemoths end up being fairly lightweight to interact with from the Kotlin side. More importantly, the IDE support from Jetbrains is absolutely amazing. This is a big advantage of dot syntax languages in my book, since the IDE can give you a list of methods/functions with their Kotlin-side types as soon as you write the dot. If a Java library is well designed and has good API naming you can often just lazily autocomplete your way to a working program.

How do I interface Kotlin and Frege ?

>>4350 >Many of Java's standard design patterns are captured by Kotlin's language features What do Kotlin's language features look like from the perspective of Java API/ABI? When C++ preyed on C, it did it in a way that would beget more C++. While C++ can trivially interface with C, the reverse isn't true. While any programming language can interface with C via de facto standard ABIs, nothing but a C++ compiler can interface with C++ because nothing else can resolve C++'s meter-long symbols. Is Kotlin a new C++?

>>4367 Kotlin doesn't do any kind of name mangling or the like no, everything ends up as a Java class file. Methods generated by Kotlin features get names according to specific naming conditions. This does lead to some semi-weird rules that prevent you from using some specific method names. It is also technically possible to use Java code to break some Kotlin compiler-enforced invariants (for example, Java can inherit from a Kotlin sealed class, which breaks Kotlin's compiler guarentees that a given pattern match will cover all cases). As long as you have those details in mind, calling Kotlin from Java (or any other JVM language capable of calling Java) is effortless, it's just like calling Java. Some API's make a lot more sense to call from Java 8+ though, since Lambdas are an integral part of idiomatic Kotlin.

Sudden surge in job postings on indeed.com . Kotlin went from no jobs posted to beating Haskell within a month or two.

>>4562 >beating haskell that's not very hard

>>1310 >Compilation to native code is in the works. and now its here: https://kotlinlang.org/docs/reference/native-overview.html looks like Kotlin is going to stand along side Rust, Go, Swift and D more info https://blog.jetbrains.com/kotlin/2017/11/kotlinnative-v0-4-released-objective-c-interop-webassembly-and-more/

>>5036 Eh. Kotlin's key strength over Scala is better interop with Java and official android support. If I'm going to use an LLVM backend for a JVM language, I'd rather just use Scala native than Kotlin native.

>>5082 I mean, Kotlin is nice in the sense that it's a good general purpose language which is fairly easy to learn. You'd most likely be more productive overall with it than with Rust and Go (assuming you're not doing the kind of stuff Rust specializes in). The comparison with Swift or D is a fair one though. They are fairly close to Kotlin in expressiveness. Imho the Java runtime is good enough and sufficiently widespread that I don't see much point in abandoning it for most applications unless you literally can't deploy with it, especially considering that the native Kotlin backend is most likely not going to see nearly as much library support.

>>4295 But much longer than a > b ? a : b

>>5208 Same semantics, far more unreadable syntax (consider that it was even considered idiomatic Perl). Also, in most languages with C-like syntax you can't do the original example in OP: val max = if (a > b) { print("Choose a") a } else { print("Choose b") b } because code blocks in C and Java don't have a return value. They are compound statements, not expressions. Hence the C/Java ternary is a lot weaker precisely because most things are not exceptions. In Kotlin, all control flow statements are expressions.

>>5209 Code blocks in C do return a value with GNU extensions enabled. You can do int x = { code(here); 10; } This is provided mostly for the convenience of macros that need to do multiple things but still return a value.

>>5208 int larger = (a > b ? print(a), a : print(b), b); checkmate

>>6263 private fun runApp() { val app = NSApplication.sharedApplication() app.delegate = MyAppDelegate() app.setActivationPolicy(NSApplicationActivationPolicy.NSApplicationActivationPolicyRegular) app.activateIgnoringOtherApps(true) app.run() } Disgusting, should've been idiomatic at least. private fun runApp() { val app = NSApplication.sharedApplication().apply { delegate = MyAppDelegate() setActivationPolicy(NSApplicationActivationPolicy.NSApplicationActivationPolicyRegular) activateIgnoringOtherApps(true) run() } } >>6263

>>7069 >https://blog.jetbrains.com/kotlin/2017/11/kotlinnative-v0-4-released-objective-c-interop-webassembly-and-more/ Forgot to reference, I'm retarded

>>7069 This is really cool. Kotlin's blocks can use object scope for syntactically lightweight cascading?

>>7074 They just stole instance_eval from ruby

>>7081 I thought exactly the same thing.

The two features of Kotlin that I like the most are probably companion objects and first class delegation. https://kotlinlang.org/docs/reference/object-declarations.html https://kotlinlang.org/docs/reference/delegation.html Kotlin itself is too tied to Java to fully make use of those features, but these two features would be killer in a language with structurally subtyped interfaces like Go's, and if the companion object was simply associated with the class. You'd get pretty damn close to Smalltalk in a statically typed language at that rate. If you added an option to forward every interface to a given member, and added a couple of compile-time hooks, you'dd essentially have a type safe version of doesNotUnderstand proxying, especially when it's combined with reflection.

>>7146 You can do that object declarations thing in java too, just instead of writing window.addMouseListener(object : MouseAdapter() { // your override methods here }) you write window.addMouseListener(new MouseAdapter() { // your override methods here }); C# has the best support for anonymous types. I don't think what Kotlin and Java have are anything special

>>1311 What does that even mean? How does kotlin prevent people from being good or bad at it