> Odin is a manual memory management based language. This means that Odin programmers must manage their own memory, allocations, and tracking. To aid with memory management, Odin has huge support for custom allocators, especially through the implicit context system.
Interesting that I was thinking of a language that combined Zig and Scala to allocate memory using implicits and this looks exactly what I was thinking.
Not that I actually think this is a good idea (I think the explicitly style of Zig is better), but it is an idea nonetheless.
A lot of our Odin procs take an allocator as a required argument specifically so they force you to choose one at the call site, because yes, often you want it to be explicit.
I am thinking now a language that had the default allocator be a GC, but you could change it to something else using implicits/context and this is enfoced everywhere (e.g.: there is no way to allocate memory "from magic", you need to call the allocator, even if it is from context).
At least thinking in Scala as a base syntax here, it would mean:
def foo(name: String)(implicit allocator: MemoryAllocator): StringBuf = {
val buf = allocator.new(100, String)
buf.append("Hello ")
buf.append(name)
buf
}
println(foo("John")) // implicit allocator from context, default to GC, no need to free
implicit val allocator: MemoryAllocator = allocators.NewAllocator()
println(foo("Alice")) // another implicit allocator, but now using the manual allocator instead of GC
defer allocator.free()
val explicitAllocator = allocators.NewArenaAllocator()
foo("Marie")(explicitAllocator) // explicit allocator only for this call
defer explicitAllocator.free()
I don't think there is any language right now that has this focus, since Odin seems to be focused in manual allocations.
The best way to harness this is to offer what companies don't: unlimited time off, no return-to-office, health insurance and savings plans that don't kick-back to the company, flat(ter) management, no all-hands meetings...
I've been doing 20 hours/week with occasional "overtime" periods i.e. 30-40 hours during crunch for the last 15 years and can't imagine ever doing full-time again. The QoL improvements are truly unbeatable, granted I take a huge pay-cut but life is more important than money.
As an employer, expecting all the benefits listed in top of thread (unlimited time off, health benefits, etc) and part time status combined with what is likely a pay rate high enough to do well on part time income, etc. This type of expectation is exactly why you’re unemployed for >1 year. If you actually want work you can find it. You’re effectively being stubborn on trying to sell a $1m house that the market values at $500k. No one is going to force you to lower your prices but the market isn’t sad about your house being unsold for over a year either. The market is moving without you.
I’m sure there’s various nuances to this and I’m assuming you are actively looking for work versus passively waiting for a perfect situation where a buyer loves your house enough to pay a premium but this actually sounds kinda disconnected from reality if that’s not the case.
in germany that's actually the law (except for the unlimited time off). you can't hire a contractor on a permanent part-time basis unless that contractor has other clients at the same time.
and the rest of the argument makes no sense. even as a contractor you'll have to pay enough to make up for the benefits they'd otherwise be getting (pro-rated of course. half the work time means half the value of benefits included). the average contracting rate is twice as high as the average salary for a reason.
I wasn’t really trying to make a global statement. The audience here skews a certain way and My assumption is this attitude is the US Bay Area tech workers, or other exFAANG, used to making >$300k USD and would be glad to make make half part time, probably living in another locale where that translates to megabucks and they still get all the other benefits. It just doesn’t exist for a reason here.
ok, with those assumptions, i agree of course. it doesn't make sense to expect bay area pay for remote work. full or part-time. but i don't see that expectation in the thread, which is why your response seemed a bit odd. for myself i'd be happy with $50k USD remote part-time. is that more realistic?
I'm talking in generalizations of course. Although I did a quick google search and it seems you are asking roughly 1.5-2x going rates in Germany even for experienced devs. I'm sure your more aware of market rates in your locale than me but it feels like I'm paying a premium at this price. For me, it would have to match up with some specialized skills or some 'reason' to justify it.
The larger view I hold, that many don't agree with, is a) if I've already decided to go remote and b) my budget is $50k then c) I could hire a small team in India/Asia. I've personally never had problems sourcing talent in those locales with my types of workloads; which I admit are rather basic (web apps, ios, devops, etc). I'm not sure if that would be the case if I was building something hard like a new database or something.
i was looking at the US market. and i am talking about the upper bound of the range that i think i can ask for. for germany my expectations are lower. since so many applications ask for a salary expectations (some requiring a number to be filled in to even be able to submit the application), it matters to pick a good number. it shouldn't be to low, nor to high.
Definitely your choice to make in terms of what salary you'd accept however I don't really understand the strategy of yours. I, or any US company, could just hire in the US if I was paying higher US rates. I could avoid the timezone issues, potential language issues, would be easier to get together in person if ever needed, etc. and I don't have to learn/concern myself with German employment laws.
All things equal, skills and such, I think it would be fairly easy to find a US based candidate at this price for part-time work. So why would I bother hiring from another country unless it saves me money?
there is no strategy. i see a job that is not limited to US only, that fits my qualifications and i apply. if there is a question about salary, i try to guess what i should put there. i am afraid if i don't put enough it is also a negative selection criteria. so that is what i am trying to figure out now. for jobs that don't even ask for a salary it's a moot point.
I don't have to learn/concern myself with German employment laws
if you don't have a subsidiary in the EU or some kind of employer of record through which you hire someone one from the EU, then the employment laws would not be relevant to you. it would just be a contractor relationship.
why would I bother hiring from another country unless it saves me money?
good point. definitely something to consider. thank you.
Part-time. When I put in overtime, I book those hours into our time-management system which I can use at a later date to take time off when things slow down.
Unlimited PTO is a scam. Instead, offer a generous amount of time off from the jump: Three to four weeks per year, with an option to roll over a portion each year and cash out the rest.
We had unlimited leave for dome senior employees for a while. Those employees ended up taking less leave than they did before and so we canned it.
We have generous leave allowances (18 working days at a starting level.) We also have a flexible sick leave policy - there is a fixed amount but we've extended that for individuals on occasion when the situation demanded it (long hospital stays etc.)
So in theory unlimited time off sounds good, but in practice its not a perk.
I was thinking of part-time work with unlimited time off: no expectations of normal working hours, or taking multiple months off. But you're right about time-off/sick days when the expectation is working a regular, full time job.
*! I was also assuming half the pay, but didn't write that either...
The amount of job postings I've been seeing in Seattle from jobs of all kinds, not just tech, that aren't even offering health insurance for full time work is absolutely ridiculous.
> Good Commandment 3. Thou shalt limit the duration of a center. ...
> To hit home runs, it’s wise to have many at bats. ...
> It’s hard to predict information technology trends much longer than five years. ...
> US Graduate student lifetimes are about five years. ...
> You need a decade after a center finishes to judge if it was a home run. Just 8 of the
12 centers in Table I are old enough, and only 3 of them—RISC, RAID, and the
Network of Workstations center—could be considered home runs. If slugging .375
is good, then I’m glad that I had many 5-‐year centers rather than fewer long ones.
> ... spreadsheet-like UI for non-technical users who know anything about SQL or DB concepts.
All the language is DB: it's tables not spreadsheets, records not rows, etc... It also doesn't hide things like 'schema' button or metadata like table description.
Maybe this project could do things like integrations with web services, easy actions on groups (like paste a list of ids and do something to all those records), and publicly available web pages (surveys, donations, pretty event pages.)
Every app has some terminology you need to learn to use it effectively, we just think that terminology should actually map to how databases work, rather than being an arbitrary abstraction. Instead of inventing our own terms, we stick to tables, records, schemas, and relationships so that users who learn Mathesar are also learning concepts that translate directly to Postgres (or relational databases in general).
Making software approachable isn’t about hiding complexity, it’s about presenting it well. The UI patterns you use determine whether a system feels intuitive, not whether the underlying mental model is simple. A well-designed interface can make even complex concepts feel natural, while a bad one can make simple tasks frustrating. Mathesar doesn’t make databases approachable by pretending tables aren’t tables, it makes them approachable by using familiar interactions, and progressively exposing functionality as you need it.
We do want to work on surveys ("forms") soon, and we're definitely thinking about bulk actions and integrations as well. Please feel free to open a feature request on https://github.com/mathesar-foundation/mathesar/issues for anything that would particularly help your use case.
> Making software approachable isn’t about hiding complexity, it’s about presenting it well. The UI patterns you use determine whether a system feels intuitive, not whether the underlying mental model is simple. A well-designed interface can make even complex concepts feel natural, while a bad one can make simple tasks frustrating.
I don't care how God-damn smart
these guys are: I'm bored.
It's been raining like hell all day long
and there's nothing to do.
Written January 24, 1967
while poet-in-residence
at the California Institute
of Technology.
> Odin is a manual memory management based language. This means that Odin programmers must manage their own memory, allocations, and tracking. To aid with memory management, Odin has huge support for custom allocators, especially through the implicit context system.
https://odin-lang.org/docs/overview/#implicit-context-system
reply