Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Try Clojure – An interactive tutorial in the browser

tryclojure.org

Post reply on HN
Print view View original

91–96 of 96 posts

Re: Try Clojure – An interactive tutorial in the browser

#91

Post by geokon »

didibus wrote: post #83
geokon wrote: post #60

Earlier quoted context omitted.

rereading the link I guess there are some implementation specifics that are JVM. I'm not really familiar with CLJS to say how those translate - but in principle is sounds like it could work on both platforms

add-libs lets you add Java libraries as well, or Clojure libs that themselves depends on Java libs. So for the JVM you need a JVM specific implementation that can pull Java libs. And when adding pure Clojure libs, you're right, it could be from source directly similar to typing it all into the REPL. For JS, it's a bit more complicated for the Clojure side, because the compiler isn't in the runtime, SCI is interpretin…

Oh okay, I see the distinction. The library would be interpreted and not compiled to JS - and I guess there would be a needless performance penalty. So it wouldn't be of much use outside of this particular scenario.

Nonetheless it seems like something that'd be quite handy for bugreports and sharing code :) One thing I've noticed is that there is friction with writing minimal bugreports/demos/examples. It usually involves making a new repo with a `deps.edn`. Then you gotta push that to github and send a link.. It's all very doable but there is overhead and people don't want to have one off demo repos scattered everywhere for every issues they've responded to on Github. And the people on the other side of the equation don't really wanna pull and execute your mini-repos either. `add-libs` already lets you boil it down to a single file which is great, but having it all in an executable pastebin or forum comment block would mean everyone is seeming the same environment/configuration, same dependencies, same code and the same output.

That said, looking over a few of my projects I do have to admit that pure Clojure dependencies are the minority :)

Dependencies with their own JS or Java dependencies sounds more hairy.. I wasn't even thinking in that direction. I'm sure that's part of why add-libs is still a work in progress

Re: Try Clojure – An interactive tutorial in the browser

#92

Post by gengstrand »

didibus wrote: post #82
gengstrand wrote: post #80

Earlier quoted context omitted.

Most data focused microservices for business applications devote most of their code to calling databases. The PoC microservices that I implemented in order to evaluate Clojure use Java libraries to communicate with Cassandra, MySql, Redis, and Elastic Search. Clojure is not currently at a point in adoption where it makes a lot of sense for these database vendors to support native Clojure libraries. While it is true t…

The reflection lookup takes about 0.04 msecs extra on my laptop. When you're doing things like I/O, an extra 0.04 milliseconds won't matter much, since the operation is already a lot slower then that. So hinting in those case generally isn't really needed, as it won't cause visible performance gains in your application. Where hinting is worth it, is in tight loops where 0.04 ms will add up. Numeric code that uses arr…

Your claim, that the latency cost of reflection is small in comparison to the latency of performing I/O, seems reasonable assuming that the service is processing only one request at a time. That is not the case for typical microservice architectures and certainly not what is happening in the load test by which each of these service implementations are compared.

There is an upper limit of requests to which any service can handle concurrently. Usually, that limit is based on memory but there could be other factors too. After that upper limit is reached, additional requests wait in a queue or get rejected. From Little's Law, we know that the number of requests in any system is the product of the rate of ingress and the average time it takes to service a request. Since that number of requests is bounded, even small increases in the average process time can have a significant negative impact on the ingress rate that the service can sustainable handle. If you are not familiar with queuing theory, then perhaps you have heard of onlooker delay being the major cause of traffic jams.

Is running Clojure services with Java reflection the end of the world? Of course not. Just be aware that it does make performance for those kind of services look not quite as efficient when compared with services that do not use Java reflection.

Re: Try Clojure – An interactive tutorial in the browser

#93

Post by amatecha »

yakshaving_jgt wrote: post #76
joshlemer wrote: post #74

Earlier quoted context omitted.

You may have seen it already but Rich Hickey the creator of Clojure had a great talk about this https://youtu.be/YR5WdGrpoug

I’ve seen a few of his talks, but I do not accept his position on types more generally. I wrote a rebuttal to a similar talk he gave a few years ago. https://jezenthomas.com/rich-hickey-doesnt-know-types/

Huh, good post, thanks. What are you usually working with, Haskell? Or I saw Elm mentioned on your blog. I've been considering learning Clojure as something new to help broaden my skills (currently using TypeScript in my day-to-day and some noob-level knowledge of Haskell). Your post has me reconsidering, haha >_>

Re: Try Clojure – An interactive tutorial in the browser

#94

Post by eyelidlessness »

futharkshill wrote: post #50
eyelidlessness wrote: post #7

Earlier quoted context omitted.

My experience with ClojureScript is you absolutely have to know the host environment because you will encounter type errors and the maintainers have negative interest in making them clear to users (as in flatly refused offers to contribute changes to make those errors easier to understand).

There is nothing worse than library or language maintainers who do not understand that "pure" error messages are absolute hell. If 99.99 % of the time a user should simply write x instead of y, the message should absolutely state that if possible.

Amusingly to me, this is what drove me to TypeScript. “Don’t do that” be damned, I’ll get my useful errors from the compiler.

Re: Try Clojure – An interactive tutorial in the browser

#95

Post by raspasov »

gengstrand wrote: post #92
didibus wrote: post #82

Earlier quoted context omitted.

The reflection lookup takes about 0.04 msecs extra on my laptop. When you're doing things like I/O, an extra 0.04 milliseconds won't matter much, since the operation is already a lot slower then that. So hinting in those case generally isn't really needed, as it won't cause visible performance gains in your application. Where hinting is worth it, is in tight loops where 0.04 ms will add up. Numeric code that uses arr…

Your claim, that the latency cost of reflection is small in comparison to the latency of performing I/O, seems reasonable assuming that the service is processing only one request at a time. That is not the case for typical microservice architectures and certainly not what is happening in the load test by which each of these service implementations are compared. There is an upper limit of requests to which any service…

For sure. YourKit is an excellent piece of software to discover the hot spots in the code that are the bottleneck in such cases. It takes just a few minutes to discover and add the type hints in the proper places.

Re: Try Clojure – An interactive tutorial in the browser

#96

Post by yakshaving_jgt »

amatecha wrote: post #93
yakshaving_jgt wrote: post #76

Earlier quoted context omitted.

I’ve seen a few of his talks, but I do not accept his position on types more generally. I wrote a rebuttal to a similar talk he gave a few years ago. https://jezenthomas.com/rich-hickey-doesnt-know-types/

Huh, good post, thanks. What are you usually working with, Haskell? Or I saw Elm mentioned on your blog. I've been considering learning Clojure as something new to help broaden my skills (currently using TypeScript in my day-to-day and some noob-level knowledge of Haskell). Your post has me reconsidering, haha >_>

Yes, I mostly work with Haskell. I'm the CTO at Supercede and our project is currently ~100,000 lines of Haskell code.

I think every developer ought to at least learn Elm. Being forced to think so lucidly about the types and effects of your systems is unreasonably effective, and I think it shapes the way you then write code in other languages.

Post reply on HN