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

How an MIT research project became the Julia programming language

news.mit.edu

Post reply on HN
Print view View original

61–70 of 142 posts

Re: How an MIT research project became the Julia programming language

#61

Post by lalalanananana »

eigenspace wrote: post #55
lalalanananana wrote: post #52

Earlier quoted context omitted.

It was a great idea for a language. In practice though,it's hard to recommend. Great pet project for some mit professors to make a bunch of side money on top of their salaries though. Everyone else riding it is pretty much trying to niche their career rather then build something people can rely on unfortunately. It's the most unstable language I've ever used. In production I watched companies spend millions of dollar…

This depends a lot on what you're trying to do with it. There have been companies which did what you described, but there's also companies happily using it. If you reach into unstable language internals, yes there is a lot of churn. If you use public language interfaces, the language has been extremely stable for a long time. The ecosystem quality and quantity depends a lot on what you're trying to do. If you're far…

Not griping about the internals. More like breaking changes, weird issues with basic transitive dependencies breaking after a minor version bump to the language. Gave me, and others on the team, the impression that the whole thing was held together with bubblegum and toothpicks.

The ode stuff is cool, but when we reached for it none of the demos ran on recent versions. It was almost like the groups working on it either intentionally made it so you couldn't keep up with them or that again everything was built on a bed of sand.

I agree writing linear algebra in Julia is clean. That said, the cost for adding a few "." Chars or calling a library in any other language far outweighed the costs for trying to buy into the language itself.

I didn't even know you could do web dev in Julia. I don't want to know what that looks like.

Re: How an MIT research project became the Julia programming language

#63

Post by eigenspace »

defrost wrote: post #59
eigenspace wrote: post #57

Earlier quoted context omitted.

Okay, but why are you trying to think about *elements* of a list in terms of offsets from the origin? I mean, that's an important low-level detail to know when you're working with assembly or doing pointer math, but it is not something that necessarily needs to be polluting the semantics of a high level language. I find it much easier to think in terms of v[i] is the i-th element of my vector. These sorts of things j…

You asked for a good argument - I provided one. > but why are you trying to think about a list of elements in terms of offsets from the origin I don't try to think about them in this way - I do and have always thought about them in this way - in software terms for 50 years, in real world cut, saw, and hammer ways for over 60. > I find it much easier to think in terms of ... Which is the crux of the issue really, that…

> You asked for a good argument - I provided one.

I don't see a good argument though, I just see adaption to a quirky convention.

> Either way of thinking works - I spent decades going back and forth from Fortran to C, and people are free to make their high level languages however they wish - it's trivial to move from one to the other.

Here I agree. I have no real problem using a 0-based indexed language, I adapt to it quickly (or as you mention a -1 indexed language. Julia itself actually stores type-level metadata at the -1 index of a pointer to a mutable struct)

I just dislike when people try and turn every conversation about julia into "oh it's 1-based indexed so that disqualifies it", and act like 0-based indexing is some god-given most natural way to do all indexing.

Re: How an MIT research project became the Julia programming language

#64

Post by defrost »

eigenspace wrote: post #63
defrost wrote: post #59

Earlier quoted context omitted.

You asked for a good argument - I provided one. > but why are you trying to think about a list of elements in terms of offsets from the origin I don't try to think about them in this way - I do and have always thought about them in this way - in software terms for 50 years, in real world cut, saw, and hammer ways for over 60. > I find it much easier to think in terms of ... Which is the crux of the issue really, that…

> You asked for a good argument - I provided one. I don't see a good argument though, I just see adaption to a quirky convention. > Either way of thinking works - I spent decades going back and forth from Fortran to C, and people are free to make their high level languages however they wish - it's trivial to move from one to the other. Here I agree. I have no real problem using a 0-based indexed language, I adapt to…

> , I just see adaption to a quirky convention.

Of course you do - you very likely didn't start programming in assembler.

You literally asked "How do I get to .." implying you wanting street instructions, distances, etc.

In assembler the third element begins literally and straightforwardly at the address base plus two (element widths).

That's not "a quirky adaption" is it? It's a dull pragmatic address of the start of the third element - the answer to the question you posed.

Re: How an MIT research project became the Julia programming language

#65

Post by eigenspace »

lalalanananana wrote: post #61
eigenspace wrote: post #55

Earlier quoted context omitted.

This depends a lot on what you're trying to do with it. There have been companies which did what you described, but there's also companies happily using it. If you reach into unstable language internals, yes there is a lot of churn. If you use public language interfaces, the language has been extremely stable for a long time. The ecosystem quality and quantity depends a lot on what you're trying to do. If you're far…

Not griping about the internals. More like breaking changes, weird issues with basic transitive dependencies breaking after a minor version bump to the language. Gave me, and others on the team, the impression that the whole thing was held together with bubblegum and toothpicks. The ode stuff is cool, but when we reached for it none of the demos ran on recent versions. It was almost like the groups working on it eith…

> More like breaking changes

That certainly has not been my experience with the language since 1.0

> weird issues with basic transitive dependencies breaking after a minor version bump to the language.

Not sure what exactly this is referring to, but I suspect it was some bugs that happened when some stdlib packages were taken out of the sysimage and started being treated more like regular packages which are pre-installed.

For a couple minor versions, if you instantiated an manifest from a previous version that used some stdlibs, it could error out. That was indeed unfortunate and IMO should not have been released as such, but it's since been fixed.

I will point out though that officially, you are not supposed to use the same manifest across versions.

> didn't even know you could do web dev in Julia. I don't want to know what that looks like.

There's actually some rather cool stuff happening in that space, but yeah it's early days.

Re: How an MIT research project became the Julia programming language

#66

Post by jondea »

defrost wrote: post #60
jondea wrote: post #58

Earlier quoted context omitted.

The third hole is _offset_ by 2, but if you ask a carpenter to add number labels to your pigeonholes, they are going to start at 1. Indexes start at 1, offsets start at 0.

Well, of course. And offsets are the measurements that get you to an element - the question was explicitly phrased as "how do I get to " ...

The problem is that we call the things in square brackets indexes, when we should probably call them offsets

Re: How an MIT research project became the Julia programming language

#67

Post by adgjlsfhk1 »

JanisErdmanis wrote: post #11
adgjlsfhk1 wrote: post #3

Earlier quoted context omitted.

a between session cache had been merged for 1.14 (release expected within 6-12 months).

What is this magic, how does it differ from PkgImages Julia already has?

pkgimages are keyed on package (and dependency) version so if you frequently add or update packages they don't help as much as they should. this new cache is at the function granularity and caches the llvm optimization and native codegen steps.

Re: How an MIT research project became the Julia programming language

#68

Post by lalalanananana »

eigenspace wrote: post #65
lalalanananana wrote: post #61

Earlier quoted context omitted.

Not griping about the internals. More like breaking changes, weird issues with basic transitive dependencies breaking after a minor version bump to the language. Gave me, and others on the team, the impression that the whole thing was held together with bubblegum and toothpicks. The ode stuff is cool, but when we reached for it none of the demos ran on recent versions. It was almost like the groups working on it eith…

> More like breaking changes That certainly has not been my experience with the language since 1.0 > weird issues with basic transitive dependencies breaking after a minor version bump to the language. Not sure what exactly this is referring to, but I suspect it was some bugs that happened when some stdlib packages were taken out of the sysimage and started being treated more like regular packages which are pre-insta…

Yea this wasn't user error which is the common gaslight trope from the Julia community. Yes some of these instances post dated 1.0 . Yes the average person is sick of being told there's nothing wrong with the technology when there's been a serious track record of it being a disaster. For companies an expensive one.

It's really not early days. The language is about 15 years old. That excuse gets really tired.

It's crazy to me how every person posting positively about Julia has the same tactics. They don't change year after year. They try to draw people in only to find it's a Trainwreck or a waste of time.

I just hope my comments save a start up a few million dollars or a curious hobbyist 5 months of their free time.

Re: How an MIT research project became the Julia programming language

#69

Post by JanisErdmanis »

adgjlsfhk1 wrote: post #67
JanisErdmanis wrote: post #11

Earlier quoted context omitted.

What is this magic, how does it differ from PkgImages Julia already has?

pkgimages are keyed on package (and dependency) version so if you frequently add or update packages they don't help as much as they should. this new cache is at the function granularity and caches the llvm optimization and native codegen steps.

Cool, can’t wait to try that out in a stable release.

Re: How an MIT research project became the Julia programming language

#70

Post by 12jahsg »

ModernMech wrote: post #44
jhoechtl wrote: post #21

Earlier quoted context omitted.

> Julia uses 1-based indexing. That rules it out to become a successor to Python. It sounds reasonable until you start interacting with other libraries. I do know the attemp to justify it for Lua and I don't buy it.

This is why AI is better at writing code than humans. They just write code and don’t complain about things that don’t matter, like indexing; or another classic, spaces vs tabs. Humans must learn to get past these things.

AI does not complain because it has no agency and cannot do anything without a prompt.

It is better than your code, which is probably a low bar.

Post reply on HN