Hacker Newsnew | past | comments | ask | show | jobs | submit | felipehummel's commentslogin

That's the best and succinct description of using ChatGPT for this kind of things: it's a floor raiser, not a ceiling raiser.


If it's of interest, I expanded on this in a blog post: https://elroy.bot/blog/2025/07/29/ai-is-a-floor-raiser-not-a...


That's no true at all. The syntax is pretty similar with few key differences. The idea is for dotty to become Scala 3.0. But, in the meantime, the next Scala 2.* versions will pave the way for 3.0. Meaning to avoid too many breaking changes in 3.0.

The above has been said repeatedly by Martin Odersky (creator of Scala) and the folks on the Scala compiler team in talks and discussions.


Martin has made no guarantee of compatibility or even to supply a Scalafix app. The fact you can do this relatively easily today is just a consequence of Dotty being very young. As it evolves and becomes more complex, there is no guarantee that a translation from Scala to Dotty will even be possible to achieve automatically.


> Martin has made no guarantee of compatibility or even to supply a Scalafix app

The entire point of scalafix[1](developed by the Scala Center) is to bridge the gap between Scala 2.x and Scala 3/Dotty. Martin talks about it in every Dotty presentation.

[1] https://github.com/scalacenter/scalafix


You may try out using Scala as script language like this: "scala myScript.scala". The first startup times are slower, and even after that it may be slower than Python/Ruby but it still may be sufficient for your use case.

Using "sbt ~run" (re-runs your program automatically at every file change) may also be an option.


I don't see a reason why Clojure couldn't achieve the same startup time? I am trying to avoid the JVM startup time itself so that leaves out Scala/Clojure.

I'd like to be able to have a fast startup time when, say, running a script with its containerized environnement, when it is done the container exits, so I can't leave a vm running.

So I believe that leaves out JVM languages.

Independently from that, I did try Scala before Clojure and found its grammar to be overkill and unintuitive so it wouldn't be my first choice.


Although named arguments are good, you won't use it in all function calls.


Can you elaborate on this: "and to handle all cases..".


Look up "total functions"


Of course, not all Haskell functions are total...


From my brazilian perspective it's very strange to read this. In Brazil, vacation is mandatory by law. Any employee has 30 days of vacation by year. But the moment the employee goes on vacation and how he does it (30 days straight, 15-15 days, 20-10...) is still discussed previously with the employer.

I'm not judging which one is better, just acknowledging the culture difference.


Swiss here; having 25 days excluding local and national holidays.

It really is a strange sight, this theme popping up all the time on HN, with some author proclaiming "look guys this is a good thing because X,Y,Z", when it's an absolute no-brainer for oneself.

Mind you, 25 days is more or less a norm; the law requires only 20 days.


Not really a natural law, but medicine from time to time finds out that working too much or sleeping less or not having time for pleasure/fun/family hurts your health.


You can actually make it automatically convert in both directions with just an import. But it is good practice to do it explicitly. In my opinion, for a typesafe language, this is a good way to do it.


The conversion, either implicit or explicit, is not free, neither in terms of performance, nor in terms of mental effort. This is not the case with Groovy, Kotlin and Clojure (though Java interoperability in Clojure does require more mental effort than in Groovy and Kotlin).


I would argue that Groovy and Clojure require just as much conversion (I have no idea about Kotlin). Scala and Clojure both require conversion if you want to use idiomatic data structures. I think Groovy is actually worse about this because you get secret implicit conversion to add meta classes and null objects. I've run in to a bunch of difficult to track down bugs where Groovy has forgotten to do these conversions.


I think "distributed" in this context is about multiple machines/servers. Not multiple plataforms.


A few suggestions: you could remove this kind of idiom: .map( result = { ... }) In the blocking commands example the snippet resembles the Javascript callback hell when it could be simpler to read: https://gist.github.com/felipehummel/6187248

Also, even simplifying it, it still seems overcomplicated. The returning type: Future[Try[Option[(String, ByteString)]]] is too much. Can't you remove the Try or the Option? Futures can already hold either a Sucess or Failure, so isn't the Try redundant?


I removed `Try` in the version 1.1


Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: