HNHacker News
TopNewBestAskShowJobs

sideeffffect

307 karma · joined January 5, 2019

submissionscomments
sideeffffect··on Next steps for Rust in the kernel
I don't now what situation was Scala in 10 years ago. But the situation it is now couldn't be further from "free fall".

It is _the_ language where most of the Functional Programming in the industry takes place (that's not to say that Haskell, F#, OCaml or Clojure are bad, they just aren't as widely used). And that also means that there are lot of open job positions available.

I like FP and Scala comes with some awesome libraries for concurrent/async programming like Cats Effect or ZIO. Good choice for creating modern-style micro-services to be run in the cloud (or even macro-services, Scala has a powerful module system, so it's made to handle large codebases).

https://typelevel.org/cats-effect/

https://zio.dev/

The language, the community and customs are great. You don't have to worry about nulls, things are immutable by default, domain modelling with ADTs and patter matching is pure joy.

The tooling available is from good to great and Scala is big enough that there are good libraries for typical (if not vast majority of stuff) and Java libs as a reliable fallback.

sideeffffect··on JDK 19 Release Notes
I would use Scala. I like FP and Scala comes with some awesome libraries for concurrent/async programming like Cats Effect or ZIO. Good choice for creating modern style micro-services to be run in the cloud (or even macro-services, Scala has a powerful module system, so it's made to handle large codebases).

https://typelevel.org/cats-effect/

https://zio.dev/

The language, the community and customs are great. You don't have to worry about nulls, things are immutable by default, domain modelling with ADTs and patter matching is pure joy.

The tooling available is from good to great and Scala is big enough that there are good libraries for typical if not vast majority of stuff and Java libs as a reliable fallback.

sideeffffect··on JDK 19 Release Notes
But they are being multiplexed on more than one Platform thread this time.
sideeffffect··on How fat does a fat binary need to be? (2021)
Wow, really? I've always thought that Cargo by default forces a package into one particular version. And that a particular package in multiple versions is something people opt into only in rare circumstances (similarly as in Java/Maven/shadowing case).

I'm no Rust expert though.

sideeffffect··on OCaml at First Glance
To be frank, any language's syntax is rather busy compared to F#. That language is setting the bar how beautifully a language can look. I don't know of any that comes close, not even Haskell or Python...
sideeffffect··on Millet, a Language Server for SML
SML comes with many implementations/compilers, but it is one standardized language (with formalized and verified semantics, IIRC).

Does that mean that there is one repository with modules (like PyPI or Maven Central) which all the implementations can use? Is there even a single build tool that can work with all (or at least some) of them (like Maven, etc.)?

sideeffffect··on Everyone seems to forget why GNOME and GNOME 3 and Unity happened
I'm just surprised that I had to scroll so down to see a correct characterization of the article...
sideeffffect··on Atlassian is 20 years old and unprofitable
I really liked, when I used them, how well integrated all the tools were: BitBucket, JIRA, Confluence...

You could see PRs related to a given ticket, see tickets in wiki, I'm sure it integrates well with CI (Bamboo/Pipelines?), etc. It might seem small, but such integration makes work more pleasant and comfortable.

sideeffffect··on Increased Subscription Pricing for IDEs, .NET Tools, and the All Products Pack
IntelliJ Community Edition is indeed Free Software! Apache 2.0 license, to be specific.

It's an awesome product, I recommend everybody to use it. I personally use it with its amazing Scala plug-in, also friendly licensed.

sideeffffect··on Type-checked keypaths in Rust
JMESPath is what JSONPath should have been

https://jmespath.org/

specified, standardized, with tests and implementations for multiple languages

sideeffffect··on Rust Is Hard, Or: The Misery of Mainstream Programming
> Rust-like programming language that was just a little bit higher level

I think the best answer is Scala. It has an awesome community/libraries/ecosystem. See this for example https://news.ycombinator.com/item?id=31601040#31604573

There are other great answers, like F#, Haskell or OCaml, but these are not as mainstream and that comes with its challenges.

With Scala you get and awesome IDE, surprisingly wide variety of libraries and the whole Java world as a backup.

sideeffffect··on Rust Is Hard, Or: The Misery of Mainstream Programming
Scala. With the functional effect systems, like Cats Effect or ZIO, you get superpowers.

Not only can write programs that are "async", but you also get easy retries (and other tricks), safe refactorability (because of its Pure FP nature), reliable and painless resource management and some other goodies like STM (Software transactional memory).

It's really that good.

https://www.youtube.com/watch?v=qgfCmQ-2tW0

https://zio.dev/

https://typelevel.org/cats-effect/

sideeffffect··on Dragonflydb – A modern replacement for Redis and Memcached
This BSL Business Source License is endorsed by neither the Free Software Foundation nor OSI

https://www.gnu.org/licenses/license-list.en.html

https://opensource.org/licenses/alphabetical

That's a big red flag.

sideeffffect··on NYC allows citizens to report idling vehicles in exchange for a cut of the fines
Officious: Rise of the Busybody State

https://www.amazon.com/Officious-Busybody-State-Josie-Applet...

In Anglo-Saxon countries there is a new and distinctive form of state: the busybody state. This state is defined by an attachment to bureaucratic procedures for their own sake: the rule for the sake of a rule; the form for the sake of a form. Its insignias are the badge, the policy, the code and the procedure. The logic of the regulation is neither to represent an elite class interest, nor to serve the public, nor even to organise social relations with the greatest efficiency as with classic bureaucracy, but rather to represent regulation itself.

https://www.youtube.com/watch?v=ehTBd_XxMMM

sideeffffect··on I would like a job writing Haskell
> doing FP in Scala versus alternatives

I think Scala is the language most actual functional programming on this planet takes place these days. Be it just FP or pure FP.

I especially like pure FP in Scala. One can do that with Cats Effect (from the TypeLevel family of languages) or ZIO. They're both awesome, so check them out and pick what you'll like best.

https://typelevel.org/cats-effect/

https://zio.dev/

You don't even need to reach out to Scala 3 (still not as mature in its tooling support), you can have a great time with the latest Scala 2 (2.13).

> versus alternatives

I think of Scala as a opinionated take on ML and a module system that is tailored to JVM (and is seamlessly interoperable with Java) that just happens to have syntax heavy on braces/parentheses. Otherwise, what's not to like? :)

sideeffffect··on I would like a job writing Haskell
> cats or zio are basically ports of Haskel into Scala

Not really. And ZIO takes special pride in that not being the case.

That's not to say that the authors didn't know (about) Haskell and its libraries. But these are distinctly Scala takes on the topic. Especially ZIO, heavily relying subtyping and vairance, is very far from Haskell while still being pure FP.

ZIO's "FP" library called "ZIO Prelude" totally revamps the "traditional" Type Class hierarchy, using Scala's intersection types feature. The name ("Prelude") is the only Haskellism there :)

https://www.youtube.com/watch?v=OwmHgL9F_9Q

https://zio.github.io/zio-prelude/docs/overview/overview_dia...

https://github.com/zio/zio-prelude/

sideeffffect··on I would like a job writing Haskell
> I don't even view Scala as a functional language, as functions (methods) are not first class. Lambdas are encoded as objects with a single method. It's much more expressive than Java and so better at expressing many functional programming ideas, but it's not a functional-first language, it's an evolution of Java.

It' technically true that Scala's fundamental building block is object, not function.

But that is in my eyes more of an implementation detail. Scala is a language that blurs the distinction between FP and OOP to the point of meaninglessness. You can do FP and still organize your code into classes/objects/traits (aka modules). You can choose to do side effects. Or you can waive them and do pure FP (like in Haskell) with TypeLevel or ZIO.

> it's an evolution of Java

I would say that it's kanda the other way around. Scala is a beacon that almost all languages are converging towards, not just Java.

https://www.lihaoyi.com/post/FromFirstPrinciplesWhyScala.htm...

> complex language with many experimental and interacting features

It doesn't have that many features. Some people even call Scala simple for this reason. But the features that is has are _very_ powerful. Some maybe even too powerful for my taste (implicit conversions anyone?). And they're orthogonal so they can be composed together.

Sadly, such composition can be brittle and non-beginner friendly, especially when it fails -- things like weird type errors or weird unexpected behavior at runtime, or compiletime for that matter, etc. So Scala will give you a lot of rope to hang yourself onto, if you'll be blindly taking it.

But it doesn't have to be that way. You (or a senior developer) have to know what you're doing. Then you can reap significant benefits.

It's good news that Scala 3 significantly improves on this front -- it emphasizes programmer's intent instead of Scala's internal mechanics.

Sure, in some languages, this risk isn't even on the table (Go, etc). But having power also comes with benefits, not only the potential problems I've described above.

sideeffffect··on I would like a job writing Haskell
> awkward currying

Personally, even though I haven't really thought it through deeply, I feel like Scala would be better if everything were curried.

> Subtyping also has many complex consequences

But also substantial benefits!

> There is limited type inference

I wish Scala would improve in this regard. Maybe paradoxically, inference works better with code tuned for subtyping and variance.

> tail call optimisation

This will be fundamentally solved by Project Loom. At least on the JVM (there's also Scala on JS and on LLVM).

> F# has units of measure

I dearly miss those. Type Providers even more so.

> OCaml has polymorphic variants

Could be nice in Scala. Or maybe not, can't tell now. And there's always the risk of too many features, which makes a language worse, not better.

> It was not designed as a functional programming language first and foremost

This is misleading at best. It was designed to show that the distinction between OOP and FP is arbitrary, not fundamental. In other words, Scala erases the distinction, it's fully OOP and fully FP. Scala has higher order functions, ADTs, pattern matching, a module system, like SML/OCaml. But it uses keywords `class` and calls it's instances "object" like Java. And it's interoperable with Java. But theoretically there's no fundamental distinction.

More languages are becoming more and more like Scala, btw.

https://www.lihaoyi.com/post/FromFirstPrinciplesWhyScala.htm...

And the concept of a programming language paradigm is fake from the start anyway ;)

https://www.cambridgeblog.org/2017/05/what-if-anything-is-a-...

sideeffffect··on I would like a job writing Haskell
> scala/functional engineers are also more likely to focus their energies on monads and type theory rather than product delivery

This feels to me like a low effort and vague criticism.

Essentially, this is a complaint about an arbitrary group of developers that they're playing around with tech (whatever that tech might be) instead of delivering...

Obviously, in this case you can't say that specific thing about Python/JS/PHP/whatever developers, because "monads and type theory" just don't apply in these languages. (I know Python has MyPy, but let's put that aside for the simplicity of the argument.)

But for some non-scala/functional engineers, somebody could complain that they're wasting time playing with GUI frameworks, testing frameworks, async libraries, whatever...

The truth is, people can clown around with any technology, just as people can deliver with Scala/FP or something else.

sideeffffect··on I would like a job writing Haskell
> Scala is to Haskell what F# is to Ocaml

That's not quite precise, IMHO.

F# is an awesome language that I hold very dear, but it is a castrated form of OCaml. It has only a few features that OCaml doesn't have. For example Type Providers or Unit of Measurement. These are nice and useful features, they're not gimmicks, but they're not fundamental.

On the other hand, Scala isn't a hollowed out Haskell. Haskell, admittedly, is a more powerful language and has features Scala doesn't, like a linear type system. And it's just different, non-strict, whereas Scala is strict. But Scala is also very powerful in other fundamental areas, where Haskell is weak. Scala has a superior module system, it's biggest strength IMO. Haskell's modularity story is that great AFAIK.

sideeffffect··on From TypeScript to ReScript
F#'s "Computation expressions" are the same sort of thing as the mentioned Haskell's "do notation" and Scala's "for comprehension". They're just thin syntactic sugar for "callbacks" -- chaining maps/binds/flatmaps/etc. Even though F#'s "Computation expressions" are very cleverly thought out and more general.

https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...

Async/await for example in C# or Rust is different. This translates the program into transition automata/coroutines.

sideeffffect··on From TypeScript to ReScript
I'm almost sure that Haskell has had its "do notation" even before 2007.

And maybe even Scala its "for comprehension".

sideeffffect··on “I am literally losing sleep” over Java (1996)
> JDK 17 has most of the good features of Scala and Kotlin.

I'd be sooo happy if that were the case, but sadly, it's not. From the point of view of Scala, I still see many features missing. Roughly in the order of importance:

* Immutable persistent collections in the standard library (and thus lingua franca in the libraries). Just so much better than mutable collections. Way less headache. Once you start using them, you realize how rarely you actually need mutable ones.

* Pattern matching. Java will surely improve on what is currently available. But why wait? It may take a long time.

* Sophisticated string interpolation. It's powerful, and yet is still easy to read. Again, Java is on its way to get it, but with Scala you can have it right now.

* Type Classes. Sometimes it is very good design to separate data from functionality. Java designers (Brian Goetz IIRC) mention they would like to get this eventually. Scala has an interesting design of Type Classes -- "givens" -- which is also modular (in contrast to Haskell). Scala also has an elegant mechanism for Type Class derivation using the "derives" clause. https://docs.scala-lang.org/scala3/reference/contextual/deri...

* for-comprehension syntax and IO/Task/ZIO for async programming. Project Loom still hasn't delivered. But Scala has you covered. It gives you for-comprehension syntax, so that you don't have to suffer from nested callback hell. And there are many great libraries for async programming, like ZIO or Cats Effect. These are easier to work with, compared to other Futures from various Java libraries, because they're lazy, not eager. for-comprehension syntax is also useful for other things, it's just that async is the typical usecase.

Higher-kinded types. Not everything has to be super fancy higher-kinded type-level craziness. And very often one gets away without needing to use higher-kinded types and that's good (just as often a solution without parametric polymorphism aka generics is enough). But other times it's awesome to have this power of abstractions. Typically, but not only in libraries.

* Object. Sometimes you just need to have an object (which might implement an interface/class/trait). But Scala doesn't force you to create a whole class, if you only even want just one instance anyway. A small thing, but way more elegant.

But I'm really happy to see Java/JVM improve. The 17 release has brought some great features, but in the language level (records, embryonic pattern-matching, ...) and the VM level (GCs in particular). We all benefit more or less directly, one way or the other.

sideeffffect··on PR to Merge Multicore OCaml
Since you mentioned using IntelliJ, I can't resist asking the question: Have you played with Scala too? If yes, how would you compare OCaml to it?
sideeffffect··on PR to Merge Multicore OCaml
I don't know much about OCaml, only Scala and Cats Effect/ZIO/Monix, but would appreciate if I could get a gist of what Multicore OCaml brings to the table.

Is there somebody who's familiar with both worlds and could compare them and explain how Multicore OCaml (and possibly the new effect system) work?

Thanks in advance!

sideeffffect··on Types for Tables: A Language Design Benchmark
Could you explain why you wanted to avoid the term (excuse the pun :) ) "type" so much?
sideeffffect··on Types for Tables: A Language Design Benchmark
> Empirical is the only system I know of that can infer types while staying static.

F#'s Type Providers can do that too.

https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/typ...

sideeffffect··on Java 17 / JDK 17: General Availability
Can you please compare to 11 or even 8?
sideeffffect··on Grafana, Loki, and Tempo will be relicensed to AGPLv3
If I contribute a code under the new CLA, is Grafana Labs allowed to relicense that contribution under a non-copyleft license, like Apache Public License 2.0, without my further permission?

If yes, than it's a really bad bad thing and I hope they change it.

CLAs that permit relicensing for a project that already uses permissive license is fine and fair. But doing that on a project with a copyleft license is a bad taste. It would enable Grafana Labs to give Grafana to a party X which can then give it to party Y, where X isn't required to give all the necessary freedoms to Y.

https://opensource.com/article/19/2/cla-problems

https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/

sideeffffect··on Metals with Scala 3
> I think Scala will always suffer from its choice to make implicits so fundamental.

Thankfully it won't. Scala 3 deconstructs implicits and discourages (or outright discards) the bad parts: http://dotty.epfl.ch/docs/reference/contextual/motivation.ht...

"Implicits" are useful for the Type class pattern and is available in Scala 3 with an improved syntax.

"Implicits" for implicit conversions is an ugly hack that should be avoided as much as possible and Scala 3 restricts it.

"Implicits" for extension methods is a clever hack, and Scala 3 provides a dedicated syntax for defining extension methods.

← PreviousPage 3 of 6Next →