Live data from Hacker News

Kashmir: A statically typed Lispy language compiling to Go

owickstrom.github.io

71–75 of 75 posts

Re: Kashmir: A statically typed Lispy language compiling to Go

#71
Project renamed to Oden and moved to: https://oden-lang.github.io/oden/

There were a bunch of reasons to change the name and I was going to create a GitHub organization for it anyway. Kashmir was not a good choice for Googleability and it turned out there's some city or region in the Kashmir region called "Golang"... :S

Sorry about the confusion!

Re: Kashmir: A statically typed Lispy language compiling to Go

#72
post #61

Earlier quoted context omitted.

Especially if you just do the compilation to Go and redirect the user to a prefilled play.golang.org page with the resulting code. And a comment withe original code and a link back to your site :)

Pre-filling a page on another domain isn't possible unless the creator of that page explicitly creates a way to do it. That's an important security feature of web browsers.

You can create and run the entire snippet and redirect the user to the resulting page. "Prefilled" was a poor choice of words :(

Re: Kashmir: A statically typed Lispy language compiling to Go

#73
post #32

Earlier quoted context omitted.

Why not?

Well I think its not the best idea to confuse people's perceptions of very important ideas of our existence as humanity, just because it was a cool 2-syllable name found in interest of saving time on Google. Kashmir resonates very strongly and has strong meaning for a significant % of the world's population. Think about coming up with a name like "Crimea" for a language if it has no connection whatsoever. If it does,…

Thanks for the explanation.

My first association was cashmere wool, which is called kashmirvilla (or kašmirvilla depending on orthographic preferences) in my native Finnish.

Re: Kashmir: A statically typed Lispy language compiling to Go

#74

Earlier quoted context omitted.

Javascript would be the assembly language of web i.e. what runs on your browser. Although that won't be true with the advent of Webassembly. Go is language of choice on cloud. If you ask me following is the checklist it passes: 1. Low memory footprint/good GC 2. Concurrency (goroutines) builtin 3. Great dependency (package) management 4. Compiled/closer to bare metal 5. Fast compilation If you check other languages a…

> Go is language of choice on cloud. I don't think this makes any sense. Javascript is the assembly language of the web because it's the only choice for the web (or more specifically, the browser). At best, any other legitimate choice will just compile to JavaScript, which is why it's thusly named. Go has no such privileged position; it's not even clear what it would mean to be the "language of choice on the cloud."…

I agree that that the statements cannot be analogues. But then I never implied it. My answer was only to counter the statement that JavaScript is the assembly language, in future WebAssembly will likely take that role. Then I continued on my intended answer of why Go is the preferred language.

Re: Kashmir: A statically typed Lispy language compiling to Go

#75

Earlier quoted context omitted.

Javascript would be the assembly language of web i.e. what runs on your browser. Although that won't be true with the advent of Webassembly. Go is language of choice on cloud. If you ask me following is the checklist it passes: 1. Low memory footprint/good GC 2. Concurrency (goroutines) builtin 3. Great dependency (package) management 4. Compiled/closer to bare metal 5. Fast compilation If you check other languages a…

> 3. Great dependency (package) management Eh... Then why are people experimenting with vendoring? > If you check other languages against the list they lack at least one of the above. If you feel any other language is better suited please tell. Ocaml checks all of them. So does Haskell (with stack package manager), with only the low memory requirement being challengeable since many aren't used to optimizing lazy eval…

Both languages you suggest require more learning (both have origins in academia) and are less popular compared to Go in usage.

Regarding the package management comment. If it is an experiment let results get in. Some people consider vendoring bad yet others find some use in it. If vendoring happens like it or not it wont make dependency management bad as a whole.

Post reply on HN