This sounds like a very US-trigger-warning-safe-spacey stance. I think most people on this planet are able to consider each point at its face value.
> I think most people on this planet are able to consider each point at its face value. Humans have a pretty strong demonstrated tendency to develop positive or negative emotional attachments to pretty much everything, including sources of information/arguments, and see the world strongly filtered through those. This is, while it can be misleading, an important evolved survival mechanism in terms of attention/resourc…
People who can't assess statements objectively are probably exactly those people whose opinion I couldn't care less about.
Perhaps this is exactly the filter I want to have.
Will Lightbend be supporting this project in any way? The reason I ask is that I see on GitHub that you are the only contributor so far. This project is quite a large commitment for a single person, I'm hesitant to play around with Scala Native without knowing more about future plans for support, milestones, etc. Having said that, this project looks awesome. Nice work so far!
Agreed. I see the statement "It's being developed at EPFL by one engineer" as a very high risk that once this student graduates or moves on to a different university, the project will be abandoned and die.
> Most Scala libraries never used reflection, so most of the ecosystem "just worked" on Scala.js. Do you have personal experience with this? I do not have hard numbers, but for me - basically none of my stack worked. I had to find a new JSON parser. I had to find new validation for my form stuff. Etc. etc. It wasn't impossible, but it was a lot of work.
You're talking about Play Framework, I assume. They did some fancy work with Macros (i.e. Scala Reflection) which causes a lot of headaches for Scala.js. The reality is most of the reflection it does is nice but not necessary and I really wish they offered a "switch" to turn it off.
Ya play is where I started, then I moved my app into Scala.JS land.
Had some cool parts to it, but not sure I was sold on the overall experience. I hate JS so bad and want to avoid it, but I kind of felt like I was mostly trading evils. Maybe if I worked at it enough it would finally get better? Not sure
> Go: Go is utter shit that only survives due to the devs name-dropping "Google" every 5 minutes Woah!
Go is great if you dont mind writing 1000's of lines of boiler plate code one would expect to exist.
Agreed, but that said I'm a recent convert from Scala to Go. Not sure I'd go backwards (no pun intended), boilerplate aside.
Having standardization on things like channels in the language makes for a much nicer consistency in the language. Scala has 8000 ways to do anything, half of which involve an exotic DSL. I'll take plain and simple please over esoteric and unmaintainable.
Not the author: > - Can this reuse existing Scala code? I think that's the plan. Would be a pretty pointless exercise without that, right? :-) > - How does it compare against Rust/GO/Swift? Why use this over them? Rust: Scala and Rust have different niches. Rust is more focused on low runtime overhead, while Scala is more focused on low development overhead. This means Rust can be potentially faster to run, but Scala…
Not the author: > - Can this reuse existing Scala code? I think that's the plan. Would be a pretty pointless exercise without that, right? :-) > - How does it compare against Rust/GO/Swift? Why use this over them? Rust: Scala and Rust have different niches. Rust is more focused on low runtime overhead, while Scala is more focused on low development overhead. This means Rust can be potentially faster to run, but Scala…
> Swift where things get added at a frightening rate.
Things are always added at a frightening rate when a language is young. Happened for C#, happened for Scala, happens for all languages.
> If you want things to be nullable, you will have to opt-in explicitly with T|Null I can see how the opt-in null references might help prevent you from writing Scala code that uses null, but how does it help when interacting with Java code?
Thanks for the downvote. Let's close this discussion.
I didn't downvote you. In fact, I consider your post interesting, because (for example) I didn't know about the opt-in nullable references. Here's a +1 to counter the downvote.
That's debatable. Some tooling is needed, some (like IDEs) are mostly unnecessary; crutches we're used to because some languages are unbearable to use otherwise. IMO it's a niche language because, unlike Scala, it requires a clean break from the way the mainstream industry sees programming languages. But don't mistake that for lack of practicality!
I don't subscribe to the point that IDEs are crutches any more. I don't rely on IDEs to generate code for me, I use them to explore code and refactor it efficiently. Good refactoring support in IDE can save you a lot of time and errors, especially in the statically typed languages. It has nothing to do with language being unbearable, but a lot to do with the size and complexity of the code you have to work with. I ha…
Can you elaborate on this OOP for big code bases argument as I've seen it wheeled out in defence of Java and PHP5 many times but I just don't buy it. Often classes in OOP languages are used not for instantiating objects, which I would argue is their raison d'etre, but simply to encapsulate some data and a bunch of methods. What advantage does this have over simply using your language's namespacing properly? In Clojure and Python, for example, it's easy to place a bunch of functions in a single file, add a namespace and you can manage a codebase of any size. When PHP introduced namespaces in 5.3 I couldn't understand why its Java-esque OOP was still so idiomatic as they solved the main problem it was invented for.
> Most Scala libraries never used reflection, so most of the ecosystem "just worked" on Scala.js. Do you have personal experience with this? I do not have hard numbers, but for me - basically none of my stack worked. I had to find a new JSON parser. I had to find new validation for my form stuff. Etc. etc. It wasn't impossible, but it was a lot of work.
You're talking about Play Framework, I assume. They did some fancy work with Macros (i.e. Scala Reflection) which causes a lot of headaches for Scala.js. The reality is most of the reflection it does is nice but not necessary and I really wish they offered a "switch" to turn it off.
Sorry I've never used Scala macros, beginner's question: are Scala macros not completely compile time? Why would they use reflection? Is it just syntactic sugar for dynamic type inference?
If they just use reflection during compilation: why would that not be compatible with whatever the runtime is? Shouldn't that be unaffected by runtime and purely depend on the compiler's support for reflect?