Hacker News new | past | comments | ask | show | jobs | submit | grogs's comments login

Scala 3 somewhat simplies implicits by the way. Especially w.r.t to extension methods, which are now a first class construct in the language: https://docs.scala-lang.org/scala3/reference/contextual/exte...


Kotlin is a better Java, or simpler Scala. Simpler can be better for plenty of teams, especially for those coming from Java. But I'll not be switching any time soon.


Sounds like PJAX.



Sidenote: Mindfulness (AKA vipassana or insight) meditation can give you that gap between feeling something, an emotion in this case, and responding to it. It's potentially useful for a lot of usecases - the NHS have been offering mindfulness-based cognitive therapy for a while now - but what you're talking about sounds very relevant!


Thanks I will look into this


Can I use this to run Scala Native apps in the browser? Making Scala.js redundant. :P


Perhaps, but you wouldn't actually want to run a Scala program that way.

To implement C semantics, Emscripten uses a single, large JavaScript typed array as the heap. To the JS garbage collector, this heap is a big, opaque blob. Then your Scala Native program has its own garbage collector operating within its heap. The two garbage collectors are unaware of each other. This is just a vague intuition on my part, but it seems to me that an arrangement involving nested garbage-collected heaps is bound to be suboptimal. Scala.js is much better in this regard, since Scala objects are just JS objects, sharing a garbage-collected, compactable heap with the other JS objects.


Asm.js optimized browsers should make the unneeded JS GC have no overhead.

But you are correct that it's a bad idea. Like running Scala.js on Rhino/Nashorn


Scala.js is not only about making your Scala app run in the browser. It's also (and mainly) about letting you develop in Scala for the Web environment, which includes manipulating the DOM and calling any existing JavaScript library. Scala Native run with Browsix (or compiled to asm.js/WebAssembly for that matter) would not give you that.

So no, it would not make Scala.js redundant.


Also deis and flynn. http://deis.io/ https://flynn.io/

There's quite a few options in this area. I've recently started using dokku for personal projects. My current plan is to migrate to deis in future if/when I want multiple nodes.


If you're only targetting 2-3 systems for redundancy (each the same apps), you could configure them exactly the sime behind a load balancer, then have each deploy just run to all 2-3. Did this as a POC early last year.


How do you handle databases in that configuration?


In that case, it was using Azure Tables and an ElasticSearch cluster. Also, you'd probably want to manage databases used by multiple systems outside your dokku anyway, but I would just assume use a DBaaS offering given an option is suitable, I have less desire to manage a database/backups, etc.


Which is what Dotty is attempting to do, but hopefully with minimal codebase breakage.

There's a tradeoff between breakage and improvement, but I'd like not to wait 10 years before I can use dotty (like python 2 to python 3). We can always have another dotty in 5 years time for another round of rationalisation/simplification.


I think Scala is doing a decent job at bringing these concepts together. Scala ticks all the OOP points you made - even more than Java does (Java has special primitives for int/booleans etc, in Scala that's more hidden, really everything in an object). FP also likes Encapsulation as you decided it - pure functions, that don't do side effects (even logging) without it being explicit in the type signature.

FP can model relationships/interactions OK. They just have new tools/techniques to do it. For example, instead of mutating things, you create a copy with the change. You then push the actual state/mutation to the edges of your system (e.g. the database), and thus hopefully make it easier to reason about. But it can be slower or hard to change things deep in an object graph. For slowness - we have persistent collections which re-use unchanged parts of the collection and implement performant "copying". For deep structures, Haskell & Scala have lenses.

It's still an ongoing exploration, with people borrowing/discovering new techniques, but I think it's working quite well and I'm happy to keep exploring.

In the other direction, I've been following Rust. I find it very interesting that it's got a very good type system, but still has mutation. Instead of avoiding mutation, they track ownership in the type system, and thus keep it easier to reason about. By doing this, they make the the performance/memory management easier to reason about, without making it too hard to reason about where effects are happening.


Yep, or drop the dependency. E.g. For joda specifically, you should probably move to Java 8 date API, which is more likely to be ported.

Bare in mind that scalajs has the same issue and a lot of work has already been done!


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

Search: