61–70 of 203 posts
This is also being taken over by Python. Databricks Koalas is a pandas interface on top of Spark - https://koalas.readthedocs.io/en/latest/
PySpark was already there (and very much in production). But Koalas (in beta) completely changes the go-to production aspects of spark.
Earlier quoted context omitted.
Go is a competitor to Java 1.0, it still needs to grow a bit more if it wants to compete with Java 14 and its 25 years of tooling and libraries. If Go 2.0 ever happens, it will be a competitor to Java 5.
Go is a competitor to Java in that most of the things people do with one, they could do with the other. As a Java guy, i would agree that Go is not actually competitive with Java. But then, a Go guy would probably say the opposite.
Earlier quoted context omitted.
Announcement on Dotty as the future Scala 3 came from Scala Center (EPFL) not Typesafe/Lightbend. AFAIK Typesafe/Lightbend has made no commitment to Scala 3. Too bad the roadmap for Scala 2.14 has been scrapped.
I've worked with Dotty a bit and read about it a lot. I am very excited about Scala 3 :) Scala 3 isn't a python2/python3 situation. It will take years for large codebases to be upgraded to Scala 3. However, the tools to migrate code from Scala 2 to Scala 3 will be reliable and highly automated, due to Scala's strong type system. Most popular Scala libraries and frameworks will be available on Scala 3 right from the g…
Which for production level code bases means never. I can't even imagine what we are going to do with our 7 year old Scala code base.
But: 1) the ecosystem makes it seems like I need to be a genius enough to learn a new DSL a bit too often, and everything is so...complex, which leads to...
2) It is hard to pitch to an organization because of the learning curve if you assume any project maintainer must learn scala to expert level. I failed (in one attempt on a scala mailing list) to pitch to the scala community the idea of having language levels: a compiler switch or the like that would guarantee that a given project will be maintainable by java programmers with only N (1-2 I hope, for the first level) hours of scala training or study, maybe another level for adding certain features (or listing them in a config file), and full-on expert. So teams can be formed with realistic long-term maintainability in mind. Edit: This may be practical with add-ons I didn't try yet.
3) It was unclear what would be the best reasonable, maintainable way to use sqlite. (Edit: in a multiplatform way to include at least BSD, linux, windows, mac. Maybe call a native code library for each? Sounds like lots of work and maintenance to do it well.)
4) Startup times, future viability of scala native (edit: or equivalent), and whether it helps or adds enough more complexity given all the above, to just learn Rust and (hopefully) simplify life (in some ways).
5) And you have to learn java first (for those who didn't know it already), and know its libraries and idioms to some extent. Will that still likely be true?
Comments welcome. (I enjoyed the article.) Maybe I'm just the type that wants to hit the sweet spot between what C, Java, and Scala do (edit: and Scheme), in a way that is hopefully/eventually at a complexity level that is inviting to other devs, but with plenty of learning headroom for my future growth.
Earlier quoted context omitted.
Go is a competitor to Java 1.0, it still needs to grow a bit more if it wants to compete with Java 14 and its 25 years of tooling and libraries. If Go 2.0 ever happens, it will be a competitor to Java 5.
So, it depends on what you’re talking about; language or organizational need. Go is an imperfect match for Java The language, largely because of the whole Generics thing. But if you’re talking about how teams use Java and Go, they’re a good match now. Go was designed for large companies like Google to have a huge number of engineers and produce consistent, quality code, all while constantly on boarding people and mov…
If you are talking about doing REST APIs, talking to Postgres in Java 1.0 servlets style code, yeah Go is a replacement for Java.
Except that is like 1% of everything that is currently being done in Java.
I wanted Scala to be my "better Java" for a long time, mainly because it seemed to have plentiful headroom as I seek to learn more. The community enthusiasm was also contagious. But: 1) the ecosystem makes it seems like I need to be a genius enough to learn a new DSL a bit too often, and everything is so...complex, which leads to... 2) It is hard to pitch to an organization because of the learning curve if you assume…
Scala is a beautiful and elegant language. I really thought that it would be one of my favourite languages when I first started working with it. However, after some time I got disenchanted. First, Scala is hard. Projects written by one person quickly become a deep functional labyrinth and custom architectural patterns because Scala is so expressive and you can do all kind of twists. Second, the entrance level remains…
It also reminds me of the famous Kernighan quote: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." [2] Scala might be optimal for some group of people, but definitely not for me, and I think not for a mainstream developer audience either.
I wanted Scala to be my "better Java" for a long time, mainly because it seemed to have plentiful headroom as I seek to learn more. The community enthusiasm was also contagious. But: 1) the ecosystem makes it seems like I need to be a genius enough to learn a new DSL a bit too often, and everything is so...complex, which leads to... 2) It is hard to pitch to an organization because of the learning curve if you assume…
One of the coolest things about Scala it that it already contains lots of Java best practices. Case classes, singleton and companion objects, traits, powerful generics... almost every Scala feature is a builtin answer for a Java pattern. Hell, even implicits in all its various forms are elegant solutions to common Java problems. People getting creative with these features is an entirely different issue. It's possible, and desirable, to use Scala to craft simple, elegant, and understandable code. Fancy but unmaintainable code should not ever be accepted: it's the job of the developer to teach the reader what the code does, and while this is true in any language, is more important when coding Scala, because the multiparadigm approach means there are multiple ways to solve things.
What you have to learn, at least in a basic form, is how the JVM works.
I wanted Scala to be my "better Java" for a long time, mainly because it seemed to have plentiful headroom as I seek to learn more. The community enthusiasm was also contagious. But: 1) the ecosystem makes it seems like I need to be a genius enough to learn a new DSL a bit too often, and everything is so...complex, which leads to... 2) It is hard to pitch to an organization because of the learning curve if you assume…
Scala dev here. "Having to learn Java" is not true at all, unless you interact with Java dependencies in special ways, or if you maintain a Java API for your Scala code. There are Scala libraries for almost anything, and it's easy to use some Java libs here and there. Creating wrappers is also simple. One of the coolest things about Scala it that it already contains lots of Java best practices. Case classes, singleto…
And the maintainability issue seems similar to perl vs. python in that way: it can be done, but I've found it takes much more work and long-term attention & presence, to enforce things with code reviews than with a project-level config that everyone knows why it is there. Just once when you are not looking and now you have a new (large or small) social and technical headache.
(Edit: in other words, while code reviews are essential I think for many reasons, any time there is a way to enforce something good, before the review, it seems like a win.)
Earlier quoted context omitted.
Did you have trouble hiring Scala devs? And if so, do you think the language benefits outweighed that. This is my main concern choosing to build new ventures with Scala.
1.) Yes 1a.) Scala was a bad choice, but it was chosen because I love the language. 2.) When founders ask me about what language to choose, I tell them: "Choose one where you easily find developers, then you can't go wrong".
As an example, we know that PHP is a "fractal of bad design"[1], but I can't deny that Facebook as a business is doing just fine.
[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/