utxaa

try vscode ;) ~ 5*10^6 java code base, i don't notice any slowness. it would be impossible to do this in emacs.

i don't think that's it. i like scheme, and clojure is not scheme. it may just be that.

if i change anything in filters.scm then i (load "filters.scm") instead of just sending a snippet to the interpreter to eval. i have this happen when i save the file. same thing, except i never have to worry about sending code or a mis-match between editor and repl. it also forces you to be more organized with code so that you don't override global state. i just code, save, code, save. you can have hooks run things after every save etc ...

it's something.

my inkling is that the more special forms the more difficult it is to repl a language. if everything is an expression not only can you eval parts of it, but that is enough to support quite a bit of extensibility sans macro.

or the ridiculous namespace system.

what about the horrible debugging experience?

i've used emacs for 20 years. i still spend 80% of my day in it ... and vscode is vastly superior for development.

i don't love java but no one can argue with the fact that it has fantastic tooling.

properly written java is a joy.

hmmm ... what if it's a closure, and it depends on a huge lexical environment?

In emacs, for instance, you often use `eval-last-sexp`, by default bound to C-x C-e. This lets you move your cursor to a particular point in the file, often deep in a function, and get the results of just the form(s) you're pointing at.

but that depends on how the environment is looking at the time.

during development, in scheme, i just have a function (reset) that reloads all the files of an app. sometimes i create a thread and poll the filesystem and reload everything that changed in the last second. that way i never have to C-x anything. if i need to eval a subexp i just jump on the repl and do it.

i get the magical aspect of repls in scheme and CL. not in clojure. not sure why. so i don't like clojure, but i feel like i should ?? why is that?

what about the current source?

same here. i would say it was a full 2 years before i was free.

i do not want to go through that again though.

isn't this a bit like saying i'm not afraid of being homeless, what i am afraid of is having no where to sleep and keeping warm in cold weather.

i also don't notice any speedup. it was a bit disappointing :)

i use gnus and org-mode heavily. 80% of my day is in one or the other.

i would add that emacs28 w/o compilation feels faster than emacs27.

emacs28 w and wo compilation feel the same.

this is why if you don't enjoy leet puzzles, you don't learn anything, or can't even do them.

hmmm ... good point.

thanks gpm for taking the time. let's see how it pans out. rust is definitely interesting.

now let me not impose on your kindness further and go learn a little rust.

It is clear to me that he is asking for no panics for OOM.

agreed. which is why i'm confused. maybe this is a non-issue that has exploded into an issue :)

thanks.

thank you for this. this helps.

but let's say one is writing a filesystem in rust, so you're implementing most of the functions in "struct file_operations", and moreover you are passing "struct inode" , "struct page" etc ... back and forth between c and rust. with such heavy handed interaction, aren't we basically doing c in rust by necessity of the interface? by which i mean "unsafe" the way you defined it?

are there examples where you see a clear win?

we have good support for "no allocations" and "panic on OOM or return Result on OOM"

so if i understand it correctly, the ability is there by just "returning a result on oom" - linus is just asking for complete assurance that a panic will never happen? like say from a library?

what about interacting with the existing kernel code base? would data coming back from the kernel into rust space need to be wrapped to provide safety guarantees? or would it be necessary to turn safety features off?

a bit confused about this.

oops. corrected. thanks.

my main beef with fossil was performance. but i should clarify that this was 5 years ago or so. so maybe it's ok now.

so stop buying apple. that'll light a match in the right place.

it's not that apples to oranges. op is saying they use sqlite, i'm saying we use edn files. just offering another point of view.

if by out-of-order you mean loading parts of a file, of course we don't do that.

we don't load everything into memory (there's more than one file). just like you wouldn't load your whole sqlite db into memory.

if the machine crashes we lose what we didn't save. same with a db.

  > So basically I can just say the same thing you said with
  > C: "I just fopen/fgetc strings to disk. C is my query
  > language."

the main problem with our approach is that the server needs to have access to the edn files. that's not always doable ... but same problem with sqlite.

and it is oh so nice to investigate stuff in the repl:

  (:prio (load-file (filter #(= "secret-id" (:id %)) index))) 

also ext4 (then 3 i think) used to look for dir entries linearly (it was a linked list of entries).

if this was the case - even if rewriting the inode was O(n) - you would have noticed. try ls on a large directory, now touch a file on same directory.

you can :) even across nfs ... maildir etc ...

one of my team members really pushed fossil, and we did like the integrated wiki/ticket system. not bad at all.

... but it was so slow compared to git! at everything. merging, pushing, pulling ...

you did not experience same?