Little Discourse tip – you can reply to a message by creating a new thread. Click the link icon and choose “New Topic.” That is what I expected would happen when I asked the question. Arguably I should have done that when I asked the question. ¯\ _(ツ)_/¯
Alternatively, I believe a mod can do this retroactively…
Actually I did not say “more warts”. My exact phrase was “Kotlin just trades some Java warts for new ones.”
Which is not 2 syntaxes for lambdas. They are two expressions that are of function type, but one is a refrence to an existing function and the other is a lambda.
The only multiple syntaxes I know of for lambdas is with explicit parameters vs. implicit parameters, but I see no way that can be construed as a bad thing.
That’s what I get for being too lazy to scroll up a page and a half…
I have some sympathy for @DonWillis but unfortunately he completely undermines himself with his comment about functional programming.
I take that as a request to expand on that.
Well, the whole idea that functional programming is something people in ivory towers and doesn’t have much use in the so-called real world shows an incredible amount of ignorance from someone who tells us how much he knows about programming languages. I gather this knowledge is limited to imperative languages.
Multi-threaded applications is just one of the things that make functional programming a good idea but it’s huge. I’m an embedded SW engineer by day (and won’t tell you what I do by night, na na na na na) and applications have been going more and more this way during my 20 years of writing professional software (I actually started by writing business software for about five years so I know that domain as well). There are some fundamental complexities writing multi-threaded programs that are extremely hard to solve and tend to create bugs that are among the hardest types of bugs a programmer can encounter (race conditions, deadlocks, etc). And many of those bugs are caused by our attempt to fix other bugs (global data being changed at the wrong time). If you look at this from the outside it’s completely backwards. Functional programming allows us to write code that gets rid of the first problem so no need to create the extra code to fix that!
And multi-threading is only getting bigger. There are just too many applications where it fits, and even more if you embrace it rather than try to avoid because it’s too hard. Including business apps.
Another big plus is functional code tends to be much shorter. This is a big bonus especially during application maintenance phase (which is pretty much always way longer than original implementation phase).
The way functional code is written also tends in my experience cause less bugs. How many for() loops have you seen with an off-by-one-error? Or code that uses a temp variable that someone goes and changes a bit at some point during application lifecycle without realising it’s used later in the code?
Furthermore, functional code is being used enough to make the notion it’s not usable sound ridiculous. Imperative languages got popular because they are easier to optimize to hardware as their logic is close to how processors work. This was important back in the 60s and 70s but this gets less and less important as our computers get more powerful. So we can actually start to use the best tools to solve our problems without such constraints as processing power. And funnily enough, functional programming has been gaining a lot more traction as a consequence. It’s still small compared to imperative programming but then again, how quickly do we adopt completely new programming languages overall? And functional programming requires a different way of thinking about programming so it’s doubly hard. But it’s creeping ahead. Clojure has a nice community and there are many companies writing applications with it. Erlang has been used by Ericsson since the 80s successfully and it’s hands down better at what it does than anything else (building fault-tolerant systems). Other companies have adopted it as well. Financial companies for some reason also like functional languages (so there’s your ultimate business applications), especially in-house developers. It won’t take over overnight but if you still have two or three decades of professional life and this is your day job you will be a bit of dinosaur at some point if you don’t know functional programming. Just like those guys who only know COBOL.
I also have to disagree with the notion that “customer is always right”. When Java was being introduced lack of multiple inheritance was seen as a huge thing. I confess of being one so I disliked the language from the off and haven’t used it much even though I actually completely agree with the language developers now. The problem with that kind of logic is that we wouldn’t really ever get anything new in any walk of life if everyone was just doing what they thought the customer wants. Did Apple become such a big company by following that idea?
Kotlin may or may not become successful. Only time will tell. But there are many other factors that decide it beyond that.
Well this this escalates quickly, but going on topic I’ve been reading about the future of Swift and found (here GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.) that it will have a rust like memory management and in a near future also support concurrency, I’m wonder if Kotlin (maybe native) intends in at some point have another kind of memory management, b/c the JVM version its tied to java GC, right?
I’m still interested in Kotlin of course, yes theres some odd things in Kotlin bug Swift also has their own things, I like both languages but trying to learn more about both in deep.
What memory management does Kotlin/native use?
I’m not a particular fan of Rust. Haven’t used it, but read about it and the system felt cumbersome with all that boxing.
I’m not so familiar but a quick google search shows me:
and
But Kotlin native its in early stages and seems that they didn’t decide it yet, also as the fist link points that will have different memory management in each platform.
Well the thing about the same memory management like Rust have its, quoted from the previous link that I’ve posted…
An (opt-in) Cyclone/Rust-inspired memory ownership model is strongly desirable for systems programming and for other high-performance applications that require predictable and deterministic performance.
This kind of thing its what a game engine would benefit, also there are plans to improve the concurrency (as far I know not yet in Swift 5), cannot speak about Kotlin b/c I’ve only have experience (started with Kotlin in May) with Android and some other test I’ve done with it, also we don’t know when Kotlin native 1.0 will be released and it could suffer big changes from the current version (0.3).
So I appreciate all the comments that you have done, so I could know more about pros and cons about Kotlin.
Currently, Kotlin Native uses automatic referencing counting (ARC) to clean up Kotlin objects when they are no longer referenced. As ARC cannot deal with cyclical references, a garbage collector runs periodically to clean up those.
Generally speaking native memory has to be allocated and released manually though there are various devices available to automate this (or the release aspect) in most circumstances.
Although the system has been designed to enable other memory management schemes to be used, depending on the platform being targetted, I’d be surprised to see something like the Rust approach catered for as, IMO, it is not very programmer friendly and is really designed with system rather than application programming in mind.
If I’m not mistaken Rust uses a memory management similar to C? and also Rust objective its to be a C replacement or something like that. So if the Swift engineers think to add something like that its b/c theres something that needs more performance and ARC may add too much overhead to some apps/systems, but I’m not an expert, my expertise its on the mobile app development side.
Also game engines uses C or C++ in the average, off course there are other languages used, but those are most preferred b/c their performance, so Rust can be an alternative in this case (but I’m not interested in learning Rust, but Kotlin / Swift yes) so my target is not to build the most performant game engine but those features in the language gives me the potential to optimize it later.
To clarify, I just want to build a one case game engine that fits my needs, not the next unreal/unity, I saw a bunch of threads that people blame b/c its too hard to build one (b/c they think that ppl want to build something like those super popular mature engines). Also this also will help me to improve my programming skills at lower level than I’m used.
It sounds quite tricky to allow both manual memory management and GC at the same time. Not sure if it’s really necessary. GC obviously comes with a small overhead but I’m not sure if competing with C++ is the way to go.
Rust’s borrowing mechanism is completely different from direct memory management used in C. Rust allows direct memory management in unsafe mode, but I think the idea is not to use it, unless it is emergency.
Just to enlarge a bit on what @darksnake was saying about memory management in Rust.
Whereas C uses manual memory management - pure and simple - the Rust compiler itself determines when a resource is no longer referenced and automatically inserts calls to deallocate memory into the compiled code.
To achieve this it has a system of resource ownership whereby a resource can only be owned by a single variable at any one time. If one variable is assigned to another or passed by value to a function, then the ownership of the resource is changed and it can no longer be referenced via the original owner.
Sometimes you don’t really want to change ownership to access a resource and Rust has a concept known as ‘borrowing’ to accomplish this. Essentially, a resource cannot be destroyed whilst it is being borrowed because there is then more than one reference to it.
When combined with other concepts such as lifetimes, scoping rules and mutability there is quite a lot for Rust programmers to get their heads around and when I tried the language I found it difficult to concentrate on what I was trying to program with all this other stuff to worry about!
Currently, you only really need to worry about manual memory management in Kotlin Native when calling functions in C libraries. For example you need to allocate an array on the native heap and pass a pointer to it to a C function which populates it with some data.
Kotlin Native is trying to make it as easy as it’s ever likely to be to interoperate with C (and now Objective-C) so I wouldn’t let this put you off.
