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

After 7 years in production, Scarf has reluctantly moved away from Haskell

avi.press

Post reply on HN
Print view View original

301–310 of 320 posts

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#301

Post by pdimitar »

kstrauser wrote: post #236
pdimitar wrote: post #218

Earlier quoted context omitted.

You're exaggerating quite a lot. Biggest I've seen the cargo directory after 3 months of active Rust development was ~17GB. You can also limit it with an env var. I have capped mine at 10GB.

I’m at 227GB as I write this.

Super curious then, and I stand corrected.

You can put the `cargo clean gc` command on a daily/weekly schedule then, or configure the `gc` option in your Cargo config. Or set `CARGO_UNSTABLE_GC=true` in your shell init. Or all of the above.

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#302

Post by pdimitar »

ghc wrote: post #296
pdimitar wrote: post #279

Earlier quoted context omitted.

I don't think it has almost anything to do with vibe-coding. When I tried Haskell and OCaml some 3 years ago, they were infuriating in terms of tooling and just needless friction (don't ask, forgot, but it was mostly around package management and just entering a project and be able to run the program was a saga). Iteration speed is not only to appease business people. As a long-time dev I prefer for my PL and its too…

I've been using Haskell for 20 years. I've been running a company built on Haskell for 10. I have a very large legacy Haskell codebase. I've invested in several companies built on Haskell. Your anecdote is about your own lack of familiarity, nothing more. Yes, companies can get into trouble with Haskell compile times, memory use, etc., but enforcing disciplined coding rules and advances in tooling solved the majority…

To comment separately: lack of familiarity is true of course but do consider your bias -- familiarity should come quickly and easily. Long gone are my days where I wanted to wear badges of honor and suffer through difficult tooling, and I am willing to bet that's true for a lot of programmers.

We want to iterate and progress. You likely are used to Haskell's tooling quirks long time ago. Everyone else outside of the ecosystem does not have that advantage.

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#303

Post by pjmlp »

antonvs wrote: post #299
pjmlp wrote: post #174

Earlier quoted context omitted.

Such as? Having known Lisp since 1996, and avid digital archaeologist, I wonder which famous implementations are those.

Ok, tell me how you're an "avid digital archaeologist" and you're not aware of what I'm about to tell you. The original Lisp as designed by John McCarthy was interpreted. That became Lisp 1.5, which ran on several mainframes of the time. Programs were represented directly as S-expressions and evaluated recursively. This is one of the defining features of Lisp - the metacircular evaluator! Almost any Lisp text which c…

Lisp 1.5 manual, appendix D, compiler

https://softwarepreservation.computerhistory.org/LISP/book/L...

"When the compiler is called upon to compile a function, it looks for an EXPR or FEXPR on the property list of the function name. The compiler then translates this S-expression into an S-expression that represents a subroutine in the LISP Assembly Language (LAP). LAP then proceeds to assemble this program into binary program space. Thus an EXPR, or an FEXPR, has been changed to a SUBR or an FSUBR, respectively. Experience has shown that compiled programs run anywhere from 10 to 100 times as fast as interpreted programs, the time depending upon the nature of the program. Compiled programs are also more economical with memory than their corresponding S-expressions, taking only from 50 per cent to 80 per cent a s much space.' The major part of the compiler is a translator or function from the S-expression function notation into the assembly language, LAP. The only reasons why the compiler is regarded as a pseudo-function are that it calls LAP, and it removes EXPRts and FEXPR1s when it has finished compiling."

Enough said.

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#304

Post by threethirtytwo »

ErroneousBosh wrote: post #294
threethirtytwo wrote: post #268

Earlier quoted context omitted.

Yes. To add more nuance to what I'm saying the trajectory of the industry and society is heading towards this. Your company may not be like this now, but the future is where this is all converging. I can tell you at my current company as of now, if you're not using AI it is essentially career suicide for that specific company. I think these statements are true: 1. An expert using AI is better than an expert without u…

AI makes people produce consistently worse results. I will not under any circumstances use AI, not least because it cannot possibly solve a problem I have. At work, I've already had to "fix" some incredibly faulty projects caused by well-intentioned people thinking they can use AI to write code. I started with `rm -rf *` and moved on from there.

That's you and your anecdotal experience against raw data from the entire world.

I don't get how people like you give their one off experiences and think that validates their world view when the world is changing right before your fucking eyes. To each their own and agree to disagree because honestly your anecdotal experience is right in front of your own eyes too. I just don't get how you can't reconcile that with the rest of reality of basically EVERYONE using AI all around you. How about some nuance like, sometimes AI screws up, but often it does better? That realistic viewpoint may not fit the world view you wish existed and so you choose the most one sided lack of naunce world view you can possibly make.

Do whatever you want. But somewhere in the back of your mind, you know you're just being stubborn.

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#305

Post by psd1 »

landdate wrote: post #300
psd1 wrote: post #176

Earlier quoted context omitted.

https://xkcd.com/224/ lol Zuckerberg became rich on php, which grinds my gears almost as much as the genocide thing. In fairness, my peers at $corp used to ship while I was sad-Wojciech "no you can't create tech debt". The universe is cruel to people who care.

php is a great language. there is a reason why the majority of the web runs on it.

There's a reason why littering is the most common crime - it doesn't require intelligence or planning, and whatever you are holding can instantly become trash.

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#306

Post by pdimitar »

threethirtytwo wrote: post #130
purpleidea wrote: post #129

Haskell definitely needs to improve a lot of things, but moving to python is obviously a mistake for most cases. Golang is probably the best language for LLM things, it's got reasonably strong types, compiles very fast, and is simple. Much nicer to work with than Rust for example. But these days most code should probably be golang or rust if you're not building a webui.

Typescript is the best for AI along with Python. Purely because there’s so much training on it. The LLMs are better at typescript. Also typescript is a better overall language than golang. More expressive types. Golang wins in performance and simplicity and raw ugliness.

Don't forget cross-compilation and a single binary. Not small advantages in _many_ scenarios.

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#307

Post by pdimitar »

nsagent wrote: post #256

Hate to bring the whole Bun rewrite drama into this discussion, but it seems the Bun team thinks it makes sense to trade a potentially faster compile time in Zig to a likely slower compile time in Rust due to the claimed advantages of a memory-safe language with a robust type system. That approach seems entirely counter to the claims in this post. Obviously, different teams can have different perspectives, but I'm su…

OP said here that their team was familiar with Python and not with Rust.

It's as simple as that.

I replied that a frontier LLM can both write code in Rust _and_ educate you. And got down voted.

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#308

Post by hollerith »

GregDavidson wrote: post #297
hunterpayne wrote: post #93

Earlier quoted context omitted.

"proving code correct has been a research topic at some point." It has been an area of active research for 40 years. But almost all the research returned the null result, meaning that the program proving didn't improve code quality (basically it didn't work). Yet somehow a group of programmers, usually fresh out of academia falls for program proving each generation. Strong types do really help but you need a good com…

I've been successfully practicing programming with proof of correctness since the 1970s. The confusion I see with most people failing at this is that they're trying to write code first and then prove it correct. The idea promoted by Dijkstra, Hoare, et al is to write the code and the proof together, with each of these aspects of the task supporting the other. The result is (in my experience) a better program develope…

Can you show us a proof of correctness you've written?

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#309

Post by aioproductos »

noelwelsh wrote: post #2

Wow. Not a Haskell user, but a big user of other languages with expressive type systems (mostly Scala; some Rust). My experience is the complete opposite. I can't imagine using a language without a good type system to catch all the junk the LLM produces. In fact I thought people would move away from languages from poor type systems, like Python, given the cost of using languages with expressive type systems has decre…

[flagged]

Re: After 7 years in production, Scarf has reluctantly moved away from Haskell

#310

Post by cwillu »

pdimitar wrote: post #301
kstrauser wrote: post #236

Earlier quoted context omitted.

I’m at 227GB as I write this.

Super curious then, and I stand corrected. You can put the `cargo clean gc` command on a daily/weekly schedule then, or configure the `gc` option in your Cargo config. Or set `CARGO_UNSTABLE_GC=true` in your shell init. Or all of the above.

PLEASE_UNBREAK_ME options should default to on; people who actually work on rust code are quite capable of turning it off when they configure the rest of their environment.
Post reply on HN