En gros, mon travail que je fais depuis quelques années ressemble à ceci.
série python3
- numpy+C/C++Créez un pipeline qui gère des données volumineuses avec l'outil écrit.
-Lisez RDB et gérez excel et csv avec les pandas.
série scala2
-Créez un pipeline qui gère des données volumineuses avec Spark.
- Playframework/Gérez une application Web créée avec Akka.
python ne changera probablement pas grand-chose pendant un moment, mais Scala passera progressivement à la 3e série prévue cette année. Dans Scala3 Scala 3, vous pourrez écrire dans une syntaxe basée sur l'indentation comme Python! Tel qu'introduit dans, il semble qu'il sera possible d'écrire «aussi» qui soit compatible avec python comme suit (bien qu'il semble y avoir beaucoup d'opposition pour le moment).
retrait (extrait).scala
enum Day
case Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday
def isWeekend: Boolean = this match
case Saturday | Sunday => true
case _ => false
def fromString(str: String): Day =
try Day.valueOf(str)
catch
case _: IllegalArgumentException =>
throw new IllegalArgumentException(s"$str is not a valid day")
def use(dayString: String) =
val day = fromString(dayString)
if day.isWeekend
println("Today is a weekend")
println(s"I rest {dayString}")
else
println("Today is a workday")
Source: https://github.com/hinastory/dotty_examples/blob/master/src/main/scala/indent_based/IndentBasedExample.scala
Avec le support de l'EDI, j'envie rarement python lors de l'écriture de la série scala2, mais je pense que la syntaxe indentée est plus lisible.
À propos, les personnes qui travaillent actuellement avec python3 ont pensé à la légère à quel point ils seraient heureux s'ils maîtrisaient le système scala3 dans 10 ans (ci-après, python3 peut également être utilisé selon le cas). Supposition).
Un micro service qui a longtemps été un petit puzzle. Puisqu'il contribue à l'amélioration continue des services informatiques qui subsistent, il est prévu que le nombre d'emplois pour créer des micro-services augmentera petit à petit à l'avenir. Dans le cas des microservices, le langage d'implémentation n'a pas tant d'importance tant que l'interface est correctement découpée. Il semble être déterminé par la facilité de réunir des ingénieurs et la productivité élevée de la langue. Scala introduit le framework de microservices lagom depuis plusieurs années. Ces dernières années, lagom est construit sur playframwork + akka, qui est devenu l'une des options pour les entreprises basées sur le Web, et devrait être utilisé pour le développement de microservices à l'avenir. Référence Lagom 1.5, un framework de microservices, introduit Akka Management et prend en charge Kubernetes et OpenShift
(Bien que ce soit un niveau d'étude car je n'ai aucune expérience en développement) Dans les micro services, il est basique de créer un service asynchrone qui utilise pleinement Future etc. (Ci-après, je l'ai écrit dans le style de syntaxe scala3 indent (?)).
HelloStreamServiceImpl_indent.scala
package com.example.hellostream.impl
import com.lightbend.lagom.scaladsl.api.ServiceCall
import com.example.hellostream.api.HelloStreamService
import com.example.hello.api.HelloService
import scala.concurrent.Future
/**
* Implementation of the HelloStreamService.
*/
class HelloStreamServiceImpl(helloService: HelloService) extends HelloStreamService
def stream = ServiceCall x =>
Future.successful(x.mapAsync(8)(helloService.hello(_).invoke()))
Référence Créer une nouvelle application pour le framework de micro service Lagom
Compte tenu du débogage, il serait plus sûr d'écrire un traitement asynchrone dans le langage de compilation scala.
Pendant longtemps, scala.js, qui était la version 0.6, a atteint la version 1.0 en 2020. https://www.scala-js.org/
Bien qu'il ne soit pas largement utilisé, il peut y avoir une option pour écrire le côté client des microservices dans scala.js 10 ans plus tard (mais pas encore). En regardant ce qui suit, il semble que le développement de lagom.js pour les clients de microservice soit en cours. https://github.com/mliarakos/lagom-scalajs-example
Il semble qu'il soit écrit en utilisant la correspondance de modèle côté client comme ceci.
client_invoke.scala
client.greeting.invoke().onComplete
case Success(message) => // display message
case Failure(exception) => // handle exception
Scala2 + Spark2 est l'un des éléments standard pour les projets Big Data sur le cloud tels que Amazon EMR et MS databricks. Les données accumulées vont augmenter dans les 10 prochaines années, il est donc naturel que Scala3 + Spark3 (?) Aura un emploi dans 10 ans. Cependant, il y aura probablement plus de discussions sur le fait que pyspark va bien. Je pense que c'est l'un de mes emplois préférés chez Scala3, mais comme il y a beaucoup d'informations sur le Web, je vais omettre les détails.
Je pense que je peux manger en tant qu'ingénieur en IA même après 10 ans avec un accent sur python, mais s'il y a beaucoup d'apprentissage et qu'il devient nécessaire d'écrire des traitements distribués compliqués, etc., utiliser Scala3 qui est un langage JVM a un large éventail. Il semble se répandre. La technologie à utiliser sera combinée avec le micro service sur Akka et le traitement des données à l'aide de Spark décrit ci-dessus, il est donc abrégé. ... Personnellement, je m'attends à ce que le framework d'IA sur le cloud accessible via JVM mûrisse dans les 10 prochaines années.
... c'est de mon intérêt personnel. Avec les microservices et les ingénieurs de données, l'industrie du jeu est une industrie en pleine croissance. Dans le développement de jeux, le client continuera à être C / C ++ pour le moment, et côté serveur, Go, qui exécute un seul serveur binaire, semble être fort. Si vous utilisez un seul langage, est-ce C # qui a Unity et peut aller à la fois côté serveur et Web Assembly? Du point de vue des 10 prochaines années, comment la rouille sera-t-elle impliquée ici?
scala3 n'est probablement pas largement utilisé dans le développement de jeux. Cependant, si vous souhaitez utiliser pleinement le moteur AI sur la JVM, il peut être possible de faire quelque chose avec Python + Scala + α. Il existe une scala native, mais il est peu probable que tout ce qui concerne le client soit scala.
En tant que personne orientée serveur, j'espère que l'utilisation de WebAssembly pour le rendu côté serveur et quelle que soit la plate-forme se développera. Je me demande si la majorité du développement du jeu se fera côté serveur, et le code côté client devrait être laissé à un artisan ingénieur. WebAssembly 1.0 est le quatrième langage qui s'exécute en natif sur le navigateur comme recommandé par le W3C Personnellement, je m'attends à ce que le langage vlnag / nim soit transpilé en C.
Ce n'est pas Scala3, mais 10 ans plus tard, c'est toujours une combinaison de Python et Go ou C #. Sinon, je me demande si l'avenir de Promane, qui peut utiliser Python pour les projets DX d'entreprise, sera sûr pour les 10 prochaines années. C'est tout.