In what sense is it closer to Scala? It's more like a slightly nicer Java: All Kotlin code can be translated back to Java (with some boilerplate), but almost no Scala code could be expressed gracefully in Kotlin (or Java).
Not everything in Scala can be cleanly translated into Java, but Kotlin looks more like a subset of Scala than it does a superset of Java. The syntax is very close.
Rust and Scala operate in entirely separate contexts, are intended for entirely separate domains, have entirely separate goals, and are intended for entirely different sets of programmers. Lessons that apply to Scala do not necessarily apply to Rust.
The cascade of efforts at error handling, which I think at one point involved a macro and a magic method name, rather than getting on with higher-kinded types to allow them to do it right.
Allowing "return".
Mandating braces for functions and control flow constructs.
Rust iteration, which is both more limited and less safe (laziness) than the scala/ruby style of passing a closure.
You must be referring to ancient Rust with its condition system and such. Modern Rust code just uses Result types.
> rather than getting on with higher-kinded types to allow
> them to do it right
Er, no, you don't need HKTs to "do it right", you'd just need HKTs to do it generically. Rust's error handling works fine for specific types; you can even write macros to emulate do-notation (and people have).
> Allowing "return"
Welcome to the realities of imperative programming. :) Unlike Scala, Rust does not aspire to functional godhood.
> Mandating braces for functions and control flow constructs
Scope in Rust is very, very important for expressing when references go out of scope and when resources are freed. Leaving scope implicit would be massively frustrating.
> the scala/ruby style of passing a closure
Rust had internal iterators for years, and the entire `for` construct was based around them. They were removed because they were found wanting.
As I've mentioned in a sibling comment, the lessons that Scala may have learned in its life do not necessarily apply to Rust. They are very, very different languages.
I am a Scala developer but I agree with your points. The only thing that just simply drives me mad in Rust is mandatory semicolons. Once you are used to be able to omit them then it gets really annoying to go back using them.
I actually agree with this one. :) The usual argument in their favor is that having to explicitly return `()` all the time would get tired in low-level C-alike functions that mostly operate via side effects, but I'm not particularly swayed that we should be optimizing for that use case (but then again I'm also of the opinion that bitwise operators don't deserve their own symbols, so I may already be an enemy of this crowd :P ).
Thank you! It's really hard to understand where criticism is from without specifics, even if you're not the OP.
I would love higher kinded types, but most of our users are asking for other type system features first. What we've done doesn't preclude a HKT style in the future, as the signatures are the same.
I'm not aware of an imperative language that doesn't allow early returns, maybe there are some, but I find 'guard clauses' to significantly combat rightward drift.
Braces are to appeal to our core audience, who have been using braces and semicolons for decades. Absolutely, 100% subjective though, I know people who prefer the whitespace-based syntax, but you really only get one or the other.
> Rust iteration, which is both more limited and less safe (laziness) than the scala/ruby style of passing a closure.
I'm not sure specifically what you mean here, around both safety and closures.
Here's Rust:
let v = vec![1, 2, 3];
let v1 = v.iter().map(|x| x + 1).collect()
Here's Ruby:
v = [1, 2, 3]
v1= v.map {|x| x + 1 }
Other than the laziness, both are "pass a closure." And I'm not sure how safety ties in here at all.
Most of these things seem like subjective preferences, rather than things that are "completely broken."
> I would love higher kinded types, but most of our users are asking for other type system features first. What we've done doesn't preclude a HKT style in the future, as the signatures are the same.
I think many users don't know that they want higher-kinded types, only that they want particular features.
> I'm not aware of an imperative language that doesn't allow early returns, maybe there are some, but I find 'guard clauses' to significantly combat rightward drift.
I don't know what you consider an "imperative language"; I'd consider Scala an example. I think a decent error mechanism (which Rust does have, even if the implementation is ad-hoc and reliant on a macro) provides a better way to express guard clauses. I think return is untenable in a language with lambdas, because any possible choice of semantics for return inside a lambda (including "compile error") will confuse a decent proportion of programmers.
> Braces are to appeal to our core audience, who have been using braces and semicolons for decades.
If by your core audience you mean C++ users then they're used to being able to omit braces on if/while/etc.
> Other than the laziness, both are "pass a closure."
I'm objecting to the .iter() part. Or perhaps more generally to the lack of something as extensible as do or for/yield. The for/yield construct turned out to be far more valuable to Scala than was realised initially.
> And I'm not sure how safety ties in here at all.
I meant unsafe in the colloquial sense. I think laziness makes programs very hard to reason about.
> Most of these things seem like subjective preferences, rather than things that are "completely broken."
I agree that they're not completely broken, but I think they're more than subjective; in many cases Scala has tried the various options over the years. We've tried exceptions and macros and found a better way of doing error handling. We've had return in the language and discovered it to be more trouble than it's worth. We've had a notoriously flexible syntax around function calls and seen a consensus on the best style develop over the years. We've seen some control-flow structures virtually wither away and others become indispensable.
> Or perhaps more generally to the lack of something as extensible as do or for/yield. The for/yield construct turned out to be far more valuable to Scala than was realised initially.
Yield doesn't make a whole lot of sense in a systems language with machine-level control over stacks and allocation. It doesn't make a whole lot of sense in a systems language where the idea of jumping out of a stack frame either means doing strange low-level stack jumping tricks (defeating standard CPU/compiler optimizations) or allocating behind your back (which is something that Rust never does). Very early Rust actually tried using yield for iteration and it didn't work.
> We've tried exceptions and macros and found a better way of doing error handling. We've had return in the language and discovered it to be more trouble than it's worth.
We've experimented with these too. And I use return all the time in Rust. It's really useful and I would hate to see it go away.
I think Rust and Scala are just different languages. One's an applications language built on the JVM and the other is a low-level systems language with manual memory management. That difference means that different decisions may be appropriate.
You seem to have missed my comment earlier about Rust blatantly lifting features from OCaml. Here, in the Rust reference, are about twenty other languages that Rust was inspired by: https://doc.rust-lang.org/stable/reference.html#appendix:-in... Being presented with the idea that Rust wasn't specifically inspired by Scala should not be taken personally. :P
Okay. I can assure you that I don't want to remain in the dark about things that are "completely broken", but I can't do anything to address them without specifics.
Well, that entirely depends. You made a really strong claim, and those are worth taking seriously. But that doesn't mean that a response might come out that way. For example, if someone claimed that using four spaces instead of two spaces for indentation is "completely broken", then "that's just your opinion" is a pretty acceptable response, in my opinion.
But, I can assure you that Rust is most certainly not perfect, and that we roughly try to prioritize work alongside what people ask for. Part of what I do is gather this kind of feedback, so that I can tell the rest of the team "Hey, lots of people have started asking about x. Maybe we should try to bump x up in the schedule." And we do do that, though obviously, everyone has a pet feature, and you can't satisfy everyone. (My pet feature that's far off: HKT) But I can't take action against "hey someone on HN says Scala has some secret sauce and we suck, but won't divulge the details."
It's not your job to help us improve Rust, but making really vague negative claims doesn't help anyone, really.
Hey did you know: the people you're talking to are real people, who work really hard on a thing that they really care about, and you are being a real jerk.
Hardly. The Kotlin designers specifically call out Scala's mistakes when discussing why they do things differently.
In my experience it works well. I've yet to encounter anything surprising or leaky. Actually the abstractions it provides are fairly thin: you can normally look at Kotlin code and understand quickly what it compiles down to.
It may be that in the end, Kotlin succeeds where Scala struggled, simply because the Kotlin designers do a better job.
Well, I don't think what you say is based on reality if you look at all the broken, half-designed stuff they are trying to ship. (Not understanding (yet) why some design decisions are bad, doesn't mean they aren't bad.)
It feels like they are digging through Scala's graveyard of discarded ideas without even realizing it. Most of what they try to do differently has already been considered in the past and has been rejected by the Scala developers for good reasons – years ago.
Kotlin's struggles are a good example that knowing how to build IDE support for existing languages doesn't give you the skills to design a programming language from scratch.
The Kotlin designers specifically call out Scala's
mistakes when discussing why they do things differently.
Yes, I have to give them that. They (and their "fans") excel at PR, marketing and FUD.
Different languages have different design tradeoffs. I had many profitable exchanges with Andrey Breslav and other Kotlin designers. We can have a technical discussion about the design choices without getting into a fight about who is more competent.
I think you are falling into the mistake of associating what you call design with features. How features are implemented and how consistent they are with some pure notion of their role is secondary to how they serve the high-level design goals. Once you understand Kotlin's design goals you see that the features and their implementation make a lot of sense. If you think the features aim to serve another goal, then the features might seem inconsistent. Outside of academic languages, language features exist to serve particular purpose, and so their "academic" form may be compromised to serve that purpose better. There is no point in isolating features from their purpose and then arguing over them without first understanding their goal in that particular language, as the same feature can serve different (or subtly different) purposes in different languages, or a feature must be twisted in order to allow the goal to be better achieved. There is no way to say whether a feature is good or "broken" without first analyzing the language's goals, and a feature that may be bad in one language may be great in another.
As Scala (or Ceylon) has such radically different goals from Kotlin, it doesn't make much sense to discuss which features were imported and how without first understanding the why. Kotlin's designers didn't say, "I like this Scala feature but not that one"; they said, "we have this goal and this Scala feature serves it but that one doesn't". A language is not measured by what features it has, but by how those features serve its goals, and whether those goals are appropriate to begin with (i.e. provide a good cost/benefit ratio).
Have I done something to offend you? Because you are being extremely rude. You are entitled to think whatever you want about my ramblings, confused or otherwise, and you are even entitled to not try to understand them or even read them at all. But your outbursts are inappropriate. Continue expressing yourself in this way and you will be banned from HN.
What's broken about extension methods? I have zero experience Scala and about a week's worth of experience with Kotlin, but so far I'm finding extension methods to be pretty straightforward and useful. What am I missing?
Extremely poor cost/benefit ratio for what purpose? If your main goal is to adopt existing classes and libraries as your own (i.e. without any loss of functionality compared to language-native libraries), then extension methods obviously have an extremely high cost/benefit ratio. You can't analyze a feature in isolation of the language's goals. Features exist to serve a purpose, and are measured by how well they serve it.
To give an analogy, a shoulder-fired missile might have a terrible cost/benefit ratio if you're trying to hunt an antelope, but if you're trying to disable a tank, then I'd say it's cost/benefit ratio is pretty good.
Why is reinventing the wheel considered a good thing?
javax.time is considered by some to be one of the best, most well-designed general and versatile libraries for date and time related matters out there, regardless in any language.
How would things be improved by throwing that away, and inventing something different?
I think keeping the API and providing an implementation for Scala.js is a much more reasonable approach.
Designing a date/time requires very rare skills and knowledge that most people lack.
A re-implementation of javax.time means all the documentation, tests and existing code can be re-used and allow correctness checks against the existing implementation.
> Why is reinventing the wheel considered a good thing?
It's not. There just is no shim for java.time currently! Even worse, there could be licensing issues[1].
EDIT: That, and some of us are unfortunately still on JDK7 until the next Ubuntu LTS. Not that that's scala.js's fault, but it's a practical issue.
EDIT: ... and of course having a duplicate implementation of java.time (JDK + the shim-which-is-basically-a-reimplementation-in-JS) could be considered "reinventing the wheel"! :) If you have to reinvent the wheel, then doing it such that it at least behaves completely consistently across all backend platforms is preferable, IMO.
As mentioned in the ticket, the original implementation is BSD.
Your last point is not the only thing that matters though.
If the runtime already ships with packages X, there is no point in shipping your own implementation.
(Which is exactly what Scala/Scala.js does with math stuff: it reuses BigInteger from the runtime on the JVM, but ships its own implementation with Scala.js.)
Right, but the JS and JVM runtimes have quite different behavior. And I'm willing to bet that implementing something as non-trivial as java.time again in Scala(.js) will end up causing quite a few bugs because they aren't identical.
That's why I'd rather have a single implementation for anything non-trivial and just retarget that to each backend using more low-level primitives. After all you're using a different language -- using a different date/time API shouldn't be much of a problem.
Yeah, inventing an API and implementation of a date/time/calendar library from scratch without an existing spec, implementation, tests or experience will surely be totally bug-free.
I'm not saying it'll be bug-free. My point is that it'll have exactly the same bugs on either platform. This may be preferable to having different bugs on different platforms.
That's a good point. As a (shim) library developer I think I might agree -- because it would perhaps be easier to find bugs in my library -- as an application developer I wouldn't because I would have to find different workarounds for different bugs.
The "I'm the smartest person in the world, because I work at Google" attitude is a reason I don't interact with/communicate with/contribute to Google-related projects. Their hugely inflated egos are just off-putting.
Googler for close to a year, so take this with a grain of salt.. I had heard of this exact reputation before I joined and frankly it was one of the things that worried me most.
After I joined, I kept waiting for the hammer to fall, to see the competitive mean streak in people and in my team at least, it was exactly the opposite. It's frankly the best environment I've worked in because they are genuinely caring people.
Now, it's not all rainbows and unicorns. I've also run into the aspergers poster child, into the competitive assholes, but I don't have to deal with any of these in my daily life. So, yes, there are assholes, but I don't think this is the norm.
While I worked at Google I noticed a huge disparity between how people responded to other Googlers and how they responded to non-googlers. A more interesting observation would be to find people you know and look for their outside interactions. If you find the same disparity as I did you might want to bring it up with them, sometimes that helps sometimes not.
There are never dumb questions, only practical and valuable examples of areas for improvement in documentation and/or related collateral (tutorials, cheat sheets, FAQs, etc.).
I actually interact with teams that bring a lot more revenue and is more highly visible to the public. And, again, I may be lucky here, but all the way up to my SVP are nice. I may have been lucky, but I think it's more an issue with people generalizing some issues. I'm not going to generalize my experience either, but I had to offer a different perspective.
Honestly, think about how many companies let their nerdiest of engineers be the public face of projects. The reputation is easy to come by when your front is not a "people person".
Sometime, Google employees also show this kind of attitude in their social life which makes other people hard to just have social interaction with Google employees.
Yes, one of the most annoying things you can encounter is a conversation at dinner with multiple Google employees. They will constantly mention that Google is working on something and then after confirmation with each other that it is still private, refuse to tell anymore details. It seems like it's encouraged in Google culture to brag but in a secretive manner to remind outsiders of what they are missing.
Plus, Google's huge and has very few internal communication barriers --- nearly everything is open to everyone. So it's really easy to get into the habit of casually talking about internal products when talking shop.
Then you notice someone nearby who isn't a Googler, and you go oh shit and stop talking.
And that is almost definitionally a lack of social grace and tact. It's one flavor of what is meant by "low EQ".
It may be usual and common for Google employees to do that. That doesn't make it excusable, and it's a pretty big reason why I, too, tend to avoid gatherings where I know it's going to be a bunch of Google employees. They communicate that they don't want outsiders around? I can oblige.
So that's a lack of EQ... So much so that it's a lack of common decency. Yes, it's a big deal, yes it's exciting but when in mixed company you need to talk about other things if it's indeed secret stuff.
Ironically, lunches are not like this. :D Since you never know which people in the cafeteria are or are not Google employees, conversation in the cafes is almost never about sensitive work stuff. The infosec focus actually stimulates an environment with a better work/life balance. Totally strange to experience, but 100% true.
I can second this, having worked with and talked with many of the team - they are great people, and enforce respect for each other within the community as the minimum bar for being involved in the ecosystem.
I have not had an issue with any interactions with any Google-backed projects.
Googlers are actually quite friendly for the most part. The internal vibe at Google is like the Globex Corporation from The Simpsons. They are elite but once you make it on the inside, far from elitist. Just never mind their secret take-over-the-world plans and you'll be fine. :)
Oh, and if you are a cat person, become a dog person before joining the company.
> "But, but ... we play both kinds of music, Country and Western!"
Yeah, but somehow it's only one group of people who seems to call the shots: Those with a disdain for the poor, the weak, the ill, the black and women.
