Any examples of what the new error reporting looks like? The release announcement is rather lacking in details.
Clojure 1.10 release
51–60 of 97 posts
Re: Clojure 1.10 release
#52Earlier quoted context omitted.
> Java is not as bad as you think. Clojure does takes a little longer though For example, I have a Python script[1] that runs on each command prompt to print status about my current git repository. Just timed it, it runs in .08-.12 seconds within a repo and about .02s outside of a repo. I still want to rewrite it in C using libgit2 someday, but something like that would be unusable if it was written in Clojure. [1] h…
Yeah, for scripting you should use something like Planck: it uses clojurescript which is virtually the same language as clojure, but starts up super fast so is great for scripts: https://github.com/planck-repl/planck
absolutely, Clojure is not a scripting language and Planck is amazing.
There are issues with a Graal-compiled Clojure repl due to reflection (apparently), but I think it's only a matter of time before those geniuses come up with something.
Re: Clojure 1.10 release
#53Earlier quoted context omitted.
> Startup time Java is not as bad as you think. Clojure does takes a little longer though > Ability to deploy/share a binary there are jar files, but I know what you mean. Interesting work happening in GraalVM land: https://www.innoq.com/en/blog/native-clojure-and-graalvm/ > Bias against Oracle and Java yeah, well ... we're all biased. It helps us make decisions quickly ;)
> Java is not as bad as you think. Clojure does takes a little longer though For example, I have a Python script[1] that runs on each command prompt to print status about my current git repository. Just timed it, it runs in .08-.12 seconds within a repo and about .02s outside of a repo. I still want to rewrite it in C using libgit2 someday, but something like that would be unusable if it was written in Clojure. [1] h…
And python tends to have fairly high startup time (compared to compiled languages) for any non-trivial script.
Re: Clojure 1.10 release
#54Congrats. I'm trying to learn Common Lisp for great good. And, I love that lisp is still alive. I think we still haven't learned all that lisp has to offer. For me personally, I think Clojure (or any lisp) targeting Go would be awesome. The JVM lacks a killer Go "feature" which is _native binaries/easy deployment. Common lisp and many other lisps lack community which is why I think Go+Lisp would make a great combo. G…
All you'd need is a Clojure to Go compiler. A simple matter of implementation (joking). The good news is that Clojure is relatively easy to tokenize and has a simple grammar. Go v1's lack of generics would make the implementation tedious, but the features announced for Go v2 should make it easier.
A more feasible option is to compile Clojure byte code to native code with GraalVM (http://www.graalvm.org/docs/reference-manual/aot-compilation...). GraalVM's native compiler still has some limitations but is coming along nicely.
Re: Clojure 1.10 release
#55Earlier quoted context omitted.
I would put it simply: Clojure was designed by a thinker , who creates when he is away from the keyboard, not in front of it. When one releases and breaks the code in his head first, very few breaking changes are left for the public releases.
It takes one to know one. (Or so I would like to think.) Rich's writing, presentations, and example of overall conceptual discipline and maturity have helped me focus on the essentials in ways that I could not overstate. I'm glad (but not surprised) to see so much appreciation for him around here, even among non-Clojurists (like myself). At the risk of fanboyism, I am constantly referencing his ideas* to my team, and…
I made the mistake of showing the 'hammock driven development' talk to an employer of mine. He got annoyed by it and said he thought that it was just providing programmers with an excuse for staying away from the computer when they should be writing code.
Re: Clojure 1.10 release
#56Earlier quoted context omitted.
If you want to demand perfection, then Clojure isn't going to meet your standards (what would?). The issue here is that, based on the way they (particularly Rich) talk, we can expect they will not do Bloody Stupid things like the old Python 2->3 changeover. Things like big, breaking changes that require architectural changes to keep current, or break all the available tutorials. If the problem can be fixed with a mac…
You don't think a breaking change to + is any more significant than a breaking change to some other part of the language?
As has been answered elsewhere in this discussion:
That was over 7 years ago, so not particularly recent. And you can get the auto-promoting behavior with +' instead.
Re: Clojure 1.10 release
#57Earlier quoted context omitted.
> I guess I might ask what this stance is founded on? Kotlin has Kotlin/Native, so I was hoping there might be a similar initiative for Clojure. But, a few reasons: * Startup time * Ability to deploy/share a binary * The JVM just seems so "heavy" to me. It's certainly the only language runtime I know of that runs a persistent helper app, or asks to install an Ask toolbar upon installation. * Bias against Oracle and J…
> * Bias against Oracle and Java It's always fascinating when I encounter people with opposite biases to my own. While I'm no fan of Oracle, I seek out technologies that are based on the JVM and try to avoid things based on many other technologies because I intrinsically trust certain behaviors and features of the JVM that other ecosystems lack.
After suffering through Java early in my career I've completely avoided it since then. What parts of Java/JVM do you find indispensable vs the rest of tech?
Re: Clojure 1.10 release
#58Earlier quoted context omitted.
I guess I might ask what this stance is founded on? The JVM is just a binary that runs byte code. It's stable and runs well pretty much everywhere. If you insist the JVM has cooties, you could use Docker and abstract it away, it might be an ideal way to use it anyways depending on your work. The JVM /= Oracle JVM by the way. There is OpenJDK EDIT: Also I think recent Java releases have gotten into making self contain…
> I guess I might ask what this stance is founded on? Kotlin has Kotlin/Native, so I was hoping there might be a similar initiative for Clojure. But, a few reasons: * Startup time * Ability to deploy/share a binary * The JVM just seems so "heavy" to me. It's certainly the only language runtime I know of that runs a persistent helper app, or asks to install an Ask toolbar upon installation. * Bias against Oracle and J…
You can use Graal native image to compile Clojure apps to single binaries. https://www.astrecipes.net/blog/2018/07/20/cmd-line-apps-wit...
There is also a lein (clojure build tool) plugin for this at https://github.com/taylorwood/lein-native-image
Re: Clojure 1.10 release
#59Are there any plans for a native version of Clojure? I'd rather avoid the JVM if possible, but I suppose the whole ecosystem is dependent on it so that's unlikely?
There’s a CLR port if you really just hate the JVM ;) Can do NodeJS with Clojure a’la Clojurescript as well
Is that actively maintained? Last commit on the GitHub repo has been two months ago, and the wiki page was last edited in 2014.
Re: Clojure 1.10 release
#60Earlier quoted context omitted.
> * Bias against Oracle and Java It's always fascinating when I encounter people with opposite biases to my own. While I'm no fan of Oracle, I seek out technologies that are based on the JVM and try to avoid things based on many other technologies because I intrinsically trust certain behaviors and features of the JVM that other ecosystems lack.
After suffering through Java early in my career I've completely avoided it since then. What parts of Java/JVM do you find indispensable vs the rest of tech?
Definitely more the language ecosystem than Java itself - coding in Java itself is painful to me as well. I actually write most of my code in Groovy, some in Kotlin and Scala. But these things keep me liking the JVM -
- maturity of the infrastructure (monitoring, debugging, IDEs, build tooling). I love that I can fire up my debugger and remote attach to a process running on some other host and set a breakpoint for a specific condition to catch a bug. Or that I can do the same to profile memory etc., all with very mature tools.
- very good performance - smack bang inbetween C/C++ and higher level languages (acknowledging that startup time is a big hole in that - but not an important one for me)
- truly cross platform - none of this python style, cross platform except half your packages are really written in C and won't compile unless an entire ecosystem of dependencies is there to support them, and even then some of the flat out don't work on some platforms. This extends deeper than most other languages ie: you can get closer to low level OS features while maintaining 100% cross platform capability.
- strong / static typing under the hood which you can access optionally (eg: languages like Groovy / Kotlin let you write high level code without being burdened too much by the overhead of static typing), but all the Java APIs, ecosystem of libraries are all statically typed so you have good guarantees and excellent documentation.
- deployment behavior - I can run the JVM, give it specified memory footprint and know it's going to stay within that