Hacker News Reader

Comment by scotchmi_st | Hacker News Reader

I would love for there to be a similarly thorough project with Clojure. It really bothers me there's no good native compiler. Apart from anything else, it means that Clojure lives and dies by the languages it compiles to, and while Java is used everywhere still, it probably isn't the thing the kids are learning these days. Besides, without going into any further rational arguments for why using the JVM (or another VM) isn't always great, something about it feels a bit icky to me. On an aesthetic level.

View on HN

I maintain a project called Ferret [1], which compiles a subset of Clojure to C++11. No VM no dependencies you get a single cpp file that can be compiled to native code. Supports any platform with a C++11 compiler. (atmega, arm, x86 etc.)

[1] http://ferret-lang.org/

Doesn't using the GPL for the stdlib also mean that all programs written in ferret must also be GPL?

Scala (and Java itself) are much easier to build native compilers for than Clojure, where numerous values are actually small dictionaries, nothing has a fixed type, and a large amount of the code is expanded from macros that are expecting to executing in the environment of deployment (not some special compilation stage). It is a language that essentially needs a heavy runtime to be remotely efficient (as anything super small is going to be rather equivalent to a barebones/naive JavaScript implementation), and it is unlikely that an attempt to build out a nice runtime for it is going to somehow be extremely better than the JVM (or a JavaScript engine, which might be even better in some ways).

Forgive my ignorance, but wouldn't one of the existing Schemes be a better or as good option?

I thought the benefit/raison d'etre to Clojure is the JVM ecosystem.

JVM is the benefit, but great immutable collections data structures and respective functions are also very very nice.

IME the biggest thing is having the same, much-better-than-JS language on front and back end.

> isn't the thing the kids are learning these days

Yep, they learn Ruby and then they need to go JRuby when performance becomes relevant. :)

Or they tend to just Go. Interestingly, I've read a lot of Go users come from the Ruby and Python communities.

Im one of those. Anytime Python / Django doesnt cut it I use Go. Works very well.

Have you got a few examples where you had to replace the former for the latter? Really interesting.

Sure. Last one was a static asset server that had to perform or the users would notice a delay. Built one in Go in about a week and put it behind nginx on a vps. It was faster than required, stand alone, and used very little memory. Its still running to this day.

What is interesting is leaving the expressiveness behind of a language like Ruby or Python, for a bit of AOT compilation to native code.

I bet if something like RubyMotion wasn't a commercial product, the reality would be quite different.

Crystal and Nim can be good alternatives, no type system sucks anyway

I agree, but they lack the Google stamp, which is one reason for Go's adoption.

I've read a lot of Go users come from the Ruby and Python communities

Don't believe what you read, especially when it originates from a biased source.

When i want productivity, i use python.

When i want speed, i use c.

When i want both, i use both.

So it isn't the case many Go users come from the Ruby and Python communities?

I'm more confident with static typing... also easier to refactor. Go's more productive for me after a cut-off. I still love using Python for quick scripts.

As a Scala/Java dev, I'd be willing to explore Go not because it seems like a better language (I have no opinion), but because I'd hope there's less design pattern/enterprise-overengineering approach among devs. Even in Scala, which is super-flexible, people tend to structure code like they do in Java - everything is decomposed into tiny classes to the point of absurd. One of the reasons is that the mocking frameworks expect to mock classes, so every bit of functionality needs to be it's own separate class, just like in Java...

If Go ever gets adopted by the enterprise for full stack applications, not only devops related stuff, expect enterprise architects to come up with GoEE.

SwiftEE looks far more probable as IBM has already jumped on Swift on server thing. The no-GUI and no-framework Go is not helping Java style solutions.

> The no-GUI and no-framework Go is not helping Java style solutions.

Just wait and it will come, it only needs a bit of enterprise architecture caretakers.

JEE might have its flaws, but it is way better than any C or C++ enterprise stack I have used before, definitely better than CORBA for example.

I have no problem with JavaEE and I have used it many times. Though JavaEE developers/architects like Java EE solutions generates 10-20 times scaffolding in meetings before getting to the point.

Funnily enough, I was reading a Scala program the other day and I noted how much it looked like a high-level dynamic Java programming. I think there was maybe 8 lines of typical functional programming code and the rest just looked like imperative code. It seems a waste to use Scala that way to me, but maybe I'm missing something?

Even if you're writing Java-like code you get a lighter syntax, fewer awkward special cases (primitives and arrays aren't as special, == does the right thing by default, try doesn't need braces and nor do function blocks, if is an expression), and some very useful code-saving constructs (case classes, pattern matching). It's not using Scala's full potential but it's still a good language for that space.

I view mocks as a code smell. If you have good interfaces and make a clear distinction between services and values you should never mock - stub your services, and use real values in tests.

It's the Never Java crowd who I just don't get. Java is almost always the most practical answer. And if you don't like Java, then use C#.

If you hate yourself sure, Java is one of the worst working environments for a tech stack I've ever worked in. I've worked in a ton of others.

I am yet to use a development environment that matches Java and .NET in terms of tooling, including libraries, IDEs, GUI toolkits, profilers , application servers, integration with legacy systems, network monitoring of clustered applications,...

why Ruby's performances are low? I've tried ruby but sintatically makes my eyes sad. and i left

Java is still taught in plenty of places and is entrenched enough to stick around for the foreseeable future. The JVM would still be fine even if Java the language declined. Clojure is is a much less vulnerable position than most languages in terms of VM risk, with Clojurescript and ClojureCLR.

The real benefit of native Clojure to me would be for reducing startup time and the JVM overhead in containers. The best option for this right now is CLJS, but it would be nice to just not have a runtime.

You always need a runtime, even if it is a native compiled one.

one of Hickey's initial goals for Clojure was to be hosted language by design because <reasons>.

still i agree with you, having native clojure would be amazing. there is pixie which is transpiled by rpython into c++ but it's pretty much abandoned.

There's also https://github.com/pixie-lang/pixie - a Clojure flavoured Lisp on top of the PyPy JIT foundation.

There's [cljs + react native](http://cljsrn.org/) which isn't a native compiler, but does compile to native code.

The kids are learning javascript, as it runs everywhere. Plus there's a clojurescript, so you should be safe. Furthermore, I wouldn't be scared on Java dying.

Reply on news.ycombinator.com