101–110 of 383 posts
Earlier quoted context omitted.
Scala is not for development, it's a research project.
I don’t know is this is a good troll because I’m replying or a bad troll because it’s so obvious. There are Many people who work at many companies doing real development with Scala that goes all the way to production, handling real user traffic.
But I wonder how many companies would make the same decision again after their experience with Scala.
Earlier quoted context omitted.
Anything GUI related, and their respective tooling support on Visual Studio, which it never got. It is still playing catch up with VS 2017 tooling for VB.NET and C#.
About GUI on .NET Framework: - Windows form works but not perfect. The editor works if you install the template for it, but not the auto generation of code, like double click on button -> handler generated. You write code programmatically. but is used a lot. I use it in the repl (fsi), to generate chart, custom data visualization. - WPF the same, works, no editor (but codegen is less needed) - Xamarin support F# ( ht…
Never understood the mentality for designing UIs by coding instead of visually.
I care for what comes in the box, and is directly supported by Visual Studio and Blend.
If someone needs to lose their .NET GUI tooling productivity to embrace F#, then better wait while C# keeps getting F# most relevant features.
Even C++ has better UI tooling support on Visual Studio than F#.
[deleted too many fanboys on HN]
> Also many open source libraries in Scala land have a very short life time and will not be upgraded to Scala3. No problem with Java, but it will take months for many larger projects to remove Scala2 library dependencies from their code base. The announcement says Scala 3 will be able to call Scala 2 libraries, so even if you're right (which is not my experience of open-source Scala libraries at all FWIW) this won't…
Earlier quoted context omitted.
Don't think it has a bright future since Rust and Kotlin share much of what brings people to Scala and are better in many ways, including and perhaps most importantly the fact they are improving faster than Scala.
Neither of those has or intends to have HKT, and they'll never be an acceptable replacement for Scala without it. They're "improving faster" but only in that they're starting from further behind.
Earlier quoted context omitted.
Can you be specific? This is a popular meme but it doesn't match my experience of Scala's language features at all (indeed I'd say Scala is very good at pushing things out into libraries or composition of existing features rather than making them language features), and often I find people with this kind of complaint were actually using a library with poorly named functions and mistaking its features for language fea…
I would start with operators and operator overrides, most of the time they don't make sense and it's difficult to know what it does, that's why most other languages banned them. Secondly, the implicit concept makes the code difficult to read. Then I would add that the differentiation between function & variable isn't always clear and sometimes you don't know what you call.
Yeah, that's what I was talking about - in Scala operators are just functions, and badly named operators are an issue with some libraries rather than an issue with the language. They're unfortunate, but all one can really do is avoid them - no language is impossible to write bad libraries in. Certainly I wouldn't ever want to go back to a language that uses magically-named methods for operator overloading, like Python and Kotlin do - I find that far more confusing, I can never remember whether a * b is calling a.__times__(b) or a.__star__(b) or something else. I could get behind a language that disallowed symbolic names entirely, but I don't think I've seen one of those since Java.
> Secondly, the implicit concept makes the code difficult to read.
IDE support has gotten a lot better now (green underline to highlight any implicit conversion, expand out implicit parameters) which makes them much easier to work with. If you only use implicits in cases where you otherwise wouldn't do anything in code at all, they enhance readability - but of course if you use them to replace things that you'd otherwise make explicit then they can reduce readability. I don't have a good answer, because I definitely want extension methods, typeclasses with derivation, and the magnet pattern, but I haven't yet seen a language design that makes those things possible while disallowing the bad uses of implicits.
Just curious, what companies (or kinds of companies) are betting on Scala nowadays? It seems that the people wanting "better Java" all decided they like Kotlin, and the functional programming people now gravitate more towards either F# (for .NET ecosystem) or OCaml/Reason (for the more unixy world). And the academic/research/learning crowd seems to like Haskell more. Who's still in Scala boat? Are Google or Fb or oth…
In the last ~18 months, the amount of CVs we're getting has been constantly increasing. Part of that is probably that our startups hiring matures, but it's also the kind of CV that is changing.
I'd say that 3 years ago, there was an 80% chance that the applicant was highly self-motivated to learn Scala in their freetime, and tried/did introduce it at his/her current workplace. Today, there is an 80% chance that the applicant either "had to" learn it in their current workplace, or learned Scala when switching jobs. (Don't get me wrong, they're still motivated, and they took the chance when it was there!)
So there is a switch from the Early Adopters to the Early Majority (where the Early Majority now has worked 1 or 2 years with Scala at their current job, and is confident enough to look for a new one).
One driving force was definitely Spark, but there are a lot of Enterprise apps, unrelated to ML (usually with higher traffic requirements). The sort that would have most likely been done with Java or C# 5 years ago. It seems a lot of Enterprises introduce Scala when they try to break up their (Java) monolith into microservices.
So it seems that Scala has been carving out it's place in backend/microservices with scalability requirements, and is eating part of Javas cake there.
Earlier quoted context omitted.
I did not want to start a flame-war Scala vs Go, it's just that I like Go simplicity & readability (I also like Python and Ruby for those reasons as well) whereas I'm not a huge fan of the Perl feeling of Scala.
When there's no ability in the language to abstract, there's no abstractions to learn, beyond what is built in. But this is not a blessing, it means we have to study every line of code and hope that we can uncover some emergent higher-level structure, if it exists.
Earlier quoted context omitted.
> Also many open source libraries in Scala land have a very short life time and will not be upgraded to Scala3. No problem with Java, but it will take months for many larger projects to remove Scala2 library dependencies from their code base. The announcement says Scala 3 will be able to call Scala 2 libraries, so even if you're right (which is not my experience of open-source Scala libraries at all FWIW) this won't…
What web framework are you using? Both Lift and Play had major migration problems over the last 5 years due to cutting off support for older Scala versions.
Earlier quoted context omitted.
Implicits are very powerful when used correctly, but are terrible if not.
If " is very powerful when used correctly, but terrible if not": think long and hard before adding to a language.
I wouldn't want to have any more language features that pushed as hard as implicits do, but one somewhat-experimental feature in a language is ok, just about. I don't think Scala is a thousand-year language, but it strikes the best balance given the current state of the art.
Earlier quoted context omitted.
When there's no ability in the language to abstract, there's no abstractions to learn, beyond what is built in. But this is not a blessing, it means we have to study every line of code and hope that we can uncover some emergent higher-level structure, if it exists.
> hope that we can uncover some emergent higher-level structure, if it exists. That's exactly what I feel when I read Scala code, everything is a soup of custom operators, implicits and objects disguised like functions (or the opposite, you think it's an object but actually it's a function), it makes the code very hard to maintain and read. At least with Go, Python or Ruby your logic is in plain English, that makes i…