btbytes has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
btbytes has joined #ocaml
ousado has quit [Ping timeout: 240 seconds]
btbytes has quit [Client Quit]
dtornabene has quit [Quit: Leaving]
ousado has joined #ocaml
zolk3ri has quit [Remote host closed the connection]
Jesin has joined #ocaml
rostero_ has quit [Quit: Connection closed for inactivity]
zv has quit [Ping timeout: 240 seconds]
btbytes has joined #ocaml
btbytes has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
btbytes has joined #ocaml
btbytes has quit [Client Quit]
zv has joined #ocaml
silver has quit [Read error: Connection reset by peer]
FreeBirdLjj has joined #ocaml
donviszneki has quit [Ping timeout: 240 seconds]
tormen has joined #ocaml
FreeBirdLjj has quit [Remote host closed the connection]
tormen_ has quit [Ping timeout: 265 seconds]
cbot has joined #ocaml
Algebr has joined #ocaml
mfp has quit [Ping timeout: 240 seconds]
ygrek has quit [Ping timeout: 276 seconds]
al-damiri has quit [Quit: Connection closed for inactivity]
pierpa has quit [Quit: Page closed]
Jesin has quit [Quit: Leaving]
pierpal has quit [Read error: Connection reset by peer]
pierpal has joined #ocaml
jao has quit [Ping timeout: 245 seconds]
pierpal has quit [Read error: Connection reset by peer]
btbytes has joined #ocaml
jbrown has quit [Ping timeout: 264 seconds]
sz0 has quit [Quit: Connection closed for inactivity]
shinnya has quit [Ping timeout: 248 seconds]
tarptaeya has joined #ocaml
cbot has quit [Quit: Leaving]
spew has quit [Quit: Connection closed for inactivity]
btbytes has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mbuf has joined #ocaml
malina has joined #ocaml
MercurialAlchemi has joined #ocaml
mfiano has joined #ocaml
<mfiano>
Is there an OCaml newbie channel?
keep_learning has joined #ocaml
Algebr has quit [Ping timeout: 255 seconds]
mbuf has quit [Remote host closed the connection]
mbuf has joined #ocaml
<Enjolras>
mfiano: this channel is for everyone. There might be one on discord, but on IRC i don't think so
<mfiano>
Thanks. I was just interested in learning OCaml, but I'm not sure what it has to offer over my current language of choice.
<Enjolras>
I guess it depends what is your current language of choice
<mfiano>
That would be Common Lisp.
<Enjolras>
Ok, i don't know any lisp like language.
<Enjolras>
The strength of ocaml imo are its expressive yet flexible type system which allows for good static typing of critical code while still having easy to write code
<Enjolras>
A very good module + functor system which is a very good way to organise code into small abstracted compenent with clear interface that you can assemble together
nopf has quit [Remote host closed the connection]
<mfiano>
Does it have meta-programming capabilities like macros, or generic functions for runtime dispatching based on types?
<Enjolras>
and a ralitively "no bullshit" wiew of functional programming with access to easy mutability and side effect for when you need them
<Enjolras>
meta-programming, yes and no. It's probably not as easy as lisp
profan has quit [Ping timeout: 260 seconds]
<Enjolras>
there is ppx, which are syntaxic macros, but it's heavy and not something you want to write often
<Enjolras>
it's basically transformation from AST to AST but the ast is not lisp it's more complex
<mfiano>
Also does the GC get in the way for real-time sensitive applications? I'm currently a 3D game developer with Lisp, so while we're at it, how is the ecosystem around this area?
<Enjolras>
there are also more experimental meta programming project like metaocaml, which is really really nice but not upstreamed
<Enjolras>
I don't do game programing i don't know much. The GC is quite good for latency, it's probably not the best around here but it's definitely not the worst
<Enjolras>
there has been various study about thsi
<gonz_>
mfiano: Macros for OCaml are baby level, you'll not find that they measure up very well with what you're used to. Fortunately it's not as if you really need them that much with OCaml.
<Enjolras>
and runtime dispatching based on types : this is a static language, so no
<Enjolras>
(while you can emulate such things)
<Enjolras>
but probably you want to do it another way, like with enum types
<Enjolras>
gonz_: you should try metaocaml though :)
<mfiano>
I see. I'm sort of too blinded by Lisp so I don't know the proper generic terminology, but is there anything like Julia, where types are given, yet you can have the same function API perform different functionality based on what you pass to it?
pzp has joined #ocaml
<Enjolras>
ocaml does not really support ad-hoc polymorphism like Haskell/rust/C++ if that's what you are asking
<gonz_>
Enjolras: Functors would satisfy what he's talking about though
<mfiano>
parametric polymorphism is what i mean i think after a quick google
<Enjolras>
gonz_: yes, although it's not directly that
<Enjolras>
i mean this is not the natural way of doing things in ocaml
<gonz_>
mfiano: Haskell with type classes is a very lightweight way of doing this, where you specialize the behavior of a common function to a type
<gonz_>
In OCaml it's slightly more verbose and not quite as convenient, but you can get the same effect with a bit more work
<mfiano>
I guess I should find a book to read about the OCaml way of writing expressive code.
<mfiano>
I haven't touched Haskell or an ML before.
<gonz_>
Personally I wouldn't recommend anyone go with OCaml nowadays
<gonz_>
But you have requirements that make more sense for OCaml rather than Haskell
<gonz_>
Without the extreme perf requirement OCaml really is a pretty wooden language
<gonz_>
Haskell is better, more modern and the only thing it has going against it is this pervasive myth of being hard to use
<mfiano>
I have a few requirements, probably none of which could be met collectively by a single language.
donviszneki has joined #ocaml
<gonz_>
OCaml has a few things that seem to never actually reach the language and everyone keeps talking about them coming "soon". This has gone on for 5+ years or something now.
<gonz_>
Without those it stays firmly in the beginning of the 2000's, IMO
<gonz_>
Whereas Haskell is already leaving the 2020's
Algebr has joined #ocaml
<mfiano>
I want to learn a static language. I don't want to use C. I want it to be fast, concise (sorry Rust), and expressive without a bunch of strange syntax and using every bit of ASCII (sorry Haskell). and I want a decent library ecosystem. Probably too much to ask, I know.
<gonz_>
OCaml makes a lot of sense with BuckleScript, though, because the lack of multicore doesn't matter when you compile to JavaScript and it still covers a pretty wide area, so it's generally speaking an extremely good way to write web apps.
<mfiano>
I read haskellbook, and I just couldn't adapt to it.
<Enjolras>
gonz_: haskell community is more concerned about writing the most complicated libs ever create than getting things done though :>
<Enjolras>
i would not recommand using haskell for this reason
<gonz_>
Enjolras: That's just false
<gonz_>
Haskell has more practical libraries (more libraries in general as well) than OCaml
<gonz_>
And the language has more practical features than OCaml as well
<gonz_>
In general, it's vastly more ergonomic both as a language and eco-system than OCaml is
Algebr has quit [Ping timeout: 260 seconds]
<Enjolras>
...
<mfiano>
Heh, the last thing I expected was to join a language channel and be persuaded not to try it because it's stuck in the past.
wordchat has joined #ocaml
<Enjolras>
Haskell is The One True Language and every person using any other language is silly, it's a well know fact...
<Enjolras>
mfiano: if you have more specific questions, eg on ecosystem for 3D stuffs etc, it might be easier to ask on https://discuss.ocaml.org/ for less immediate feedback
profan has joined #ocaml
Algebr has joined #ocaml
<gonz_>
Enjolras: I use OCaml, I just don't pretend it's a modern programming language. I started out with OCaml instead of Haskell because of the same lore you brought up, but I realized it's actually easier to use in practice eventually.
Algebr has quit [Ping timeout: 260 seconds]
Algebr has joined #ocaml
dejanr has quit [Ping timeout: 245 seconds]
dejanr has joined #ocaml
Algebr has quit [Ping timeout: 276 seconds]
donviszneki has quit [Ping timeout: 256 seconds]
Haudegen has joined #ocaml
Algebr has joined #ocaml
Algebr is now known as Guest87418
Guest87418 has quit [Ping timeout: 240 seconds]
caltelt_ has quit [Ping timeout: 248 seconds]
argent_smith has joined #ocaml
pzp has quit [Quit: Connection closed for inactivity]
gareppa has joined #ocaml
gareppa has quit [Remote host closed the connection]
Guest87418 has joined #ocaml
shinnya has joined #ocaml
Guest87418 has quit [Ping timeout: 276 seconds]
mk9 has joined #ocaml
mbuf has quit [Remote host closed the connection]
mbuf has joined #ocaml
mk9 has quit [Quit: mk9]
dakk has joined #ocaml
mk9 has joined #ocaml
Guest87418 has joined #ocaml
mk9 has quit [Quit: mk9]
Guest87418 has quit [Ping timeout: 276 seconds]
donviszneki has joined #ocaml
donviszneki has quit [Ping timeout: 240 seconds]
TarVanimelde has joined #ocaml
mk9 has joined #ocaml
mk9 has quit [Quit: mk9]
Guest87418 has joined #ocaml
Guest87418 has quit [Ping timeout: 276 seconds]
mfp has joined #ocaml
<Fardale>
gonz_: what make you say that OCaml is not a modern programming language ?
zolk3ri has joined #ocaml
halogenandtoast has quit [Quit: leaving]
<ZirconiumX>
Honestly, this kind of argument reminds me of Go, and I think OCaml shares a reasonable amount of philosophy with Go, in that they're fairly pragmatic languages.
<ZirconiumX>
Granted, OCaml's stdlib doesn't hold a candle to Go's, but opam helps work around that.
<Armael>
wat...
* reynir
grabs popcorn
* ZirconiumX
sighs
<steenuil>
not having typeclasses does not make it qualify as "not modern" IMO, especially since you can almost get them with functors
donviszneki has joined #ocaml
dhil has joined #ocaml
<discord3>
<Christophe> ZirconiumX: you mean that people say that Go is not a modern programming language?
<ZirconiumX>
I've seen people argue that. I don't agree, though, because it's a very clean and elegant language.
<ZirconiumX>
But, for example, "Go Is Not Good" argues that
Guest87418 has joined #ocaml
donviszneki has quit [Ping timeout: 276 seconds]
Guest87418 has quit [Ping timeout: 276 seconds]
<Drup>
Well, it would have been a satisfyingly modern language 30 years ago.
mbuf has quit [Remote host closed the connection]
mbuf has joined #ocaml
TarVanimelde has quit [Quit: TarVanimelde]
<ZirconiumX>
If you'd given people in the 90's an alternative to using scripting languages for web, with native encryption and HTTPS, the web would be a very different place.
<dreamer>
hmm, after x hours I find my LS instance as 'Killed'
<dreamer>
woops, wrong chan. sorry
dreamer has left #ocaml [#ocaml]
<ZirconiumX>
I don't think he needed to leave
<steenuil>
Go's standard library is very much modern; Go itself isn't very much
<ZirconiumX>
True, yeah.
sagotch has joined #ocaml
<bartholin>
Common Lisp is a modern programming language.
freyr69 has joined #ocaml
ziyourenxiang has joined #ocaml
lobo has quit [Ping timeout: 245 seconds]
lobo has joined #ocaml
tarptaeya has quit [Ping timeout: 264 seconds]
<freyr69>
Are there any plans on adding option to basic format strings?
<Drup>
freyr69: you mean, like `"%a" Fmt.(option foo) x` ? :)
dhil has quit [Ping timeout: 240 seconds]
Haudegen has quit [Remote host closed the connection]
<freyr69>
More like part of the format
<freyr69>
It would be quite convenient to use format as a Sql query constructor param
<freyr69>
Although I still need to specify the result type, so maybe it is not a good idea anyway, and I have to stick to ppx
<Drup>
Yeah, it's not a great idea :)
<discord3>
<Christophe> About the "modern language" claim, I guess I mostly don't understand what it's supposed to mean. I guess it could mean "suitable for modern use-cases" but I don't see what it means for a language, I can see only for libraries
<discord3>
<Christophe> also the tooling, but again, not the language itself
<def`>
A language that implements recent results from PL research?
<def`>
that implements ONLY*, otherwise Coq and OCaml would qualify too :P
dhil has joined #ocaml
<Drup>
Well, at least PL research ideas from the last 30 years, not even recent ones.
Guest87418 has joined #ocaml
<bartholin>
iirc the only recent idea is the univalence axiom
<Drup>
bartholin: No.
<bartholin>
( ͡° ͜ʖ ͡°)
<discord3>
<Christophe> No offense but sometimes I feel that it is expected of ocamlers to have strong knowledge of theory, I had the same feeling yesterday when I asked about complexity and was told simply "best complexity for the data structure". My question was genuine not a sassy way to say "I don't believe there is such thing as a modern language". I'm just not aware of the state of research 30 years ago nor recently.
Guest87418 has quit [Ping timeout: 260 seconds]
<flux[m]>
eons ago, when I started learning OCaml, I also wondering how the complexity of each function wasn't documented. Probably the response was similar to that ;-).
<Drup>
Christophe: You don't need to. You have the right to like Go, or find it a decent language. But language designer should know better
<flux[m]>
andI still like how C++ documentation specifies the complexity - even if it is to be expected
<discord3>
<Christophe> Of course, my question was about OCaml, what would be missing to make it modern :)
<Drup>
and the Go language designer explicitely said he find the PL community to do shit, and proceed by designing a language that has all the shortcomings of language designed in the 90s.
<Armael>
but it is modern
<nicoo>
flux[m]: Yes, I agree the documentation should specify average and worst-case time- and space-complexities; I suspect it's mostly a matter of someone doing it and sending a pull request (or at least opening a bug)
<discord3>
<Christophe> Especially, the lead developer in the company I work in is infatuated with Go. I plan on making a strong case for OCaml, so I want to understand all the strengths and weaknesses of both :)
<discord3>
<Christophe> Opening a bug, that I can :D
<dmbaturin_>
Christophe: I still can't get to writing a thorough "Go considered harmful" article. :)
<dmbaturin_>
Note that the biggest issue with HTTP until some point was that it _required_ a dedicated address, which was clearly incompatible with virtual hosts.
<freyr69>
While Golang is quite ridiculous, it's hard to recommend OCaml as a golang replacement since OCaml has no shared memory parallelism support
<bartholin>
^
<Enjolras>
imo, sared memory parallelism is over rated and something from the past
<freyr69>
And haskell is way too cumbersome
<freyr69>
And Scala is scala
<flux[m]>
that being said maybe some "guestimator" would be feasible. Ie. if you call List.iter (..) x, then your function is at least O(n), if x is your input.
<Enjolras>
it has niche usacase and unless you are writing desktop apps like games, which is not the strengh of golang either
<freyr69>
So everybody write Java and Go
<Enjolras>
you don't need shared memory parallelism. Actually you're better without
jao has joined #ocaml
<flux[m]>
but I suppose it easily breaks if you write algorithms yourself to the code. so perhaps it would not be useful really.
<dmbaturin_>
nicoo: ZirconiumX's claim wat about 90's web. Even if SNI worked in 2003 (I don't remember), it still disproves the claim as stated. :)
<dmbaturin_>
* was
<nicoo>
dmbaturin_: Oh, sorry, I missed that bit of context; IPv4 was plentyful in the 90s, though :þ
<Enjolras>
the reasons it's hard to recommand ocaml compare too go are more like lack of good http implementtion
<dmbaturin_>
nicoo: Yeah, but virtualization was only only common on mainframes and dedicated servers were even more expensive than now.
<freyr69>
Enjolras: yeah, or multimedia app, or literally anything beyond simple web
<Enjolras>
freyr69: anything running on a desktop basically, but nothing running on a server
<Enjolras>
flux[m]: nicoo i actually don't know how hard it is, i just know some people are working on prototypes like this
<Enjolras>
but day to day, i think you only care about < linear, linear >= quadratic
* bartholin
asks Santa Claus for a purely functional language with support for inductive types, concurrency, parallelism, cubical type theory, objects, classes, subtyping, dependent types, inline assembly code, a Python-like standard library, reflection, language extension (macros), type classes and chemical programming (as in the gamma-calculus).
<discord3>
<Christophe> We do web and mobile services,, I'm quite confident that OCaml would do well for the backend, except for lack of HTTP/2 amd gRPC
* bartholin
forgot linear types
<Enjolras>
Christophe: gRPC and HTTP/2 are basically the same thing as protobuf is supported. But the lack of HTTP/2 is definitly an annoyance
<discord3>
<Christophe> yeah I'm aware the problem is linked, I meant it as teo desireable technologies 😃
<discord3>
<Christophe> *two
Haudegen has joined #ocaml
<discord3>
<Christophe> throw in that the front-end guys do a lot of react/react-native and with bucklescript I could try to convince them also to do OCaml 😄
mengu has joined #ocaml
<discord3>
<Christophe> but mostly, I want to opt out from python, and Go is not that tempting
<flux[m]>
recently I've been writing python at work, and it's tolerable with mypy. buuut so much worse typing than OCaml ;-).
<Enjolras>
Christophe: it's perfectly hackable to put an http1.0 endpoint in ocaml behind nginx
<flux[m]>
out of go and python with mypy.. I might go with mypy. it has polymorphic types!
<Enjolras>
sure you loose some performance, but performance per core of an http sever in ocaml is quite acceptabke
<Enjolras>
and the latency of tcp connect in the DC on a gigabit network is negligible in the response time
<Enjolras>
like sub millisecond
<Drup>
Is implementing http2 (on top of httpaf, I suppose) really that much work ?
<Enjolras>
Drup: i guess it depends how used to this kind of SPEC reading exercise you are
<Enjolras>
you need to implement HPACK compression algo too
<Enjolras>
and handle the message format
<freyr69>
Ah, httpaf)
<Enjolras>
on top of that, need to implement the state machine which is quite different from HTTP/1.0
<Enjolras>
tbh i've no idea how hard it is, but it looks harder than what i can do tackle on my free time
<freyr69>
I like how diverse OCaml ecosystem is without any reason)
<freyr69>
And some of them are pretty the same, like cstruct and bigstringaf
<Enjolras>
Drup: it's probably much easier than dinosaure[s] projects as HTTP/2 is modern and sanely design
<Enjolras>
but it's not a one weekend project
<Drup>
Well, dinosaure, you know what to do
<Enjolras>
that's not what i meant
<Drup>
:D
<Enjolras>
%)
<discord3>
<Christophe> what is the "af" suffix by the way ? I keep reading it "as fuck" and I'd love to get rid of that ^^'
<Drup>
freyr69: some of them have good reasons
<nicoo>
dmbaturin_: You don't need VMs or extra hardware to use multiple IPs. Back then it was common to have multiple IPs going to the same host and have the httpd do “virtual hosts” based on the destination IP
gtrak has joined #ocaml
<Drup>
Christophe: I have a disappointing news for you. :3
mbuf has quit [Quit: Leaving]
<discord3>
<Christophe> Dont's tell me I'm reading it right XD
<dmbaturin_>
nicoo: I know. How many 90's or early 00's hosters actually gave customers multiple IPs though? :)
<freyr69>
Christophe: Angstrom and Faraday it seems
<discord3>
<Christophe> o/ thank you !
<Drup>
freyr69: in particular, except lwt/async; they are all re-engineering of libraries that were not satisfying, either API or performance-wise
pierpal has joined #ocaml
<Drup>
Christophe: That's a poor pretext though :p
<discord3>
<Christophe> isn't also Async there because JaneStreet needed more control over the evaluation of deferred ?
<Enjolras>
to say the least.
Denommus has quit [Ping timeout: 248 seconds]
<Enjolras>
Async and Lwt where almost developped in parallel and Async was not opensource back then as far as i know
<Enjolras>
that's a special case
<discord3>
<Christophe> ah ok 😃
<freyr69>
Cohttp people said that cohttp just needs more love, there is nothing inherently broken about it
spew has joined #ocaml
<freyr69>
Drup: And what is wrong about cstruct?
<freyr69>
It's just { buf; off; len }
<freyr69>
And bigstringaf is...
<Enjolras>
i remember when async was released. They created an opensource website, put some code with 0 doc on it, with a shiny webpage
<freyr69>
{ buf; off; len }
<Enjolras>
and a lot of people were like "who the hell is janestreet ?"
<Drup>
freyr69: Haven't looked at that one :)
<freyr69>
BTW unison still uses it's own original lwt
<freyr69>
probably because no one gives a shit
<Enjolras>
modern people use dropbox or gougle drive
<Enjolras>
who cares about unison
<freyr69>
I care, it's better than either
Guest87418 has joined #ocaml
<flux[m]>
why would unison switch?
<flux[m]>
if it works.. :)
<freyr69>
Well, they have to maintain it
<flux[m]>
I think that work is quite minimal. it probably works after all these years.
gtrak has quit [Ping timeout: 245 seconds]
<Drup>
You are assuming that code written by Jérôme has bugs in it, I'm not sure that is correct :D
gtrak has joined #ocaml
<dmbaturin_>
Given it was originally an academic project, say thanks they didn't make their own ML for it. ;)
<dmbaturin_>
(Like certain web framework)
<Drup>
Lwt? It was part of ocsigen, so they kind of did.
Guest87418 has quit [Ping timeout: 255 seconds]
<dmbaturin_>
Drup: No, I'm talking about Unison having its own Lwt.
<dmbaturin_>
And by the certain web framework I mean urweb.
<dmbaturin_>
(Nothing against urweb per se)
<Drup>
Ah, ML the language, not Mailing List nor Machine Learning.
<nicoo>
flux[m]: IIRC, Unison also still uses Marshal, which means that using it across architectures or compiler versions is impossible; I would assume it's just minimally maintained, rather than “it is a good idea to have it that way”
<flux[m]>
yes, I've noticed that as well :). but I think the problem has almost handled itself by now, 32-bit platforms are becoming more rare.
<nicoo>
dmbaturin_: Unison predates Lwt, but I think it's very much unfair to describe all software made by academics as “an academic project”.
<flux[m]>
and pulling out marshal would probably be painful; doubly so if one wanted to maintain compatibility
<nicoo>
It's very much not a research project
<nicoo>
Do people call LLVM “an academic project” ?
<flux[m]>
similarly I had problem handling large directories with a 32-bit machine due to 16M string length limit.. no longer.
mbuf has joined #ocaml
ratschance has joined #ocaml
<dmbaturin_>
nicoo: I didn't know Unison predates Lwt to be fair. Regardless, the tendency does exist — I'm not saying it's always bad to roll your or it's never a valid choice. "The industry" has the opposite trend of using ready to use libraries no matter how much impedance matching it needs, I don't entirely approve of it either.
<dmbaturin_>
flux[m]: Marshal is used for sending data to the remote side?
<flux[m]>
yes
<dmbaturin_>
Maybe some magic cookie for protocol versioning might help. I haven't looked into unison's internals to be fair.
<dmbaturin_>
It's a very nice software though.
cryptocat1094 has joined #ocaml
neatonk has joined #ocaml
wilfredh has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 255 seconds]
mengu has quit [Remote host closed the connection]
mengu has joined #ocaml
mengu has quit [Ping timeout: 245 seconds]
al-damiri has joined #ocaml
wilfredh has joined #ocaml
<bartholin>
Is there a way to use 64-bits integers by default? For instance, I want that if I type 42;;, then the interpreter tells me 42 : int64.
<companion_cube>
nope
<companion_cube>
you can type 42L
<ZirconiumX>
You can use `42L`, bartholin.
<ZirconiumX>
It's not quite as convenient though
<bartholin>
ok
<ZirconiumX>
Note than int64 is slower than int
<bartholin>
Why?
<bartholin>
(if my machine is natively 64 bits)
<Armael>
"int64"s are boxed, "int"s are unboxed 63 bits integers
<Armael>
(on a 64bits architecture)
<ZirconiumX>
Or 31 bits on a 32-bit architecture
<ZirconiumX>
It uses the least significant bit to test for pointer/int
larhat has joined #ocaml
gargawel has quit [Quit: leaving]
gargawel has joined #ocaml
Haudegen has joined #ocaml
nephanth has joined #ocaml
Haudegen has quit [Ping timeout: 256 seconds]
Haudegen has joined #ocaml
ziyourenxiang has quit [Ping timeout: 264 seconds]
malina has quit [Ping timeout: 248 seconds]
SomeDamnBody has quit [Ping timeout: 268 seconds]
twopoint718 has joined #ocaml
dakk has quit [Remote host closed the connection]
wilfredh has quit [Ping timeout: 265 seconds]
jao has quit [Ping timeout: 264 seconds]
troydm has quit [Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset]
gareppa has quit [Remote host closed the connection]
troydm has joined #ocaml
pierpal has quit [Quit: Poof]
pierpal has joined #ocaml
pierpal has quit [Client Quit]
pierpal has joined #ocaml
<dinosaure>
Enjolras: Drup: may be one day in another life I will implement HTTP2 :D
<Drup>
Come on, the (OCaml) world need you
<Drup>
After doing all those shitty RFC and serialization weirdness, you're ready!
<dinosaure>
if I have a time, probably, but I think Anil has already some plans about that
dhil has quit [Ping timeout: 240 seconds]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
freyr69 has joined #ocaml
SomeDamnBody has joined #ocaml
larhat has quit [Quit: Leaving.]
nephanth has joined #ocaml
MercurialAlchemi has joined #ocaml
dhil has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 260 seconds]
jack5638 has quit [Ping timeout: 240 seconds]
gareppa has joined #ocaml
gareppa has quit [Remote host closed the connection]
gareppa has joined #ocaml
isd has joined #ocaml
MercurialAlchemi has joined #ocaml
jack5638 has joined #ocaml
gareppa has quit [Remote host closed the connection]
gareppa has joined #ocaml
nephanth has quit [Ping timeout: 264 seconds]
jnavila has joined #ocaml
gareppa has quit [Quit: Leaving]
ygrek has joined #ocaml
Denommus has joined #ocaml
gareppa has joined #ocaml
<Armael>
Well Anil already has plans for smart houses running ocaml on mars
<Armael>
(and I wish I was kidding)
donviszneki has quit [Ping timeout: 264 seconds]
malina has quit [Ping timeout: 248 seconds]
gareppa has quit [Remote host closed the connection]
erwounn has joined #ocaml
donviszneki has joined #ocaml
roygbiv has joined #ocaml
<mfiano>
Thanks for the input guys. I'm still unsure if ocaml brings anything new to the table for me
<companion_cube>
compared to what?
<mfiano>
Common Lisp
<companion_cube>
ah, ok. depends on how much you like types!
<mfiano>
Well, I'm not sure.
<mfiano>
I care more about getting things done with a flexible and expressive language that doesn't have a lot of noisy syntax, and one that is fast for real-time applications, and doesn't hurt to have a large library ecosystem.
<mfiano>
That's what I've been working with for about 15 years anyway. But I'd like to learn something new
<companion_cube>
thinking in OCaml after 15y of CL would be a change in perspective, for sure :D
jao has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 265 seconds]
<cryptocat1094>
Fast but with a friendly syntax leaves me with little in mind besides Ocaml and Nim. I'd argue the latter has a larger library set if one considers near-seamless integration with C libraries as C libs being part of the ecosystem.
<companion_cube>
not sure if nim is as… robust as OCaml
<cryptocat1094>
Me neither.
<Drup>
At least from a type-system person, Nim fill as a bunch of metal scraped fixed together with ducktape
<Drup>
+point of view
<Drup>
feel*
<companion_cube>
still better than Go :°
<cryptocat1094>
Well, I'd have said Rust, but they said "doesn't have a lot of noisy syntax".
<Drup>
(Note that I didn't say it didn't work, just that it didn't felt like something particularly though out in a principled way)
<cryptocat1094>
(It's also not all that user-friendly)
<cryptocat1094>
Go is... what it is.
<cryptocat1094>
:p
k1000 has joined #ocaml
k1000 has quit [Client Quit]
<mfiano>
I've tried Rust. I found myself fighting with the borrow system more than actually coding
<mfiano>
Also yeah...noisy
k1000 has joined #ocaml
k1000 has quit [Client Quit]
<cryptocat1094>
The borrow system takes some effort to learn. Though it's about as nice as you get get without GC while remaining safe.
<cryptocat1094>
Mind, that's because I prefer it to C++'s way.
<cryptocat1094>
You also can't enforce mandatory RAII in C++, but that's besides the point.
<mfiano>
Nothing is scary about a GC in Lisp. We have implementations that can be as fast as C in some applications.
Haudegen has quit [Read error: Connection reset by peer]
<companion_cube>
"in some applications" is the critical part, I think
<companion_cube>
I doubt anyone could write a competitive web browser in CL (or in OCaml)
tarptaeya has quit [Quit: Konversation terminated!]
<cryptocat1094>
Right tools for the right job & so on. And when the job doesn't mandate the best tools, then whatever you happen to think is fun.
<mfiano>
depends what you mean by competitive, but web browsers have been done, as have complete and modern 3D games
<cryptocat1094>
3D games tend to exploit FFI goodness a lot.
<mfiano>
Not really. Only a handful of calls are needed. Most of the work is math on the cpu and the gpu. You actually try to minimize the OpenGL state calls, and thus FFI, entirely, because cpu->gpu is SLOW
<zolk3ri>
cryptocat1094: what about zig?
<zolk3ri>
ever looked at it?
<cryptocat1094>
zolk3ri: I haven't personally. I heard a friend express interest but that's about it.
<companion_cube>
zig isn't safer than C++, is it?
cryptocat1094 has quit [Quit: gtg]
tane has quit [Quit: Leaving]
<freyr69>
Why can't you write a web browser in OCaml or CL? C# feels pretty fine in this niche
<isd>
fwiw, firefox is *mostly* written in JS
<Armael>
uh
<isd>
Obviously there are some bits that you can't do that with
<companion_cube>
well, the engine is the interesting part I was thinking of
<companion_cube>
I should have been more accurate
<isd>
:P
<isd>
that was kinda my point -- it's easy for us to ignore all of the "boring" parts that make up the vast majority of the code
<companion_cube>
well the glue can be written in anything, indeed
<companion_cube>
the performance sensitive parts… less so
<isd>
At a certain point you at least need a non-garbage collected language to write your garbage collector in.
pierpa has joined #ocaml
<isd>
You also still need to identify what your actual performance concerns are. Using a low-level language like C, C++, Rust, or Zig isn't just a magic "now everything is fast without me doing anything" -- quite the opposite; if you try to write idiomatic OCaml in one of those it will be slow as molasses.
<isd>
They're known for their speed because if you're working in them you're spending a bunch of time fussing about low-level details.
<isd>
OCaml doesn't seem like a bad language to write a JIT in, by any means.
<isd>
And most rendering probably belongs on the GPU...
freyr69 has quit [Remote host closed the connection]
<discord3>
<Perry> Lisp vs. OCaml: I've worked in both, and I've done a lot of systems programming.
<discord3>
<Perry> 1: in spite of claims for fast garbage collectors, It is still the case that languages like Rust will be used into the far future for things like OS kernels.
<companion_cube>
isd: sure, but if you want performance and you know a bit how it works, rust should take your further than OCaml
<discord3>
<Perry> 2: I'm an insane Lisp devotee, but I've become converted to strong types. It makes programming easier and faster when the tools check your code so thoroughly for correctness in advance.
<discord3>
<Perry> (Credentials: I started with maclisp. Not lisp for the macintosh, MIT Project MAC's lisp implementation, which I used on the DECSYSTEM-20 35 years ago or so.)
<isd>
Yeah, OS kernels are kinda *the* systems language use case.
<discord3>
<Perry> Also things "like" kernels. If things need crazy performance, you want to use a language like Rust. (A few years ago I'd say a language like C.) That includes crazy performance video games btw.
<isd>
But with a browser I wonder. Do you gain as much back in perf for memory layout control as you lose in time spent making the JIT smarter? Hard to know.
<companion_cube>
for rendering, I think so
Guest94047 has joined #ocaml
<isd>
But this is also why I brought up the "it's mostly JS" thing. low-level languages are really good at what they do, but the firefox approach of only using that for the bits of the application that actually need it seems like a good one.
<companion_cube>
(wait, isd, not sure I follow — both rendering and the JS JIT are costly things you need to do
<discord3>
<Perry> BTW, one thing Common Lisp does for you that OCaml doesn't, but which doesn't matter: far more attention payed to things like the floating point library. It doesn't matter because no one trying to do stuff like HPC would use either language.
<companion_cube>
the FP side of OCaml isn't actually that bad, if you use bigarrays (and you should)
<discord3>
<Perry> I also have a hat (which I haven't worn in some years) where I used to do high performance molecular simulations that ate CPUs. You need a language like C or Rust for that. Why? Because you need the performance (really, you do). Also, OCaml doesn't give you sufficient control, you can't pick normal vs. double vs. extended precision reals when you need them.
<isd>
companion_cube: my latter comment was more in response to discord3's. I'm definitely not saying there's no use case where you really *need* a language like that.
<companion_cube>
sure, and many applications can mix a system language with something higher-level
mikeyhc has quit [Ping timeout: 240 seconds]
mikeyhc has joined #ocaml
<discord3>
<Perry> All this said: most software doesn't require performance, which is why things like Ruby and Python (and once Perl) have been so popular. OCaml is far far nicer than any of those and performs pretty damned well compared to them too.
<isd>
But, re JITs: I'm not convinced OCaml is "too slow" there, and I think the boost in help you get re: correctness and productivity could potentially make up for that in gains made to the output.
Guest94047 is now known as Haudegen
<companion_cube>
hopefully rust also has the gain in correctness
<companion_cube>
(productivity, probably not so much)
<isd>
Yeah, I think it's more lacking on the latter.
<discord3>
<Perry> Rust is a lot more productive than C.
<companion_cube>
that's not hard ^_^'
<discord3>
<Perry> But remember, the competition is C and C++.
<discord3>
<Perry> Not OCaml.
<isd>
Eh, well that's kinda the debate.
<discord3>
<Perry> There are dark horses out there as well like Swift, but I think Rust is better in that space.
<isd>
I see rails style web frameworks being developed in Rust, and I'm like, really?
<discord3>
<Perry> Some people do web stuff in C.
<discord3>
<Perry> There's a need sometimes. Not all the time, but sometimes.
<isd>
*Sigh* yeah, they do...
jnavila has quit [Remote host closed the connection]
<discord3>
<Perry> And I'd rather do web stuff in Rust than in Java and I have plenty of clients who do web stuff in Java.
<discord3>
<Perry> (Java is frankly just mediocre at everything. It's never bad, and it's also never actually good.)
<ZirconiumX>
On the other hand you don't get things like the Wat talk in Java
tokomak has quit [Ping timeout: 245 seconds]
<discord3>
<Perry> Java has a lot of Wat, it's just not that sort of Wat.
<isd>
Eh, it has some pretty horrible design mistakes. But half of them are inherited rather than being original, and the other actually require a bit of background to not trip over.
<discord3>
<Perry> Inherited design mistakes are reasonable in Java given that it's object oriented. 😉
<isd>
e.g. the covariant array mixup
<companion_cube>
kotlin looks much better than java
<isd>
Like, it's a standard gotcha with subtyping, but back when I was the TA for a data structures course, I saw students trip over that one special purposes "oops we messed up our type theory" runtime exception fairly often.
<isd>
Yeah, having poked at Kotlin a bit it seems to be "let's fix java as much as we can without making calling java libraries feel wrong"
<companion_cube>
exactly
<companion_cube>
whch is a pretty good design goal, I think
<companion_cube>
in particular the nullability thing
<isd>
Yeah. Given that I think they did a great job. I still personally wouldn't be likely use it if I didn't otherwise need the java ecosystem, but it's not bad.
<isd>
Speaking of inherited design mistakes, I really wish Rust had borrowed less syntax from C++.
<companion_cube>
like what?
<isd>
(I suppose it's high praise that that's one of my biggest complaints about the language)
<isd>
I think . is a better choice for a namespace operator.
<isd>
I don't actually think it would muddy much of anything to just use it.
<companion_cube>
honeslty I wouldn't swear it works, even in the syntax
<companion_cube>
might make things ambiguous
<isd>
And my right pinky is weak because I broke that hand a few years ago. typing :: all the time is actually somewhat painful after a while.
<isd>
I wouldn't count on being able to swap it into the language now as-is and have it just work.
mfiano has left #ocaml ["WeeChat 2.0.1"]
<isd>
But I don't think there would have been any real difficult design questions in using it.
<isd>
I could see an argument for having a different operator -- but one that requires repeated key-presses with the weakest fingers on the hands (both of them)...
<companion_cube>
but think of the turbofish opeerator :p
<isd>
But I don't think there's really any problem using the same notation for field access and namespace operator
<isd>
and in rust "method call syntax" is really namespacing anyway.
<companion_cube>
hmm, not really? there's some dispatch on type going on
<isd>
on the type though, not the value.
<isd>
so yeah, you can argue that's different than namespacing.
<isd>
but it is just disambiguating names, ultimately.
<companion_cube>
or dynamically dispatching
<isd>
I guess if you're using trait objects, yeah.
<companion_cube>
so in general, yes
<isd>
Sure.
<isd>
And field access is definitely not namespacing also.
<isd>
But in languages that mix these two notions I don't think I've ever seen anything negative actually come of it.
<companion_cube>
well in OCaml the `.` operator is pretty… rigid
<companion_cube>
you basically have to use it in a context where it's statically known what it refers to
c4rc4s has quit [Ping timeout: 260 seconds]
c4rc4s has joined #ocaml
<isd>
On the angle brackets: I'd be less annoyed if vim did matching with them like it did with any of () {} [].
<companion_cube>
I suppose they could have used [ ] for types
<isd>
but it also looks super noisy to me, and comparing it to Haskell leads me to ask: why not just whitespace?
<isd>
Scala uses [], and it's not terrible.
<companion_cube>
beause there is no curring
<companion_cube>
currying
<isd>
I don't think there needs to be for the notation to make sense
<isd>
HashMap K V reads nicer to me than HashMap<K, V> or even HashMap[K, V]
<isd>
But I'd be happy with []
<isd>
And like I said, if this is my biggest complaint...
<Drup>
isd: What about `v HashMap(K).t` ? :D
<companion_cube>
eek
<companion_cube>
that's not a pretty part of OCaml's syntax
<isd>
Drup: in fairness, that's a somewhat different construct; you've got both functor application, projection and type parameters
<Drup>
it combines all the wrong ones :p
<isd>
the more direct translation would be (k, v) hashmap
<Drup>
isd: it's more direct, but less idiomatic :
<Drup>
:)
<isd>
Sure, but my point is now we're not just fussing about syntax -- OCaml needs the functor becuase it probably needs something besides just the type, whereas rust would use a trait or something.
<isd>
But yeah, this is why I'm drawing from haskell here :P
spew has quit []
<isd>
and the having type parameters to the left of the type constructor always felt slightly awkward to me.
mengu has joined #ocaml
twopoint718 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cbot has joined #ocaml
caltelt_ has joined #ocaml
Haudegen has quit [Read error: Connection reset by peer]
dhil has quit [Ping timeout: 265 seconds]
larhat has joined #ocaml
clog has quit [Ping timeout: 260 seconds]
ia0 has quit [Quit: reboot]
ia0 has joined #ocaml
silver has joined #ocaml
shinnya has joined #ocaml
mengu has quit [Quit: Leaving...]
isd has quit [Quit: Leaving.]
al-damiri has quit [Quit: Connection closed for inactivity]